SQLI Attack: Attack Prevention Techniques for SQL

Injection
ABSTRACT:
This article speaks about the improvement in the
development process of the application to avoid the
SQLIA attack at the preliminary level, especially at
the source code itself. We discuss about the
possible methods to attack an SQLIA providing the
pseudo code for better understanding. A prototype
of the solution i.e. consolidating the validation into
a single custom component termed as Injection Box
control (IBC) that takes care of all the possible
preventive measures for controlling the SQLIA at
the source code level itself.
Keywords: SQL rand, Sql injection vulnerabilities,
Sql injection attack prevention.
1. INTRODUCTION
Web applications enable much of todays online
business including online banking, online
shopping, and online university admissions and
various online governmental activities. Anyone can
use a web browser and can access them, and the
data they manage typically has significant value
both to the users and to the service providers. [1, 2,
3, 4, 5 and 6] The standard language for accessing
database servers including MySQL, Oracle, and
SQL Server is SQL (Standard Query Language).
Web programming languages such as java and
asp.net provide various methods for constructing
and executing SQL statements, but developers
often misuse these methods due to lack of training
and development experience and resultant occurs
as SQL injection vulnerabilities. To construct SQL
statement the developers usually use the dynamic
query building with string concatenation. [7, 8, 9,
10, 11 and 12 ] The system forms queries with
inputs directly received from the external sources,
during runtime. This method makes it possible to
build different queries based on varying conditions
set by the user.
However, as this is the cause of many sql injection
vulnerabilities. Consequently, vulnerabilities that
allow an attacker to compromise a web
applications control of its data pose a significant
threat. SQL command injection vulnerabilities
comprise most of this class.
A sql injection [SqlI] attack occurs when a
malicious user, through specially crafted input
causes a web application to generate and send a
query that send a query that functions differently
than the intended programmer.

For example, if a database contains user names and

passwords, the application might have code such as
the following:
Query = "select * from accnt where name='"
+ request.getParameter("name")
+ "' and password='"
+ request.getParameter("pass") + "'";
This code generates a query intended to be used to
authenticate a user who tries to login to a web site.
However, if a malicious user enters guy into the
name field and.OR' a'='a. into the password, the
query string becomes:
Select * from accnt where
Name ='guy' and password='' or 'a'='a' this
condition always evaluates to true.
2. Existing Issues
Though client side input validation happens, never
trust that, since it can be evaded easily i.e. hacker
will simply watch the return value and changes it as
he needs[1].Although we have many tools to
identify SQLI vulnerables, research show that only
20 percent of the vulnerables are revealed while a
scan is run. Out of the alarms raised by the tools 50
percent of them are false alarms [3].Experts
suggest that using prepared statements, stored
procedures in the code can avoid injection, but it is
found that string concatenation while framing a
dynamic query can cause SQLIA to the system.
3. Related works
Fault injection techniques have traditionally been
used to inject physical (i.e., hardware) faults [18],
[19]. In fact, initial fault injection techniques used
hardware-based approaches such as pin-level
injection or heavy-ion radiation. The increasing
complexity of systems has lead to the replacement
of hardware-based techniques by software
implemented fault injection (SWIFI), in which
hardware faults are emulated by software. Xception
[20] and NFTAPE [21] are examples of SWIFI
tools.
The injection of realistic software faults (i.e.,
software bugs) has been absent from fault injection
effort for a long time. First proposals were based on
ad-hoc code mutations [22], [23], but more recent
works focus on the injection of representative

software faults based on comprehensive field

