=Paper=
{{Paper
|id=None
|storemode=property
|title=Protection of Web Applications Using Aspect Oriented Programming and Performance Evaluation
|pdfUrl=https://ceur-ws.org/Vol-920/p46-kajo-mece.pdf
|volume=Vol-920
|dblpUrl=https://dblp.org/rec/conf/bci/MeceKVS12
}}
==Protection of Web Applications Using Aspect Oriented Programming and Performance Evaluation==
https://ceur-ws.org/Vol-920/p46-kajo-mece.pdf
Protection of Web Applications Using Aspect Oriented
Programming and Performance Evaluation
Elinda Kajo-Mece Lorena Kodra Enid Vrenozaj Bojken Shehu
Faculty of Information Faculty of Information Faculty of Information Faculty of Information
Technology Technology Technology Technology
Polytechnic University of Polytechnic University of Polytechnic University of Polytechnic University of
Tirana Tirana Tirana Tirana
Albania Albania Albania Albania
ekajo@fie.upt.al lorena.kodra@gmail.com enidv11@gmail.com b.shehu@fti.edu.al
ABSTRACT In the case of XSS we consider a dangerous string the one
Web application security is a critical issue. Security concerns are containing non-alpha numeric characters such as <, >, =, –, ',".
often scattered through different parts of the system. Aspect Aspect Oriented Programming is a programming paradigm that
oriented programming is a programming paradigm that provides provides explicit mechanisms to modularize crosscutting concerns
explicit mechanisms to modularize these concerns. In this paper (behavior that cuts across different divisions of the software) such
we present an Aspect Oriented system for detecting and prevent as security. This means that the security code can be separated
common attacks in web applications like Cross Site Scripting from the system code which makes it a good candidate for
(XSS) and SQL Injection and evaluate its performance by applying security to a system compared to traditional
measuring the overhead introduced into the web application. The programming methodologies where the security code may be
results of our tests show that this technique was effective in spread over multiple modules of the system and its maintenance
detecting attacks while maintaining a low performance overhead. would be difficult and error prone.
In this paper, we propose and evaluate an Aspect Oriented
General Terms protection system that detects and prevents attacks on web
Algorithms, Performance, Security applications. This system analyzes and validates user input
strings. We use an aspect to capture input strings and compare
them to predefined patterns. The intrusion detection aspect is
Keywords implemented in AspectJ and is woven into the target system. The
Security, web application, XSS, SQL injection, aspect oriented
resulting system has the ability to detect malicious user input and
programming, performance evaluation
prevent SQL Injection and Cross Site Scripting. The advantage in
using aspect oriented programming lies in separating the security
1. INTRODUCTION code from application code. In this way it can be developed
Today, user and critically important company information is independently to adapt to new attacks.
managed using web applications. For this reason, web We test our system by applying it to an insecure web application
applications can be a door for attacks. The vulnerabilities present and we evaluate its impact on the overall web application
in the application can be exploited by an attacker. Even with the performance.
rapid development of Internet technologies, web applications
have not achieved the desired security levels. As a result, web The rest of the paper is organized as follows. Section 2 presents
servers and web applications are popular attack targets. concepts of SQL Injection, XSS and AOP. Section 3 describes our
proposed solution. Section 4 describes in details the architecture
The most common attacks on web applications are Cross Site of our system and its integration with the web application. Section
Scripting (XSS) and SQL Injection [14]. SQL Injection is a 5 describes the experimentation and evaluation results. Section 6
technique where an attacker injects SQL code into the user input concludes and discusses some future work.
field in order to modify the original structure of the query to post
hidden data, or execute arbitrary queries in the database. Cross
Site Scripting occurs when an attacker injects and executes scripts 2. CONCEPTS OF SQL INJECTION, XSS
written in languages like JavaScript or VBScript. AND ASPECT ORIENTED PROGRAMMING
The basic idea behind SQL Injection is inserting malicious SQL
In the case of SQL injection a string is considered to be dangerous
commands into a parameter that a web application sends to a
when it alters the original structure of the sql statement. These
database. The malicious SQL commands alter the original
strings tipically contain non-alpha numeric characters such as <,
intended structure of the query and it becomes a malicious query.
>, =, –, '," and/or a combination of the SQL keywords.
If it is executed it may corrupt or even destroy the database. The
most popular techniques used in SQL injection are tautology,
union, and comments.
BCI’12, September 16–20, 2012, Novi Sad, Serbia.
Copyright © 2012 by the paper’s authors. Copying permitted only for private and The general idea behind tautology is inserting malicious code into
academic purposes. This volume is published and copyrighted by its editors. one or more conditional statements of a SELECT or UPDATE
Local Proceedings also appeared in ISBN 978-86-7031-200-5, Faculty of Sciences,
University of Novi Sad.
46
statement so that they always evaluate as true. Let’s consider the code can be encapsulated into modules called aspects which can
case where the web application authenticates users by executing be maintained separately from the web application in order to
the following query: adapt to new attacks.
SELECT * FROM users WHERE username = ‘admin’ 3. RELATED WORK AND PROPOSED
and password = ‘pass’ SOLUTION
This query doesn’t select any rows because the password is Different solutions have been proposed addressing security issues
incorrect. Injecting ‘OR 1=1 gives: in web applications. Some of these solutions are presented below.
SELECT * FROM users WHERE username = ‘admin’ Zhu and Zulkerine propose a model-based aspect-oriented
and password = ‘‘OR 1=1’ framework for building intrusion-aware software systems [2].
This causes the WHERE clause to be true for every row and all They model attack scenarios and intrusion detection aspects using
table rows are returned. an aspect-oriented Unified Modeling Language (UML) profile.
Based on the UML model, the intrusion detection aspects are
An attacker can use the UNION clause to manipulate an SQL implemented and woven into the target system. The resulting
statement into returning rows from another table. Let’s consider target system has the ability to detect the intrusions automatically.
the following query that allows users to get the product name by
inserting the product ID. Mitropoulos and Spinellis propose a method for preventing SQL
Injection attacks by placing a database driver proxy between the
SELECT productName FROM products WHERE application and its underlying relational database management
productID = '3'
system [1]. To detect an attack, the driver uses stripped-down
An attacker can use the UNION clause to modify the structure of SQL queries and stack traces to create SQL statement signatures
this query to: that are later used to distinguish between injected and legitimate
SELECT productName FROM products WHERE queries. The driver depends neither on the application nor on the
productID = '3' UNION SELECT username, RDBMS.
password FROM users Hermosillo et al. present “AProSec” implemented in AspectJ and
This query will display the product name together with the in the JBoss AOP framework, a security aspect for detecting SQL
usernames and passwords of the users table. Injection and XSS [3]. They use the same aspect for dealing with
Another type of SQL Injection uses comments to change the SQL Injection and XSS. Their experiments show the advantage of
structure of an SQL query. The part of the SQL statement that runtime platforms such as JBoss AOP for changing security
comes after the comments will not be executed and the query will policies at runtime.
return the results that the attacker wanted. Let’s consider the The authors in [4] present Noxes, which is a client-side solution to
following SQL statement: mitigate cross-site scripting attacks. Noxes acts as a web proxy
and uses both manual and automatically generated rules to
mitigate possible cross-site scripting attempts. Analogous to
SELECT * FROM users WHERE username = ‘alice’ personal firewalls, Noxes allows the user to create filter rules (i.e.,
and password = ‘alice*123’ can be transformed in the firewall rules) for web requests.
following way:
In [5], Madow et al. describe a method for defending web
applications against XSS vulnerabilities at runtime by identifying
SELECT * FROM users WHERE username = ‘admin’ dangerous values as they are written into the HTTP response
-- and password = ‘’ rather than as they enter the program. Their method is comprised
The query will return all the information about the admin user. of two phases: an attack-free training period where they capture
the normal behavior of the application in the form of a set of
Cross Site Scripting (XSS) is an attack done against the user’s likely program invariants, and an indefinite period of time spent
browser in order to attack the local machine, steal user in a potentially hostile environment where they check to make
information, spoof the user identity, attack other machines, etc. sure the application does not deviate from the normal behavior.
The attacker uses a web application to send malicious code
usually in the form of a script. Together with the legitimate Janot, and Zavarsky in [6] present a study on the prevention of
content, the users get the malicious script from the web SQL Injections, an overview of proposed approaches and existing
application. This attack is successful in web applications that do solutions, and recommendations on preventive coding techniques
not validate user input. for Java-powered web applications and other environments. They
present their solution, the SQLDOM4J, which targets Java
Aspect Oriented Programming is a programming paradigm that environments and enables developers to construct and execute
aims to solve problems like code scattering and code tangling that safe SQL statements easily and to protect applications against
cannot be solved by traditional programming methodologies. SQL Injection Attacks.
Code scattering means that the problem code is spread over
multiple modules. This makes things difficult for the developers The solution we propose performs a two-step validation of user
when they want to fix a bug because they have to modify several input. In the first step, the user input is validated syntactically by
source files. Code tangling means that the problem code is mixed the Syntactic Validator to check whether it contains dangerous
with other code. In the case of web applications, security code characters that can be used in XSS and SQL Injection. In the
needs to be applied in different modules of the system. This second step, the input is validated by the SQL validator (Semantic
process is error prone and difficult to deal with. AOP is a good Validator) in the context of a query. This is done to check
candidate for applying security in web applications. The security whether it contains always true statements or combinations of
47
SQL keywords that can modify the original structure of the query The validation process happens in two steps. In the first step it is
and make it dangerous. What makes our system different from the checked whether the input contains dangerous characters such as
solutions described earlier is the fact that it analyzes directly user ‘<’,’ >’, ‘=’ and’ –‘that can be used to perform XSS and SQL
input before it is being used as part of an SQL query. This Injection attacks. In the second step, the input is analyzed by the
facilitates the analyzing process because the part of the query that SQL Validator (Semantic Validator) in the context of the query.
is pre-programmed is considered safe and there is no need to This is done to check whether the query contains combined SQL
validate it. Another advantage of our system is the fact that the keywords that can modify the original structure of the query or
SQL validator checks the presence of SQL keywords in the user SQL code that can transform the original query in an SQL
input. This prevents attacks that do not contain comments or statement that results always true.
always true statements but contain SQL keywords that can modify
the original structure of the SQL query. The presence of a
combination of SQL keywords is considered as an attack, not the
presence of a single SQL keyword. This prevents the generation
of false positives in cases when for example the word “Union” is
part of a legitimate user name.
3.1 System Architecture
Our system consists of three parts. The first and the most
important part is an aspect implemented in AspectJ [10] called
WebAppInputFilter that contains the logic of the whole defense
process. It contains the advices that control the validation process
as well as the actions to be taken (code to be executed) based on
the results of the validation. The aspect also contains the pointcuts
that define the vulnerable points of the web application and allow
the weaving with the advice code. It monitors the traffic in
servlets and captures some specific calls that implement the
ServletRequest and HttpServletRequest interfaces. The pointcuts Figure 1: The flow of information within the defense system.
are: Figure 1 shows the flow of information within the defense system.
pointcut pcGetParameter(): call(String The aspect captures the user input string and sends it to the first
javax.servlet.http.HttpServletRequest.getPar analyzer (Syntactic Validator). If the string is not dangerous it is
ameter (String)) passed on to the second validation step (Semantic Validator). If
pointcut pcGetParameterValues():call(String the string is dangerous it is send to the encoder. It encodes the
[] dangerous characters and the result is passed to the Semantic
javax.servlet.ServletRequest.getParameterVal Validator. If the string is not considered dangerous, it is passed on
ues(String))
to the web application as a legitimate request. If it is considered
pointcut pcGetQueryString(): call String dangerous, it is erased.
javax.servlet.http.HttpServletRequest.getQue
ryString (String)) In the cases when an attack is detected the system generates a
pointcut pcGetRequestURL(): call(String notification showing the dangerous string which can be saved on a
javax.servlet.http.HttpServletRequest.getReq log file or database for later analysis.
uestURL (String))
These pointcuts cover even the cases when the attacker performs 4. PERFORMANCE EVALUATION
the attack directly from the URL without the need for using a We tested our system by using it to protect a vulnerable web
form. application [11]. First we applied all sorts of SQL Injection and
The second part consists of a validators class that validate against XSS injection attacks on the unprotected system to see how it
XSS and SQL Injection attacks the input captured by the advices. behaved. Then we applied our solution to protect it and attacked it
The third part consists of an encoder which encodes dangerous again but were unable to bypass the application’s security. The
characters by converting them to their decimal equivalent, making results of these tests are described further in [7]
them harmless. In order to evaluate the impact of the defense system on the
The basic idea behind our technique is to capture user input and performance of the web application we measured its response
validate it by comparing it to predefined patterns. This makes our time using JMeter [12], first in the absence of the defense system
system different from the ones described in [1, 2, 3, 4, 5, 6]. As and then in the presence of our defense system. JMeter is a tool
we explained before, the user input is validated before being used used to test performance both on static and dynamic resources. It
as part of a query. The query that is entered into the web can be used to simulate a heavy load on a web application or to
application is a combination of user input and a partial SQL analyze overall performance under different load types. We
statement defined by the developer. The part defined by the created 3 scenarios with GET and POST HTTP requests:
developer is considered as safe so there is no need to validate it • POST requests for XSS
and we only validate the user input part. This speeds up the
validation process, makes it easier and also decreases the • POST requests for SQL Injection
possibility of generating false positives.
48
• A mix of legitimate requests, XSS attack requests and Table 3: Overhead for POST and GET Requests for Harmless
SQL Injection requests. and Harmful Requests for XSS and SQL Injection
Each of these scenarios represent real life situations where the 1000 10000 100000
requests can be only XSS attacks, only SQL injection attacks or a requests requests requests
mix of legitimate requests, XSS and SQL injection attacks. XSS Overhead (%) 1.93 2.03 2.19
and SQL Injection attacks use only POST requests since they try
to insert information into the web application. GET requests
represent the legitimate requests when the user wants to retrieve As we can see, the overhead introduced into the system in this
information from the web application. POST requests also are case is lower due to the presence of harmless requests that don’t
used as legitimate requests in cases where the user wants to insert need to be encoded.
information into the web application. We feel that the overhead introduced in the scenarios described
For every scenario we evaluated the system under different loads. above is at an acceptable level for use in many production
We used 3 different requests loads: 1000 requests, 10000 requests environments and it will not be noticeable by the user. Hence we
and 100000 requests. These numbers of requests are used to can conclude that our system offers an effective defense against
simulate normal, high and very high load. The default maximum XSS and SQL Injection by keeping at the same time a low
number of concurrent threads in the Tomcat’s server performance overhead.
configuration file is set to 150. We could spawn as many client
threads as we wish but if we exceed the limit of 150, performance 5. CONCLUSIONS AND FUTURE WORK
will decrease because some client request threads will always be We have presented an approach for building an effective security
waiting. So it is better to stay just under the maximum number, system for a web application. This system detects XSS and SQL
such as 149 client threads. We executed each test 5 times and Injection attacks in requests. Our system was built separately and
measured the average response time and calculated the overhead the initial code of the web application was not modified. This
introduced. The response time is the time the web application allows the security system to be evolved independently from the
takes to process a user request and send the result to the user. The web application to adapt to new attacks.
overhead is the difference in response times between the system
with protection and without protection. What makes our system different from similar proposed solutions
is the fact that it analyzes directly user input before it is being
Table 1 shows the results for the first scenario where all the used as part of an SQL query. This facilitates and speeds up the
requests are harmful POST requests for XSS. analyzing process because the part of the query that is pre-
programmed is considered safe and there is no need to validate it.
Table 1: Overhead for POST Requests for XSS
1000 10000 100000 The performance evaluation under normal, moderate and high
requests requests requests load showed that our defense system provides an effective
protection while maintaining within acceptable levels the
Overhead (%) 2.14 2.21 2.31
overhead introduced in the system.
Our system can be improved in some directions. A possible
As we can see, the defense system introduces an overhead. This improvement might be the implementation of defense against
overhead comes from the Syntactic Validator and the Encoder We other form of attacks. Also new techniques like machine learning
also notice that with the increasing number of requests, the and neural networks can be used to detect more sophisticated
overhead increases too. This comes from the increased processing attacks. Another direction of improvement might be the
and encoding of the requests. implementation of runtime weaving using the JBoss AOP
Table 2 shows the results for the second scenario where all the Framework [13].
requests are harmful POST requests for SQL Injection.
Table 2: Overhead for POST Requests for SQL Injection
6. REFERENCES
[1] Mitropoulos, D., Spinellis, D. Sdriver. 2009. Location-
1000 10000 100000 specific signatures prevent SQL injection attacks, Computers
requests requests requests & Security, Vol.28, Issues 3-4, (May-June 2009,) 121-129
Overhead (%) 1.99 2.10 2.23 [2] Zhu, Z.J., Zulkernine, M. 2009.A model-based aspect-
oriented framework for building intrusion-aware software
systems, Information and Software Technology, Vol.51,
As we can see from the results, even in this case the defense
Issue 5, (May 2009), 865-875
system introduces an overhead. If we compare these two tables
we notice that the overhead is slightly smaller in the case where [3] Hermosillo, G., Gomez, R., Seinturier, L., Duchien, L. 2007.
the requests are for SQL Injection. This comes from the fact that AProSec: An aspect for programming secure web
not all strings need to be encoded. applications, In Proceedings of the The Second International
Conference on Availability, Reliability and Security, (2007),
Table 3 shows the results for the third scenario where we have a 1026-1033
mix of harmful and harmless requests for XSS and SQL Injection.
[4] Kirda, E., Jovanovic, N., Kruegel, C., Vigna, G. 2009.
Client-side cross-site scripting protection, Computers &
Security, Vol.28, Issue 7, (October 2009), 592-604
49
[5] Madou, M., Lee, E., West, J., Chess, B. 2008. Watch What [9] Lam, M.S., Martin, M., 2008. Automatic generation of XSS
You Write: Preventing Cross-Site Scripting by Observing and SQL injection attacks with goal-directed model
Program Output, OWASP AppSec 2008 Conference checking. In Proceedings of the 17th conference on Security
(AppSecEU08) symposium (USENIX Association Berkeley, USA. 2008)
[6] Janot, E., Zavarsky, P. 2008. Preventing SQL Injections in [10] AspectJ, http://www.eclipse.org/aspectj/
Online Applications: Study, Recommendations and Java [11] WebGoat,http://www.owasp.org/index.php/Category:OWAS
Solution Prototype Based on the SQL DOM, OWASP P_WebGoat_Project.
AppSec 2008 Conference (AppSecEU08)
[12] Apache Jmeter, http://jakarta.apache.org/jmeter/.
[7] Kodra, L., Kajo, E. 2011. Protecting Web Applications
using AspectJ . 6th Annual South East European Doctoral [13] JBoss AOP, http://www.jboss.org/jbossaop
Student Conference, (Thessaloniki, Greece, September 19- [14] OWASP Top Ten Project,
20, 2011). https://www.owasp.org/index.php/Category:OWASP_Top_T
[8] Lam, M.S., Martin, M., Livshits., Whaley, J. 2008. Securing en_Project
Web Applications with Static and Dynamic Information
Flow Tracking. ACM SIGPLAN 2008 Workshop on Partial
Evaluation and Program Manipulation (San Francisco,
USA, January 7-8, 2008). PEPM '08.
50