a study on removal techniques of cross-site from web application

2015 INTERNATIONAL CONFERENCE ON COMPUTATION OF POWER, ENERGY, INFORMATION AND COMMUNICATION

A study on removal techniques of Cross-Site

Scripting from web applications

Dr. G. Shanmugasundaram Associate Professor, Department of Information Technology

Sri Manakula Vinayagar Engineering College Puducherry, India

S.Ravivarman M.Tech.,Department of Networking

Sri Manakula Vinayagar Engineering College Puducherry, India

Abstract-Cross site scripting (XSS) vulnerability is among the top 10 web application vulnerabilities based on survey by Open Web Applications Security Project of 2013 [9]. The XSS attack o�curs when web 'based application takes input from users through web pages without validating them. An attacker or hacker uses this to insert malicious scripts in web pages through such inputs .. So, the scripts can perform malicious actions when a client visits the vulnerable web pages. This study concentrates on various security measures for removal of XSS from web applications (say defensive coding technique) and their issues of defensive technique based on that measures is reported in this paper.

Keywords- cross site scripting; vulnerabilities; defensive coding technique; scripting languages; data validation; data sanitization; output escaping

I. INTRODUCTION

OW ASP 13 has reported XSS as one of the common vulnerability among web application security threats. This type of injection vulnerability allows attackers to send malicious scripts to web browsers and arises when a web application states user inputs in its HTML pages without validating them. An attacker inserts vulnerable scripting codes by those inputs in the HTML pages. When a user linked to a vulnerable page, the user's browser doesn't know the existence of malicious codes which may execute all the scripts forwarded by the web application those results a successful XSS vulnerability attack. The vulnerable scripting code of client side scripts might be a JavaScript or VB Script that can be interpreted by web browsers. XSS attacks involves various security flaws such as account hijacking, data theft, cookie theft and poisoning, web content manipulation, and denial of service. Even by the practices of using defensive coding approach and vulnerability detection methods by developers and security auditors, XSS vulnerability still remains in many web based applications. A brief study of Cross-site Scripting is given in the next chapter.

II. CROSS SITE SCRIPTING

A.Brief of cross site scripting

P. Thangavellu

B.Tech.,Department of Information Technology Sri Manakula Vinayagar Engineering College

Puducherry, India

Cross site scnptmg (XSS) is a vulnerable attack that shall happen in any part of the web application, if that web application accepts input from an attacker to result in output without validating the input. The attacker will deploy the vulnerable scripts at the client system to pass code from a web page by changing the HTML coding. This usually eradicates the trust of a client web browser to the websites. During XSS, the client trusts that the page being displayed in their web browser was actual page by the website to be shown.

Of total web applications tested in 2013 where found 25% of vulnerability to be cross site scripting.

Fig I: 2011 vs 2012 vs 2013 Web vulnerability trends [I 6]

XSS provides a gateway for the hacker or an attacker to deface web sites, deploy phishing attacks, access the web server's database and can take over a user's web browser remotely and force the user to continue with option that they are not known before. Basically XSS vulnerability attacks are performed as of JavaScript, even any active code can be used as a potential threat.

A vulnerable part in a web page based on XSS:

978-1-4673-6524-6115/$ 31.00 © 2015 IEEE

0436

SHANMUGASUNDARAM et al: A STUDY ON REMOVAL TECHNIQUES OF CROSS-SITE SCRIPTING FROM WEB APPLICA nONS

1 <%Stringempidno=request.getParameter("empidno"); %> 2 ... 3··· 4Employee IDNO:

This JSP code gets an employee IDNO: empidno, by sending a HTTP request through a browser and outputs them. XSS are not done in a single way, there are three ways to imply of XSS are continued further in the next part.

Ill. TYPES OF CROSS SITE SCRIPTING

A. Non-Persistent cross site scripting

The Reflected type of XSS is which that passes the vulnerable codes in the victim's web browser and executes the codes directly. This attack is possible by an external source which may be an e-mail or malicious link to attacker's website.

For example:

http://portal.example/index. php?sessionid= 12312312&usern ame=<script>document.locati on='http://attackerhost.exampl e/cgi-bin/cookiesteal.cgi?'+document.cookie</script>