studies on the most common types of software bugs
[24].
The use of fault injection techniques to assess
security is actually a particular case of software
fault injection, focused on software faults that
represent security vulnerabilities or may cause the
system to fail in avoiding a security attack. Neves
et al. proposed an Attack Injector
Tool (AJECT) to support the discovery of
vulnerabilities in network servers, specifically
IMAP servers [25].
To attack the target system they used predefined
test classes of attacks and some sort of fuzzing. Our
approach automatically discovers places in the web
application code that can be used to inject
vulnerabilities using fault injection techniques and
smart fuzzing to seamlessly attack them.
It is shown that weak typed languages are more
prone to SQLI vulnerables than the strong typed
languages [1]. 76 percent of the SQLI vulnerables
are related to the multiple function call extended
(MFCE). The commercially used scanners are
unable to detect most of the vulnerables injected
via Vulnerability Attack Injector Tool (VAIT).
Despite some of them seemed to be apparently easy
to detect. This shows that there is always a room
for improvement in detecting vulnerables by the
scanner [4].
The industry uses fuzzing and mutation testing to
automate penetration testing of web applications.
They rely on web application vulnerability scanner
tools that also generate reports compliant with
security regulations (Sarbanes-Oxley, PCI-DSS,
etc.). Some of the best known
of such tools are HP WebInspect, IBM Watchfire
AppScan, Acunetix web application security
scanner and Web- Sphinx. In spite of their
continuous development, these tools still have
many problems related to the high number of
undetected vulnerabilities and high percentage of
false positives, as shown by several studies [26],
[27]. To address these problems, it was proposed a
method to benchmark these scanners [26]. The
method starts by identifying all the points where
each type of bug can be injected, then injecting the
bug. Many of these bugs injected are vulnerabilities
that can be used to test and compare the
performance of the scanners.
The use of model checkers for security analysis
was also proposed [28]. In this case, the
vulnerability is injected by mutating the formal
model of the web application. The model is also

used to generate test cases that are used to attack

the web application in a semi-automatic way.
The list of possible types of vulnerabilities
affecting web applications is enormous, but XSS
and SQLi are at the top of that list, accounting for
32 percent of the vulnerabilities observed [3], [6].
This is why we focus on those two important
vulnerabilities, SQLi and XSS.
Attack Scenario Remarks
An attack can be considered successful if it leads to
an error [14]. Obviously, the consequences of the
attack (the failure and its severity) are dependent
on the concrete situation, on what is compromised
(credit card numbers, social security numbers, bank
account information, passwords, emails, etc.), on
how it is compromised (information disclosure,
ability to alter the data or to insert new data, etc.)
and on how valuable is the compromised asset (the
value to the company, to the client from which the
information belongs, to the companies operating in
the same market, etc.) [10]. Although it is not a
direct goal of the attack injection methodology
presented here it can, however, provide important
insights about security related issues allowing
further analysis to obtain data about the
consequences of the attack.
To avoid attacks, web application developers are
currently reducing the number of error messages
displayed to the user. This does not prevent SQLi
attacks, but makes it harder to identify SQLi
vulnerabilities using the black-box approach.
However, after the vulnerability is found it is as
easy to exploit as it was before. One consequence
of this trend is an extraordinary increase in the
false-positive and false-negative rates of black-box
testing tools such as automatic web application
vulnerability scanners [29], [27]. This also applies
to other security mechanisms that use the same
methodology, like the SQLmap sponsored by the
OWASP project, for example [30]. The attack
injection approach described in this chapter is quite
immune to this countermeasure technique, because
of the way the data used for the analysis is
obtained: through the use of probes placed in
different layers of the web application setup and
correlating their data (e.g., HTTP and SQL
interactions).
SQL Injection Techniques
Tautologies One method to gain unauthorized
access to data is to insert a tautology into the query.
In SQL, if the where clause of a SELECT or
UPDATE statement is disjuncted with a tautology,
then every row in the database table is included in
the result set.

To illustrate, consider an online message board

application. Assume that a user has logged into the
web site properly. To update their account
information, the user navigates to the proper page.
In the query string, the member id is maintained.
The web page submits, in the query string,
details.asp?id=22. In middleware, the query
SELECT
*
FROM
members
WHERE
memberid=22 is generated, and the appropriate
information is returned back to the user. However,
an attacker could easily manipulate this interaction
by editing the query string to contain a tautology,
such as details.asp?id=22 OR 1=1. The resulting
query is then SELECT * FROM members WHERE
memberid=22 OR 1=1, which will select the top
user in the users table (user id 1 may not be a valid
id). Often, this is an admin, because they are the
first to use the application.
The attacker is now free to read and modify the
admins credentials. Checking for tautologies can
be difficult, because SQL allows a wide range of
function calls and values. Simply checking user
input for patterns such as n=n or even for an equals
sign is not sufficient. For example, other SQL
tautologiesare greg LIKE %gr% and
greg=Ngreg which are based on operators, such
as LIKE and =N that are not typical math
operators.
UNION Queries Another SQL injection technique
involves the UNION keyword. SQL allows two
queries to be joined and returned as one result set.
For example, SELECT col1, col2, col3 FROM
table1 UNION SELECT col4,col5,col6 FROM
table2 will return one result set consisting of the
results of both queries1 .
Let us return to our previous example, SELECT *
FROM members WHERE memberid=22. If the
attacker knew the number and types of the columns
in the first query, an additional query such as
SELECT body,results FROM reports can be
appended. For some applications, surmising this
information is not difficult. If the programmer is
not consuming all exceptions, incorrect SQL
queries will generate error messages that expose
the needed information [12]. For example, if the
two queries in the UNION clause have a disparate
number of columns, an error such as All queries in
an SQL statement containing a UNION operator
must have an equal number of expressions in their
target lists will be returned.
The attacker merely changes the query to SELECT
* FROM reports WHERE reportid=22 UNION
SELECT username,password,1 FROM members to
try additional queries. The attacker would then
continue to add dummy columns until an error such
as Syntax error converting the varchar value feet
to a column of data type int occurs. This signals

