Web Application Vulnerability Analysis Using Robust SQL Injection Attacks

advertisement
International Journal of Engineering Trends and Technology- Volume3Issue5- 2012
Web Application Vulnerability Analysis Using
Robust SQL Injection Attacks
Anil Kumar Mandapati #1, Adi lakshmi.Yannam#2
1
2
M.Tech (CSE),Gudlavalleru Engineering College, Gudlavalleru
Associate professor(CSE), Gudlavalleru Engineering College, Gudlavalleru.
ABSTRACT:
SQL Injection Attacks is one of the most serious threats in
the security of database driven applications. An SQL
injection attack focuses on interactive web applications that
employ database services.These applications accept user
inputs and use them into form SQL statements at runtime. In
the SQL injection attack, an attacker might include malicious
SQL query portions as user input that might bring about a
different database request.Through the use of SQL injection
attacks, an attacker could thus obtain and/or modify
confidential/sensitive information. The model is intended to
study the detail SQL attacks as they possibly can and record
the dangerous attack actions by deploying some smart
program the client computer and of course the server
respectively, that may check the length and data type of the
submitted variables, and detect the injection-sensitive
characters and keywords. Therefore, much research is done
to detect and prevent these attacks and it also resulted in a
decline of SQL Injection attacks. However there are still
techniques to bypass them and such methods are too
complex to feature in real web applications. This project
proposes complete sql injection approaches in web
applications which uses Combined Static and Dynamic
Analysis and evaluates the efficiency through experiment.
sufficient so that you can perform SQL injection attacks
against web applications, as long as the attacker has basic
knowledge of HTTP, relational databases and SQL [1]. Even
if the RDBMS is secured through proper configuration, the
database are still able to be vulnerable to SQL injection
attacks conducted by malicious users. As also mentioned
there, SQL queries are executed in RDBMS necessary are
valid and well formed and users provide the required
privileges. Therefore, while security flaws are frequently to
be discovered in the whole RDBMS resulting from improper
security configuration
Objects for SQL injection attacks. Those databases usually
contain corporations’ most useful information assets:
corporate and customer data. Those data are vital to suit
functions the most corporation’s web applications, but often
even more crucial and important to suit corporation itself:
user credentials, sensitive financial information, preferences,
invoices, payments, inventory data etc. If successful, SQL
injection attacks may therefore end in exposure of and
serious influence on the businesses most precious
information assets. These attacks may in the worst case bring
about a completely destroyed database schema, which in turn
may affect a corporation’s capability to perform business.
2 BACKGROUND AND RELATED WORK
1 INTRODUCTION
With the widespread usage of data processing equipment, an
evident Requirement for protecting files and also other
information stored on computers began to concern
information security. This resulted in the generic name
computer security, which encompasses the gathering of tools
designed to protect data and defend systems against threats.
SQL injection3 is naturally a particularly dangerous threat
that exploits application layer vulnerabilities that we inherent
web applications. Compared to attacking instances
encompassing web servers or operating systems, the aim of
SQL injection usually is to to attack RDBMSs, running as
back-end systems to web servers, through web applications.
More specifically, attackers can bypass existing security
mechanisms implemented to enforce security services, and
may therefore get access to and manipulate information
assets outside their privileges. This happens to be
accomplished by modifying input parameters expected in
fields of forms embedded in internet websites, so that you
can enhance underlying queries built with SQL and passed
onto the database across the web server. Another method is
to insert arbitrary SQL within the query string potion of an
URL in the address field of web browser.A web browser is
As reported by Kok[2] and Finnigan[1], the person with the
pseudonym “Rain Forest Puppy” was among the first to
assess the techniques of SQL injection in writing. Today,
extensive material on SQL injection can be found on the
world wide web. SQL injection has frequently been
discussed in and among various security communities,
organizations, conferences, forums, hacker sites and software
manufacturers Indeed, the attempts to describe and overcome
the challenge of SQL injection are numerous, and they have
been conducted .The truth is, many of the more interesting
discussions of this very problem is supplied by advisories,
error reports from database manufacturers, and discussion
forums and hacker sites on the Internet. The reasons for
information available all contain inconsistencies linked to the
terminology used and of course the type of coverage the
trouble. Moreover, often specific database vendors, products
and technologies are discussed, therefore we guess that the
general picture is missed. In conclusion, we look like that
any effort to fully cover the topic because we are part of a
structured and general way is needed.
Jaquith [3] and OWASP and Spett [6] mention that web
applications provide connectivity, admission to information
and online services for users. Web applications can, based on
ISSN: 2231-5381 http://www.internationaljournalssrg.org
Page 562
International Journal of Engineering Trends and Technology- Volume3Issue5- 2012
Spett, today be implemented countless stages of
complexity,and each implementation possesses a distinct
purpose: “...an informational website, an e-commerce
website, an extranet, an intranet, an exchange, an exploration
engine, a transaction engine, an e-business.” The functions
performed can therefore, as OWASP notes, range from easy
tasks like searching a local directory for a file, to highly
sophisticated applications that perform real-time sales and
inventory management across multiple vendors, including
both Business to Business and Business to Consumer ecommerce, flow of effort and provide chain management,
and legacy applications.
Within the two-tier client-server architecture, mentioned by
Connolly et al. [5] clearly as the basic model for separating
tasks, clients constitute the first tier and servers the next tier.
A prospect is primarily needed for presentation services,
including handling gui actions, performing application logic
and presentation of data in the user and performing the
primary business application logic. The server is primarily
concerned with supplying data services towards the client.
Data services provide limited business application logic,
typically validation of this very client and access control to
data. Typically, the client would function on end-user
desktops and interact utilizing a centralized DBMS with a
network.
Within the three-tier architecture, the first tier still constitutes
the client which is now considered a skinny client, i.e. is
barely needed for the applications’s gui and possibly simple
logic processing, inclusive of input validation. The core
business logic of the application now resides in its own tier,
the middle tier, that runs on a server and is also called the
application server. The third tier constitutes an RDBMS,
which stores the data needed by the center tier, and may even
function on some other server known as database server. As
applications became more challenging and potentially could
be deployed to a big pile of end-users, the standard two-tier
architecture was challenged.
As reported by Connolly etal.,this mainly stems from On
account that the client-side presented two problems that
prevented true scalability. First, they rely on fat clients, i.e.
clients that require considerable Resources the client’s
computer to try effectively: disk space,work memory and
processor power.
Secondly, a significant client-side administration overhead is
essential. The solution took over as three tiered model,each
tier potentially running on a different platform. Hence,the
arguments and get a tiered model of choice more is
dependent upon factors such as performance and scalability
rather than security. Amongst others, Jaquith [3] and Spett
[6] furthermore reason that architecture issues regarding tiers
and layers are less relevant while searching for web
applications from the perspective of this very vulnerabilities
that SQL injection exploits. Weaknesses regarding security
most certainly are actually in system architectures.
of sql-query strings. „O -Original query „S -Suspecious
query
Ex- („O ) select * from admin where uid = „1„;
(„S ) select * from admin where uid = „ „ OR 1=1;--„
(„O ) select * from admin where uid = 1 && pwd
= abc ; („S ) select * from admin where uid = „ „ OR
1=1;Tokens:t1= select ,t2= *from ,t3= admin ,t4= where
,t5= uid ,t6= „,t7= OR ,t9= 1 ,t10= && ,t11= p
wd= ,t12= abc ,t13= =
Word-list contains various tokens of named t1…t13,which
are as listed above. Vector of string is generated, and
classifier classifies the first and suspicious query. An
SQLinjection attack Occurs when an attacker causes the web
application to obtain SQL queries which are functionally
different from just what the graphical user interface
programmer intended. For instance, and get a database that
stores user names and passwords, an attacker may commit to
gain root privileges by manipulating the owner name or
password string. Let’s say the applying maintains the
following code: query = \"SELECT * FROM accounts
WHERE login=’\" request.getParameter(\"login\") \"’ AND
password=’\" request.getParameter(\"pwd\") \"’\";
With this code, usually the internet server application
retrieves user inputs from login and password, and
concatenates this pair of user inputs straight into the query.
These activities code generates a query when it comes to user
authentication. However, when an attacker entersadmin
directly into login field andabc’ OR ’1=1 directly into
password field, the query string becomes the listed, whose
condition always evaluated to become logic tautology, hence
an attacker can bypass the authentication process, and put on
the fundamental privilege.
3. PROPOSED FRAMEWORK
Our propose work holds the unique idea that compares SQL
query strings and blocks suspicious sql-query and passes
original sql-query. Ex- Original query=select * from admin
where uid= 1 ; Suspecious query=select * from admin
where uid= „ OR 1=1;--„ Here, original query is passed
and suspicious query is blocked. Word-list holds the tokens
Figure 1: Typical problem overview
SELECT * FROM accounts WHERE name=’admin’
AND password=’abc’ OR ’1=1’
In the whole above case, the password field, which must
have only a password string, is replaced with five substrings: string “abc”, logic control keyword “OR”, “1”,
logical control assignment “=”, and “1”. Particularly, the
logical control code “OR” connects “password=’abc’” and
“1=1”to changes the evaluation of one's Where clause.
ISSN: 2231-5381 http://www.internationaljournalssrg.org
Page 563
International Journal of Engineering Trends and Technology- Volume3Issue5- 2012
b. The reader data (Using prototype query model) is
encrypted making use of the MD5 hash.
4. The web application sends the validated URL and hashed
user data onto the web
application in the whole server.
1)Query Collector will processes all possible SQL queries
during the data collection phase;
(2) The User Input Extractor implements a worldwide
pairwise alignment algorithm to recognize user input data .
(3) The Parse Tree Generator generates the parse tree
regarding the incoming queries.
(4) The User Input Validator evaluates weather the user input
is normal malicious based upon user input validation
algorithms. validator collects the queries that cover so many
functionalities of one's application, and stores the
minarepository. In the course of the query validation phase,
when an application-generated query be captured by your
proxy, the proxy forwards it into the user input extractor and
the parse tree generator simultaneously. The user input
extractor leverages a global alignment algorithm regarding
the application-generated query on the collected query
repository, and extracts the user input data. Then, the user
input validator validates the extracted user inputs among the
parse tree, that's created by the parse tree generator. If the
user inputs are validated as being normal, the generated
query will be sent to database directly; otherwise, the query
will be discarded currently being a malicious query.
The presence of the proxy server is not known to the user.
A reverse proxy is used to sanitize the request due to user.
As soon as the request becomes high, more reverse proxy’s
can be utilized to handle the request. This lets sst to retain a
low response time, even at high load. The actual work of this
very structure is as an instance:
1. The client sends the request onto the server.
2. The request is redirected onto the reverse proxy.
3. The sanitizing application among the proxy server extracts
the URL direct from HTTP and naturally the
user data from the SQL statement.
a. The URL is send onto the signature check
5. The filter within the server denies the request in case the
sanitizing application had marked the
URL request malicious.
6. In the event the URL can be found to become benign, then
the hashed value is send towards the database of this very
web application.
7. When the hashed user data matches the stored hash value
in the database, in that case data is
retrieved and naturally the user gains admission to the
account.
8. Else the customer's is denied access.
Data Cleansing Algorithm (DC algorithm):
1st step:Parse the user data into Tokens-token;
While (not empty of token)
Check if tok ≠ reserved SQL Keyword
Move token to User data Array-UDA;
2nd step:
For (every data in UDA)
Convert to Corresponding MD5 and store in MD5.
3rd step:
Extract the URL from HTTP;
Parse the URL into Tokens-tokens;
While (not empty of tokens)
Check if (URL = using the signature check)
Set the flag to continue;
Else
Set the flag to deny;
4th step:
Send the MD5-UDA and flag to Web application;
Extracting user data from SQL statement:
The SQL statement is extracted from the HTTP request and
the query is tokenized. The tokenized query is in comparison
to the prototype document. A prototype document consists of
all of the SQL queries from the Web application. The query
tokens are transformed into XML format. The XSL’s pattern
matching algorithm is designed to locate the prototype model
equivalent to the received Query. XSL’s Pattern Matching:
The query is first analyzed and tokenized as elements. The
prototype document maintains the query pertained to the next
particular application. By way of example the input query is,
SELECT * FROM members WHERE login=’admin’ AND
password=’XYZ’ OR ‘1=1’.When this query is received this
is converted into XML format using a XML schema. The
resulting XML would be,
<SELECT>
ISSN: 2231-5381 http://www.internationaljournalssrg.org
Page 564
International Journal of Engineering Trends and Technology- Volume3Issue5- 2012
<*>
<FROM>
<Members>
<WHERE login= ’admin’>
<AND password= XYZ>
<OR 1=1>
</OR>
</AND>
</WHERE>
</Members>
</FROM>
</*>
</SELECT>
The listed signature examines are done on the URL’s
extracted from the HTTP request.
1. Query delimiter ( --)
2. White Spaces
a minimum of 3. Comment delimiter (or // or /* */)
4. EXEC keyword
five very long. UTF coding
5. UTF coding
6. Scanning for query with signature OR followed same
characters before and after ‘=’.
7. Dropping meta characters (and their encoding) like ; ,(,),
>, <, %, +,= and @
8. Use of ‘IN’, ‘BETWEEN’ after ‘OR’.
9. Use of SQL keywords. To just look into your keywords
will allow for a few great deal of false
positives. So the perspective before and after the keyword is
also checked.The user data is converted into its
corresponding hash value using the MD5 algorithm. The
hash
value and the validated URL are then directed back to the
server.
4. EXPERIMENTAL RESULTS
All experiments were performed with the configurations
Intel(R) Core(TM)2 CPU 2.13GHz, 2 GB RAM, and the
operating system platform is Microsoft Windows XP
Professional (SP2).
SQL INJECTION ATTACKS SCREENS
ISSN: 2231-5381 http://www.internationaljournalssrg.org
Page 565
International Journal of Engineering Trends and Technology- Volume3Issue5- 2012
detection and studying alternate techniques for detection and
mitigation of SQL injection attacks.
REFERENCES:
[1] Allaire Security Bulletin, (1999) “Multiple SQL
statements in dynamic queries”.
[2]
Chip
Andrews,
“SQL
Injection
FAQs”,
http://www.sqlsecurity.com/FAQs/SQLInjectionFAQ/tabid/5
6/Default.aspx
[3] V.B. Livshits and M.S. Lam, (2005) “Finding Security
Errors in Java Programs with Static Analysis”, Proc. Usenix
Security Symposium ‘05, pp. 271-286.
[4] D.Scott and R.Sharps, (2002) “Abstracting Applicationlevel Web Security”, Proc. International Conference on the
World Wide Web ‘02, pp. 396-407.
[5] Chris Anley, (2002) “Advanced SQL injection in SQL
server applications”, Next Generation Security software Ltd.,
White Paper
[6]Web Application Security: A Survey of Prevention
Techniques Against SQL Injection Uzi Ben-Artzi
Landsmann
and
Donald
Str¨omberg
uzi-ba@dsv.su.se,donald-s@dsv.su.se.
[7] Don Kiely. Guarding against sql injection attacks. Web
advisory,
mar
2002.http://www.itworld.com/nl/windows_sec/03252002/.
[8] Don Kiely. Sql injection attacks. Web advisory, mar
2002. http: //www.itworld.com/nl/windows_sec/03182002/.
[9] Chong Siew Kok. Sql injection walkthrough. Web
advisory,
may
2002.
http://www.scanassociates.net/papers/sql_injection_
walkthrough.txt.
5. CONCLUSION AND FUTURE WORK
The novel system with intrusion prevention proxy has proved
to be effective in detecting the SQL injection attacks.
Dynamically user input extraction and analysis taking into
consideration the context of the query’s syntactic structure.
Unlike current protection techniques, our approach is fully
modular and does not require access to the source code of the
web applications or the database. In addition, our system is
easily deployable to existing enterprise environments and
can protect multiple front-end webapplications without any
modifications. Our experimental results indicate that we can
achieve have high detection rate with reasonable
performance overhead making our system ideal for
environments where software or architecture changes is not
an economically viable option. In future work, the focus will
be on optimization of the system and removing the
vulnerable points in the application itself, in addition to
ISSN: 2231-5381 http://www.internationaljournalssrg.org
Page 566
Download