B. Persistent cross site scripting

Stored based type of XSS vulnerability attack passes the untreated data which has been given as user input and stored in the database. This data might be a comment of scripts, server log file, message queries. Later executes malicious script from the victim server to the client web browser without being validated or escaped.

For example:

<SCRIPT>document.location='http://attackerhost.example/c gibinicookiesteal.cgi?'+document.cookie</SCRIPT>

C. DOM Based cross site scripting

Document Object Model (DOM) defined by W3C specification for denoting for XML and HTML standards and structures. DOM based type of XSS attack is executed for modifying the DOM script in the victim's web browser using of current client-side script by user supplied data. DOM based XSS is mainly functions on JavaScript on the web browser and allows hacker to use the data obtained by the script for hijacking user accounts.

For example:

<HTML> <TITLE>Welcome ... </TITLE>Hello

<SCRIPT>varpos=document. URL. indexOf("userna me=")+5 ;document. write( document. URL.substring( pos,document. URL.length)); </SCRIPT> Welcome you all !

</HTML>

XSS attack leads to many possibilities to intrude the system; some of the intrusion tasks which are achieved after XSS attack are mentioned in the next section.

IV. SUCCESSFUL XSSV RESULTS IN

As a result of XSS attack the attacker may perform the following malicious actions:

1) The attacker obtains access to confidential information's by stealing the account.

2) Confidential data in the web browsing history and temp internet files of the web browsers can be obtained from clients system by spreading web wonns.

3) After obtaining the control to the victim's system, hackers can get through and use the intranet based web applications.

V. AVOIDING CROSS SITE SCRIPTING

A. Data Validation

Data validation is the process of ensuring that your application is rwming with valid data. The PHP scripting language based web applications awaits an integer for user input, if so other types of data get eliminated [7]. Each source of user data should be processed while receiving for ensuring it as validate data type and eliminated if it fails the validation process.For example, in validating a contact number it should eliminate any strings that have letters as a contact phone number must consist of numbers only. You should also take the length of the string into consideration. And consider the length of a phone number and suitable special characters that are included to your area locale. Checking the scripted inputs and encoded forms and validating them properly leads a website to be free from XSS vulnerability. The incoming input might be a user initiated data or some other data.

Steps required in using untreated input data:

1) Standardize: URL/UTF -7 IUnicode/USASCIIIetc

decode the incoming data.

2) Character-set checking: Make sure of data that only

has valid characters.

978-1-4673-6524-6115/$ 31.00 © 2015 IEEE

0437


3) Length restrictions (minimax): Make sure that the

data occurs within a limit range in number of bytes.

4) Data format: Make sure that the structure of the

data is reliable with what is expected.

B. Data Sanitization

Data sanitization views on modulating the data for making sure that it exists in normal form even when removal unnecessary data in it. For example, for a plain type of text input from a user it must remove any tags present in it.

c. Output Escaping

Output encoding or escaping is the process of converting the data characters that have special meanings to a clientscript interpreter into the representations so the special type of this are eliminated. The data should be treated as data from other representations, so it must be escaped before proceeding in the web browser. Escaping all input data which are untreated before acceptance in the web browser.

Example code for JSP on output escaping:

Public static String encode (String data)

{ fmalStringBuffernewbuf = new StringBufferO; final char[] chars = data.toCharArrayO; for (inti = 0; i<chars.length; i++)

newbuf.append("&#").append((int) chars[i]);

returnnewbuf.toStringO;

From above discussed security measure which prevents cross site scripting vulnerability based attacks are combined to give a new prevention method called defensive coding technique, the defensive coding technique is discussed briefly in the next section.

VI. DEFENSIVE CODING APPROACH

The Defensive Coding approach prevents XSSVs by escaping all the user inputs used in HTML web pages according to the contexts in which these inputs are referenced. Like JavaScript context for input used in a JavaScript code; HTML element context for input used in an HTML element. This practices includes the above mentioned security measures together to eliminate the vulnerability completely from web applications.

JSP based vulnerable web page example:

Fig . 2: Sample JSP based vulnerable page[l]

HTML contexts where user inputs are usually referenced:

1) HTML attribute (line 9)