that the column count is correct, but at least one

column type is not. The attacker then alters the
types accordingly.
Additional Statements An interesting point when
using a UNION to select multiple requests is that
often only the first row of the result set is used by
the web page. In this scenario, the attacker does not
necessarily benefit from returning more rows than
what was intended. However, a similar but
alternative approach is to UNION the first query
with a new query that does not return addition
results. These new queries often perform specific
actions on the database which can have disastrous
consequences. For example, Microsofts SQL
Server provides two system level stored procedures
designed to aid administrators.
These tools inadvertently provide powerful features
to an attacker. The first is the xp cmdshell(string)
command. This function can be UNION d with
any other query. The effect is essentially that the
command passed to the function will be executed
on the server as a shell command. Another
interesting system procedure is sp execwebtask
(sql,location). This command executes the SQL
query and saves the results as a web page at the
specified location. The location need not be on the
database server, it can be placed in any accessible
UNC path. For example, SELECT * FROM reports
WHERE reportid=22 UNION sp make webtask
\\IP address\ share\test.html,SELECT * FROM
users will create an HTML page of the entire users
table onto the server IP address.
Using Comments SQL supports comments in
queries. Most SQL implementations, such as TSQL and PL/SQL use - - to indicate the start of a
comment (although occasionally # is used). By
injecting comment symbols, attackers can truncate
SQL queries with little effort. For example,
SELECT * FROM users WHERE username=greg
AND password=secret can be altered to SELECT
* FROM users WHERE username=admin - AND password=. By merely supplying admin - as the username, the query is truncated, eliminating
the password clause of the WHERE condition.
Also, because the attacker can truncate the query,
the tautology attacks presented earlier can be used
without the supplied value being the last part of the
query, or an int. Thus attackers can create queries
such as SELECT * FROM users WHERE
username=anything OR 1=1 - - and
password=irrelevant. This is guaranteed to log the
attacker in as the first record in the users table,
often an administrator.
Failure detection strategies can be implemented as
local or remote detection modules, depending on
whether they are or not deployed on the same node

of the monitored component. Local and remote

detection can be both implemented with querybased or log-based techniques. Query-based
techniques rely on interrogating the monitored
component health status, to discover potential
anomalies. The query can be performed
periodically (heartbeat techniques, such as [8, 9]),
or implicitly each time another distributed
component tries to invoke the component of
interest [10]. On the other hand, log-based
techniques consist in analyzing the log files
produced by the component, if available [11, 12].
In fact, these may contain many useful data to
comprehend the system dependability behavior, as
shown by many studies on the field [13, 14].
Moreover, logs are the only direct source of
information available in the case of OTS items.
Both query-based and log-based techniques can be
considered as direct detection techniques: hey try to
infer the component health status by directly
querying it or by analyzing data items directly
logged by the component itself. A different
approach would instead be to infer the health of the
observed component by monitoring its behavior
from an external viewpoint, along with its
interactions with the environment. These
approaches can be labeled as indirect failure
detection techniques. As an example, the work in
[7] exploits hardware performance counters and OS
signals to monitor the system behavior and to
signal possible anomalous conditions. For instance,
as better detailed an active hang is flagged if the
instruction count executed by the process goes
outside a given bound. However, this technique is
not useful in the case of passive hangs, where
instructions are not executed.
Indirect techniques have been especially adopted
for intrusion detection systems. In these cases,
anomaly detection approaches are used to compare
normal and anomalous runs of the system. In [15]
the execution of a program is characterized by
tracing patterns of invoked system calls. System
call traces produced in the operational phase are
then compared with nominal traces to reveal
intrusion conditions. Other solutions, such as [16,
17], are based on data mining approaches, such as
document classification. They extract recurrent
execution patterns (using system calls or network
connections) to model the application under
nominal conditions, and to classify run-time
behaviors
as
normal
or
anomalous.
Notwithstanding the high degree of accuracy that
these solutions are able to achieve, they require
high computational load (due to the huge volume
of analyzed data), which is inadequate to perform
on-line detection in critical systems. Moreover,
they have been applied to intrusions, which are
deliberate software faults, rather than on transient

software faults. Hence, it is not clear whether they

are able to detect software hang failures due to
transient faults.
3.1 Pseudo Code for hacking Select SQL
statements
Open a connection to SQL
Prepare an SQL Command for select statement.
E.g. string sQuery = Select 1 from Table
Name
where
UserName=+txtUname.text+
and
Password=+txtPass.text+;
Boolean bFlag = ExecuteSQL(Squery);
If a hacker tries to inject a known username e.g
MyUserName followed by single apostrophe and
double hyphen i.e. My Usernamethen MSSQL
will comment the statement there after and always
return the value as true, thus letting the hacker into
the application system.
3.1.2. SQLI Attack Method 2
If the application system takes in an user input and
executes the query and binds the data to an data
grid dynamically based on the number of resultset
returned, then the hacker can use a ; a semicolon
followed by the select statement ie ;select * from
sysobject
where xtype=u; to pull the list of tables used in a
particular database.
3.2. Pseudo code for hacking insert statements
Open a connection to SQL
Frame an insert statement dynamically based on
the inputs given e.g. string sQuery = Insert into
tablename (col1, col2)
Values
(+txtName.text+,+txtAddress.text+,);

ExecuteQuery (sQuery)
3.2.1. SQLI Attack Method 1
Here if an hacker tries to inject an input Address1;
Delete from table name ;, then if appropriate
permission are available for that system then it can
completely wipe out the data e.g customer data for
that organization.
Similarly we can use; Truncate table, ; Drop
table; instead of delete statement.
4. Existing Framework
In the existing process, User tries to give inputs
that are passed to the DB server without validating

for SQLIA. The hacker will try to inject the

vulnerables trying to exploit the server.

Set the attribute autocomplete="off" for the

IBC.
Mark the cookie as HTTPOnly
Apply the following changes to your web.config
file to prevent information leakage by using custom
error pages and removing X-AspNet-Version from
HTTP responses.
<System.Web>
< httpRuntime enableVersionHeader="false" />
<customErrors
mode="On"
defaultRedirect="~/error/GeneralError.aspx">
<error
statusCode="403"
redirect="~/error/Forbidden.aspx" />

Figure 1: Existing process for SQLIA by Hacker

The hacker tries to inject the vulnurables into the
Web GUI and try to exploit the vulnerables.
5. Proposed Framework
In the below Fig .2 IBC replaces the regular Input
control, that blocks the hacker from Injecting the
vulnerables into the server. Thus acts as an internal
firewall within an application.

<error
statusCode="404"
redirect="~/error/PageNotFound.aspx" />
<error
statusCode="500"
redirect="~/error/InternalError.aspx" />
</customErrors> </System.Web>

Set the ViewState Encryption mode to Always

in config file. E.g.
<System.Web>
<pages viewStateEncryptionMode="Always">
</System.Web>
To avoid this, output should be encoded according
to the output location and context. For example, if
the output goes in to a JavaScript block within the
HTML document, then output needs to be encoded
accordingly.

Figure 2:
Prevention

Proposed

Process

for

SQLIA

6. Proposed Solution
A simple solution thought of SQLIA attack is
creating an custom component termed as Injection
Box Control (IBC) with the below checks made at
the code level to block the SQLIA.
Strip all the possible SQL vulnerables at the
server side code e.g Truncate, Drop, Delete, etc.
And pass the diffused vulnerable SQL to the
Database server .ie. IBC act as an validation layer
for the SQL vulnerables.

7. Field Study Analysis on Vulnerability using

SQLIA Tool NetSparker
Analysed some of the live Web URLs that take
user input and process data

 ASP.Net Framework Identified

Version Disclosure
HTTP Strict Transport Security Policy (HSTS)
not enabled.
Robots.txt detected (i.e. hidden files are
detected).
ASP.NET Debugging Enabled.
7.4. Low Category Vulnerables
Low Category vulnerable identified above are
Cookie not marked as Http Only.
Auto Complete enabled.
View State is not encrypted.
Internal IP Address disclosure
Internal Server Error detected
Table 1: Metrics on Vulnerable Categories
Surveyed Over Above Urls Using Netsparker

Cross Site Request Forgery Detected

Insecure Frame

7.1. Critical Category Vulnerables

The Critical category vulnerables identified are
Password Transmitted over HTTP. The possible
remedy is all the sensitive data need to be
transferred via HTTPS instead of HTTP.

Future Work

7.2. Medium Cater gory Vulnerable

As part of future work, we plan to extend our

prototype to develop a complete implementation of
the proposed architecture. This would then be used
as a test bed to evaluate the different web
application scripts available in the public domain.
We are currently exploring the security
implications of incorporating well known
randomization algorithms into our model in case
the session id which is used to separate the user
inputs from the SQL statement might be guessed by
the attacker. We are also exploring the possibility of
implementing this functionality as a middleware to
the database engine, to avoid explicit
instrumentation of source code.

Medium Cater gory vulnerable identified above are

Conclusion

Open Redirection

Web application developers need more extensive

training to raise their awareness about SQL
injection and to become familiar with state-of-theart defenses. At the same time, they need sufficient
time and resources to implement security measures.
Too often, project managers pay less attention to
security than to functional requirements. Second,
researchers should implement their proposed
approaches and make such implementations, along
with comprehensive user manuals, available either
commercially or as open source. Too many existing
techniques are either not publicly available or are

Permanent Cross-site scripting that allows an

attacker to execute a dynamic script (infected
JavaScript, VBScript) in the context of the
application. The remedy is output need to be
encoded using Microsoft Anti-cross-site scripting.
Cookie Not Marked as Secure. The possible
remedy is mark all cookies used within the
application as secure.

Source Code disclosure

Http Header Injection
7.3. Information Category Vulnerables
Information category vulnerables identified are
Forbidden Resource.

difficult to adopt. Readily available tools would

motivate more developers to combat SQL injection.
References:
[1] C. Anley, Advanced SQL Injection in SQL
Server Applications, white paper, Next Generation
Security Software Ltd., 2002;
[2] W.G.J. Halfond, J. Viegas and A. Orso, A
Classification of SQL Injection Attacks and
Countermeasures., Proc. Intl Symp. Secure
Software Eng. (ISSSE 06), IEEE CS, 2006;
[3] D. Saravanan and Dr. S. Srinivasan, Matrix
Based Indexing Technique for Video Data.,
International journal of Computer Science, 9 (5):
534-542, 2013,pp 534-542.
[4] R.A. McClure and I.H. Krger, SQL DOM:
Compile Time Checking of Dynamic SQL
Statements, Proc. 27th Intl Conf. Software Eng.
(ICSE 05), ACM, 2005, pp. 88-96.
[5] S. Thomas, L. Williams, and T. Xie, On
Automated Prepared Statement Generation to
Remove
SQL
Injection
Vulnerabilities,
Information and Software Technology, Mar. 2009,
pp. 589-598.
[6] Y. Shin, L. Williams, and T. Xie,
SQLUnitGen: Test Case Generation for SQL
Injection Detection., tech. report TR 2006-21,
Computer Science Dept., North Carolina State
Univ., 2006.
[7] H. Shahriar and M. Zulkernine, MUSIC:
Mutation-Based SQL Injection Vulnerability
Checking, Proc. 8th IntlConf. Quality Software
(QSIC 08), IEEE CS, 2008, pp. 77-86.
[8] D. Saravanan and Dr. S. Srinivasan, A
proposed New Algorithm for Hierarchical
Clustering suitable for Video Data mining.,
International journal of Data Mining and
Knowledge Engineering, Volume 3, Number 9,
July 2011.Pages 569-572.
[9]. J. Fonseca, M. Vieira, and H. Madeira,
Vulnerability &Attack Injection for Web
Applications, Proc. 39th Ann. IEEE/IFIP Intl
Conf. Dependable Systems and Networks (DSN
09), IEEE, 2009, pp. 93-102.
[10] X. Fu and C. C. Li, A String Constraint
Solver
for
Detecting
Web
Application
Vulnerability., Proc. 22nd Intl Conf. Software
Eng. and Knowledge Eng. (SEKE 10), Knowledge
Systems Institute Graduate School, 2010, pp. 535542.

[11] A. Kiezun et al., Automatic Creation of SQL

Injection and Cross-Site Scripting Attacks, Proc.
31st Intl Conf. Software Eng. (ICSE 09), IEEE CS,
2009, pp. 199-209.
[12] D. Saravanan and Dr. S. Srinivasan, Data
Mining Framework for Video Data, In the Proc. of
International Conference on Recent Advances in
Space Technology Services & Climate Change
(RSTS&CC-2010), held at Sathyabama University,
Chennai, November 13-15, 2010.Pages 196-198.
[13] N. Alshahwan and M. Harman, Automated
Web Application Testing Using Search Based
Software Engineering, Proc. 26th IEEE/ACM Intl
Conference Automated Software Eng. (ASE 11),
IEEE, 2011, pp. 3-12.
[14] K.J. Biba, Integrity Considerations for Secure
Computing Systems., tech. report ESD-TR-76372, Electronic Systems Division, US Air Force,
1977.
[15] V.B. Livshits and M.S. Lam, Finding Security
Vulnerabilities in Java Programs with Static
Analysis, Proc. 14th Conf. Usenix Security Symp.
(Usenix-SS 05), Usenix, 2005;
[16] Y. Xie and A. Aiken, Static Detection of
Security Vulnerabilities in Scripting Languages.,
Proc. 15th Conf Usenix Security Symp. (Usenix-SS
06), Usenix, 2006;
[17] G. Wassermann and Z. Su, Sound and recise
Analysis of Web Applications for Injection
Vulnerabilities., Proc. ACM SIGPLAN Conf.
Programming
Language
Design
and
Implementation (PLDI 07), ACM, 2007, pp. 32-41.
[18] L.K. Shar and H.B.K. Tan, Mining Input
Sanitization Patterns for Predicting SQL Injection
and Cross Site Scripting Vulnerabilities, Proc.
34th Intl Conf. Software Eng. (ICSE 12), IEEE,
2012, pp. 1293-1296.
[19] D. Saravanan and Dr. S. Srinivasan, Video
Image Retrieval Using Data Mining Techniques
Journal of Computer Applications, Volume V,
Issue No.1. Jan-Mar 2012. Page 39-42. ISSN:
0974-1925.
[20] S.W. Boyd and A.D. Keromytis, SQL rand:
Preventing SQL Injection Attacks, Proc. 2nd
Conf. Applied Cryptography and Network Security
(ACNS 04), LNCS 3089, Springer, 2004, pp. 292302.
[21] D.T. Stott, B. Floering, D. Burke, Z.
Kalbarczpk, and R.K. Iyer, NFTAPE: A
Framework for Assessing Dependability in
Distributed Systems with Lightweight Fault

Injectors, Proc. Computer Performance and

Dependability Symp., 2000.
[22] J. Christmansson and R. Chillarege,
Generation of an Error Set that Emulates Software
Faults, Proc. IEEE Fault Tolerant Computing
Symp., 1996.
[23] H Madeira, M. Vieira, and D. Costa, On the
Emulation of Software Faults by Software Fault
Injection, Proc. IEEE/IFIP Intl Conf. Dependable
System and Networks, 2000.
[24] J. Dur~aes and H. Madeira, Emulation of
Software Faults: A Field Data Study and a Practical
Approach, IEEE Trans. Software Eng. vol. 32, no.
11, pp. 849-867, Nov. 2006.
[25] N. Neves, J. Antunes, M. Correia, P.
Ver_ssimo, and R. Neves, Using Attack Injection
to Discover New Vulnerabilities, Proc. IEEE/IFIP
Intl Conf. Dependable Systems and Networks,
2006.
[26] J. Fonseca, M. Vieira, and H. Madeira,
Testing and Comparing Web Vulnerability
Scanning Tools for SQLi and XSS Attacks, Proc.
IEEE Pacific Rim Intl Sump Dependable
Computing, Dec. 2007.
[27] Ananta Security Web Vulnerability Scanners
Comparison,
anantasec.blogspot.com/2009/01/webvulnerability-scannerscomparison. html, accessed 1
May 2013, 2009.
[28]. M. Buchler, J. Oudinet, and A. Pretschner,
Semi-Automatic Security Testing of Web
Applications from a Secure Model, Proc. Intl
Conf. Software Security and Reliability, 2012

[29]. J. Grossman, SQLi, Eye of the Storm, The

Security J., vol. 26, pp. 7-10, 2009.
[30] B. Damele, Sqlmap: Automatic SQLi Tool,
sqlmap. Source forges Net, Accessed 1 May 2013,
2009.

Zahra Shafiei is a
Student at the University of JNTUH and
Completed bachelor in mathematics applied in
computer. She is an expert on security in cloud
environment and her research interests also include
experimental Security evaluation, fault injection,
security benchmarking, software development
processes, and software quality assurance.