2) JavaScript (line 2)

3) Cascading style sheets or CSS (line 5)

4) URL parameter(line 8)

5) Line 4 which has untrusted link as source which can result to malicious links by clicking the image link.

The existing papers based on this defensive approach propose an automated approach that statically removes XSSVs from program source code. The existing method consists of two phases:

A. XSSV Detection

This identifiespotential XSSV's in the program source code using static analysis.

B. XSSV Removal

This phase first determines the context of each user input referenced in the identified potential XSSVs.

Securing the XSSVs applies the appropriate escaping methods by using an escaping rules sheet provided by ESAPI (Enterprise Security API). And uses escaping and validations process to make the code free from XSS attacks.

A tool developed called saferXSS to automate the proposed approach for the web applications written in Java language due to the frequent occurrences of XSS issues in Java-based web applications.[l]

VII. ASPECT ORIENTED PROGRAMING

Aspect oriented programing is an approach in which the security aspects are coined and the coding is done or changed according to those aspects. Aspect oriented programming is done in three steps. First web application is analyzed using static analyzing tools (SCA). Next the security aspects are generated according to the report delivered by the SCA. Finally AspectShield is designed to fix those security threats. Aspect Oriented programming is a prevention mechanism for XSS Vulnerabilities and not capable for detecting those vulnerabilities. Since exceptional case are not addressed by this methodology.

A. XSSV Detection

978-1-4673-6524-6115/$ 3l.00 © 2015 IEEE

0438


This phase fIrst determines the context of the web application by perfonning Static code analysis. The security cracks in the applications are detected and the security measures are declared accordingly.

B. Generating security aspects

This phase involves the declaration and the framing of the rule sets for the security measures need to be taken are discussed.

C. Building AspectShield

Java aspectj extension is used to implement the defIned rules into the action and such an example is AspectShield discussed by Bojan Simic and James Walden.[3]Aspectshield application discussed above will help the developer in auditing and fIxing the XSSV's in the application. In the next chapter the prevention mechanism for the common users and tools that helps the hackers to fmd the vulnerable websites at the browser end are discussed.

VIII. RELATED WORKS

Some of existing schemes for automated removal and other related vulnerability removal techniques are discussed briefly in the following sub-section.

A. Defensive Coding Approach

1) Lwin Khin Shar, Hee Beng Kuan Tan, [1] proposed an automated removal tool for eliminating cross site scripting vulnerability from web applications. The tool initially track the flow of user inputs into HTML output statements and identify potentially vulnerable statement along with control flow graph to detect vulnerable section in the code and uses pattern matching and data dependency analysis to identify the HTML contexts in which the user inputs are referenced and the required escaping mechanisms that prevent code injection. It performs source code generation and replacement to secure potentially vulnerable statements with proper escaping APIs using saferXSS[I] tool that was developed by them. The tool states the vulnerable statements that are detected as XSS flaws and the statements that are changed in the code. The author evaluated the proposed method based on the experiments on fIve Java-based web applications. Securing the XSSVs applies the appropriate escaping methods by using an escaping rules sheet provided by ESAPI (Enterprise Security API).[26] And uses escaping and validations process to make the code free from XSS attacks.

2) Shar, L.K., Tan, H.B.K., [2] proposed a codeauditing approach that recovers the defence model implemented in program source code and suggests guidelines for checking the adequacy of recovered model for XSS attacks. In the implementation patterns of defensive coding methods, this

approach uses those defences that are implemented in securing vulnerable web applications. It introduces control flow graph denotation, called tainted-infonnation flow graph, to audit the adequacy of XSS defence artefacts. The author evaluated the proposed method based on the experiments on seven Java-based web applications.

3) Bojan Simic and James Walden, [3] proposed an approach to mitigate SQL injection and Cross-Site Scripting (XSS) vulnerabilities in java based web application. By analyzing code using SCA and removing the defects using Aspect shield which is based on aspectJava. The code analyzer easily detects weakness in code and the code can automatically validated using aspect shield. The aspect shield tool which performs code validation for the defected codes in the java based web application programs. The aspect shield simplifIes the manual code analyzing by means of Fortify Source code analyzer tool to identify the vulnerable codes that are context in the XSS flaws. The author evaluated the proposed method based on the experiments on five Java-based web applications.

B. Sanitization

1) Pankaj Sharma, Rahul Johari, S. S. Sarma, [4] proposed an integrated model to prevent SQL injection attacks and reflected cross site scripting attack (Reflected XSS) in PHP based applications. This is an effective method to avoid SQL injection attack and Reflected XSS attack in development of web application environment. The proposed mechanism is divided into safe mode and production mode. Safe mode constructs a security query model for SQL injection and sanitizer model for Reflected XSS attack for each identified SQL queries for SQL injection attacks and input entry points for Reflected XSS. The development part has input areas that caries dynamic SQL queries are validated against security query model generated in safe mode and normal input text entered by the user is validated by sanitizer model instrumented in the code at safe mode.

C. Client Side Detection

1) Fangqi Sun, Liang Xu, Zhendong Su, [5] proposed an approach for the client-side scripting solution to detect XSS wonns. The XSS worm spreads from one user to another by reconstructing and propagating its payload. This approach prevents the propagation of XSS worms by monitoring outgoing requests that send self-replicating payloads. Also intercepts all HTTP requests on the client side and compare them with currently embedded scripts. The author has implemented a cross-platform Firefox extension that is able to detect all existing self-replicating XSS wonns that propagate on the client side. And the approach results in no false positive in client side environment. The proposed

978-1-4673-6524-6115/$ 31.00 © 2015 IEEE

0439


works discussed above is all meant to mitigate XSS vulnerabilities in java based web applications but most of the applications of websites being developed of HTML, ASPX, and PHP. This web developing platforms also used to develop Social networks, E-Commerce applications that to be much secured thus it consists of user credentials and databases.

TABLE I. COMPARISON OF RESEARCH WORKS BASED ON XSS PREVENTION

Existing Research XSS Type Addressed

Contributions Non- Stored DOM Web App/ica-Persistent tions

Lwin Khin Shar, Hee ,( ,( x Beng Kuan Tan[l] Java Shar, L.K., Tan, ,( ./ x H.B.K.[2] Java Bojan Simic and ,( ./ x James Walden[3] Java Pankaj Sharma, Rahul Johari, S. S. ,( x x PHP Sarma[4] Fangqi Sun, Liang ,( x x Xu, Zhendong Su[5] Java

IX. BROWSER BASED TOOLS AND METHODOLOGIES FOR

XSSV'S DETECTION

A. Tools

Apache Patches

• Apache patches l.3.12 and above provides the prevention mechanism for XSS by mitigating the XSSV using proxy modules at the browser level. It will check for the possible vulnerabilities in the web page and report it to the user. [21]

• Apache patches provide more options for the general users than the developers.

• Apache patches address DOM based XSS vulnerabilities alone but failed to discuss the other types of vulnerabilities since it concentrated on the client side scripting rather than the server side scripting.

• Another flaw in the Apache patches are they are designed to work on the standalone systems configuring this patches in an interconnected complex environment is complicated nearly impossible.

XSSer • XSSeris an open source package provided for the

Ubuntu and debian environment written in python under the license version v.3.

• XSSer works as an additional payload for tor proxy server. It monitors multiple injections that are embedded with the URL and encode those injections as Hexadecimal characters to bypass the XSS vulnerabilities.[22]

• XSSer performs the pen test with reference to the XSS valid vector dictionary recommended by the OWASP.

• XSSer does the tasks like operation testing, documentation, bug fixing and diffusion of the web applications. [22]

Fiddler • Fiddler is a language neutral application which is

windows oriented .exe file operates on the windows browser Internet Explorer monitoring web applications.

• Fiddler checks for the malicious scripts if detected escapes the execution of the code using sandbox.

• Fiddler analyzes the proxy server applications that tacks our http(s) traffics and the internet log files and debug those configurations. [23]

• Fiddler address the issue of cookie stealing, session tracking comes with XSS. Fiddler is not a complete remedy for preventing cross site scripting.

Enableloopbackutility • Enableloopbackutility is a windows oriented

application comes as .exe file. It addresses the XSS vulnerabilities by escaping and redirecting mechanism.

• Enableloopbackutility is developed to operate at the client side thereby address only client side XSS scripting and DOM based XSS vulnerabilities.

• Another flaw in this application is it is not distributed so applying it in enterprise level is merely not possible.

Ra2 DOM based XSS scanner • Ra2 is a Blackbox scan tool for DOM-Based

XSSV's in the web applications as it works as an Add-on in Mozilla Firefox.

• This Add-on works as a session aware tool which scans the web applications which requires authentication. The vulnerable URL's of web applications are stored in the Database of the tool and executed locally at the browser.[25]

• This tool supports UNICODE character encoding for avoiding information leakage from the web applications. [25]

• This tool uses native interpreter to handle scripts based on Java

B. Methodologies proposed to overcome XSSV

Runtime Enforcement ojWeb Browsers • Runtime Enforcement ofWeb Browsers is

mechanism provided by the Mozilla interprets the web applications before execution and preform

978-1-4673-6524-6115/$ 3l.00 © 2015 IEEE

0440


checks for the JavaScript operations as an intrusion detection mechanism.[19]

• The JavaScript intrusion detects Scripts provide by untrusted source which cause a situations where abuse of browser resources takes place.

• This approach is only applicable to Java Scripts based on XSS attacks. Further improvements have not been taken yet to address intrusion mechanism for different interpreters such as Java, Flash, etc.

Browser-Enforced Embedded policies • Browser-Enforced Embedded policies are the

proposal that addresses some analogies for host based intrusion detection techniques, But not for the execution in local pc's which detects program misuse.[20]

• This method uses a whitelisted scripts and a sandbox environment that restricts the scripts to execute on the local hosts and isolate the browser resources by placing the sandboxes over the browser.

• The usability and accessibility of the applications and browsers are affected and restricted by this approach.[10]

Though these patches and extensions for browsers are defined to prevent or blocks script from running on the web browsers, they doesn't include any security measures for the developers to build web applications and only can identify unexpected scripts which are excluded during encoding code. The summary given below initiates the drawbacks of existing techniques and tools which are mentioned above in the basis of developer side to prevent web vulnerabilities like security measures, defensive coding and AspectShield and SaferXSS.

TABLE II. COMPARISON OF VARIOUS XSSV'S TOOLS

Vulnerability discussed Usability of tool TOOL

Non- Stored DOM Developer Client Persistent side side SaferXSS ,( ./ ./ x x

Aspect Shield

,( ./ ./ x x

Apache Patches

,( x x ./ x

XSSer ,( x x ./

Fiddler ,( x ./ x ./

Enable x ./ loopback ,( x ./ utility Ra2 DOM ./

x ./ x x Scanner

DISCUSSION

Drawbacks of existing techniques

XSS vulnerability still exists in most web applications because of

1) The difficulty of adopting these methods,

2) The inadequate implementation of these methods,

3) The lack of understanding of XSS problem.

4) The output encoding ends with human error as it can't escape all untreated data.

Drawback of existing tools

1) Only for reflected & persistent XSS type of attacks and not for DOM-based XSS

2) Tool developed based on Java based Web Applications only and HTML, PHP based web applications are not issued.

3) Only server side scripts can be analyzed

4) DOM based requires client-side scripts as this system implies only server side scripts.

These drawbacks of existing systems can be overcome by considering the developer side prevention of XSS vulnerabilities from web applications.

CONCLUSION

In this work, we presented a study on various eliminating methods for the cross-site scripting vulnerability, which plays a vital role in defacement of web applications majorly. The existing papers analyzed here defines an idea to approach further using this three security measures together for eradication of XSSV's in web application for some limit. The limitations defined might not affect the existing system much as they lead to future work to propose a new system of concepts in mitigating the XSS with all other web application languages and in both client and server side. The study states current exposes on removal measures of XSS which can be further extended and analyzed.

REFERENCES

[I] LwinKhinShar, HeeBengKuan Tan, "Automated removal of cross site scripting vulnerabilities in web applications", Information and Software Technology 54 (2012) p.467-478.

[2]Shar, L.K., Tan, H.B.K., "Auditing the XSS defence features implemented in web application programs",Software, TET (2012) (Volume:6 , Issue: 4 ) p.377 - 390

[3] BojanSimic and James Walden, "Eliminating SQL Injection and Cross Site Scripting Using Aspect Oriented Programming", Engineering Secure Software and Systems (2013) p.213-228

[4] Pankaj Sharma, Rahul Johari, S. S. Sarma,"Integrated approach to prevent SQL injection attack and reflected cross site scripting attack", International Journal of System Assurance Engineering and Management, 2012, Volume 3, Issue 4, p.343-35I

[5] Fangqi Sun, Liang Xu, Zhendong Su, "Client-Side Detection of XSS Worms by Monitoring Payload Propagation", Computer Security -ESORICS (2009), Volume 5789, p.539-554

978-1-4673-6524-6115/$ 31.00 © 2015 IEEE

044 1


[6]Neo Kobo, January 2014, Client-Side Attacks.<http://neokobo.blogspot.in /2014_01_05_archive.html>

[7] Security measures, http://www.sitepoint.com/php-security-cross-sitescripting-attacks-xss

[8] OW ASP, OW ASP Top Ten project 2013. http://www.owasp.org

[9] J.H. Hayes, A.J. Offutt "Input validation analysis and testing", Empirical Softw.Eng. II (4) (2006) p.493-522

[10] H. Liu, H.B.K. Tan, 'Testing input validation in web applications through automated model recovery", J. Syst. Softw. 81 (2) (2008) p.222-233

[II] H. Liu, H.B.K. Tan, "Covering code behavior on input validation in functional testing", Inform. Softw. Techno!. 51 (2) (2009) p.546-553

[12]OWASPLAPSE+ Project, http://evalues.es/projects/lapse+/lapse+.html

[13] RIPS, PHP Static Code Analayzer,http://www.php-security.orgl 20 I 0/05 1241 mops-submission-09-rips-a-static-source-code-analyser-forvulnerabilities-in-php scripts/index.html#sec8

[14] OWASP, Microsoft FxCop (.Net), Other Source Code Analyzer tools, <http://msdn.microsoft. com/en -us/l i brary Ibb4 2947 6%28v=vs. 80%29. aspx>

[15] OWASP, ORIZON Project, Source Code Analyzer tools, <https:!/www .owasp. orgiindex.php/Category:OW ASP _ Orizon _Project>

[16] Cenzic Vulnerability Report, Application Vulnerability Trends 2014, www.cenzic.com/downloads/Cenzic_Vulnerability_Report _2014. pdf

[17]WebApplication Security Introduction,<https:!/www.owasp.orglimages/8/ 83/Webappsec_intro.ppt>

[18] Scott, D., Sharp, R.: Abstracting application-level web security. In: II th International Conferenceon the World Wide Web, pp. 396-407(2002).

[19] Hallaraker, 0., Vigna, G.: Detecting Malicious JavaScript Code in Mozilla. In: 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 2005)

[20] Jim, T., Swamy, N., Hicks, M.: Defeating Script Injection Attacks with Browser-Enforced Embedded Policies. International World Wide Web Conference, 2007

[21] Apache patches. http://httpd.apache.orglinfo/css-security/

[22] source forge - xsser tool http://xsser.sourceforge.net/xsser/ XSSeUhe _mosquito _2011. pdf

[23] Fiddler: http://www.herdprotect.com/fiddler.exe-344714aI95c63 9143da5a2675b458a3215e la3 75.aspx

[24] Software Informer - Paros: http://paros.software.informer.com/3.2/

[25] ra2-dom-xss-scanner: https:!/code.google.com/p/ra2-dom-xss-scanner/

[26] OSW AP _CROSS _ SITE_SCRIPTING: https:!/www.owasp.org/

index. php/XSS _(Cross_Site _ Scripting)]revention _ Cheat_ Sheet#XSS ]re venti on Rules

978-1-4673-6524-6115/$ 3l.00 © 2015 IEEE

0442

a study on removal techniques of cross-site from web application

Documents