Paper Title (use style: paper title)

Download PDF
3 downloads 775 Views 766KB Size Report
Comment
JavaScript from the attacker with the privileges of a trusted host. Most existing approaches .... developer to analyze their web application periodically and apply a ...
International Journal of Computer Information Systems, Vol. 3, No. 2, 2011

A New Server-Side Solution for Detecting Cross Site Scripting Attack Tawfiq S. Barhoom

Sarah N. Kohail

Faculty of Information Technology Islamic University of Gaza Gaza, Palestine [email protected]

Faculty of Information Technology Islamic University of Gaza Gaza, Palestine [email protected]

Abstract— Web applications support many of our daily activities, but they often have security problems, and their accessibility makes them easy to exploit. Cross Site Scripting (XSS) is one of the most common web application vulnerabilities in which an attacker causes a victim’s browser to execute JavaScript from the attacker with the privileges of a trusted host. Most existing approaches to finding XSS vulnerabilities have not been applied in a universal manner, because of their deployment overhead and the poor understanding of XSS problems. In our paper we propose a new server side solution to detect and block XSS attack. Using the Extensible Markup Language (XML) and XML Schema Definition (XSD) our solution enforces the input type integrity by preventing untrusted user input from altering the structure of the trusted code through the execution life time of the web application. At the end of the paper we apply a set of extermination to support our idea proposed. The results show that our solution can detect any injected script breaks the input schema rules. Keywords- web security, cross site scripting, web document integrity.

I.

INTRODUCTION

Web application have become one of the important means of information communication and presentation of governments and business. The rapid growth of dynamic web application and the wide accessibility to them resulted in rapacious impact of security flaws in such application. Breach of security in such application may lead to a violation of privacy and sensitive information theft. Cross Site Scripting (or XSS), is one of the most common web application attack. Web Hacking Incident Database for 2011 (WHID) show that XSS attack methods are the second most popular and harmful [11]. Unlike most attacks, which involve two parties the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties the attacker, a client and the web site. XSS occurs when a web application gathers malicious data from attackers. The data is usually gathered in the form of hyperlink which contains malicious content (e.g., JavaScript) within it. The attackers may put the link in a website, web boards or in an email. Once the users click on the link, the malicious JavaScript code will run at the victim (client) browser, with the “access privileges” of the web site [10].

August Issue

In this paper we propose a new server side solution to detect and protect from XSS attack by preserving the web document input structure integrity. This is done by storing the XSD schema of input fields and dynamic parts of the web application pages. So any attempt by the hacker to break the stored schema will be detected. The rest of this paper is organized as follows: Section 2 give a brief background about XSS problem. Section 3 presents some related works. Section 4 describes the proposed solution. Section 5 present and discuss our experimentation results and evaluation. Finally conclusions and future work are presented in the last section. II.

CROSS SITE SCRIPTING ATTACK

Cross site scripting attacks (XSS), are an important class of attacks against web-based applications. These attacks exploit trust relationships between web servers and web browsers by injecting a script (often written in JavaScript) into a server that is not under the control of the attacker [12]. XSS can lead to many malicious results like identity theft, accessing sensitive or restricted information, altering browser functionality and denial of service (DOS) attacks [4]. There are two known variants of cross site scripting: reflected and stored. The easiest to exploit most common type is Reflected XSS in which a page reflects user supplied data directly back to the user. For example let’s say we are taking some information passed in on a querystring (the string after the (?) character within a URL), with the purpose of displaying the content of a variable, for example, the visitor’s name: http://www.trustedsite.com/welcomepage.php?name=your name Note that we are passing the visitor’s name as a parameter in the URL, and then displaying it on “welcomepage.php” page with the following code: The attacker can exploit this weak implementation and modify the URL by replacing the visitor’s name passed in the URL as follows: http://www.trustedsite.com/welcomepage.php?setInterval("window.open('http://ww w.anothersite.com/','innerName')",100);

Page 19 of 107

ISSN 2229 5208

Consider a case where the attacker sends this URL by e-mail to a group of victims. The inserted script make a request for the anotherdsite.com index page every 100 milliseconds for one hit by a victim. This is extremely dangerous where this code will heavily overload the anothersite server and maybe generate a Denial of Service condition by denying access to other visitors requesting the same page (or other pages). Stored XSS occur when insufficiently validated user inputs are persistently stored on the server side (file, a database, or other back end system) and later displayed in dynamically generated Web pages for others to read [4]. This is extremely dangerous in systems such as blogs, or forums, where a large number of users will see input from other persons. The following message board code clarifies stored XSS attack.
This code simply takes a post from user through text field. When the user submit his post will send to savepost.php page through POST method. Code at savepost.php presented below will open a file for writing, set the pointer at the end, write the content of user post and then read and display all posts. Imagine if the attacker enter the following post: document.location = 'http://attack.evil.org/steal_cookies.php?cookies=' + document.cookie The next user who visits this message board with JavaScript enabled will redirected to attacker.evil.org, and any cookies associated with the current site are included in the query string of the URL. III.

RELATED WORK

Cross site scripting is well known in the internet community from several years [6]. Programmer used many practices to mitigate the risk of XSS like filtering all external data using existing functions and whitelist approach [10]. Unfortunately these practices can lead to many false negative and increase the burden required from web developers. Wassermann and Su [8] propose a static analysis approach which check the adequacy of sanitization functions. this approach help the developer to analyze their web application periodically and apply a vulnerability analysis tool to provide a level of

August Issue

International Journal of Computer Information Systems, Vol. 3, No. 2, 2011 assurance that no security-relevant flaws are present. Based on string analysis techniques, they use blacklist comparison approach to check whether tainted strings may still contain the blacklisted characters at sensitive program points after passing through sanitization functions. Web browser and email application vendors understand the danger of XSS so they give the users a possibility to disable all scripting language support in user’s browsers and e-mail readers. If this is not a feasible option for business reasons, another recommendation is to use reasonable alert when clicking links in anonymous e-mails and dubious web pages [3]. Also keeping up to date with the latest browser patches and versions is important in protecting against XSS in client side. Both disabling scripting language and keeping browsers up to date depend on how many of users are aware of the XSS attack and how can easily they can deal with the configurations and options [7]. Since today, there is no universal applied solution for XSS attack. Several research tried to invent a new solutions that is independent to programming language or browser used [6][5]. We can classify the existing XSS solutions based on the point of deployment to server side solutions [6][2] or client side solutions [3][4][7]. Noxes [4] is a client side personal web firewall that allows the user to create, modify, and delete filter rules (i.e., firewall rules) for web requests manually or by tracking the user browsing behavior. At [3] Ismail et al. implemented a client side proxy that can be used to protect a user while surfing the web. The proxy analyzes the HTTP traffic exchanged between the user’s browser and the contacted web server. Client requests are scanned for special HTML characters. Also before delivering any server response to user’s browser the special characters are encoded which disables the attempted attack. For client side solution it’s hard to protect the client immediately when a new vulnerability is introduced till the automatic download takes place and installed in client place [6]. Also some client side solutions degrade the performance of client’s system resulting in a poor web surfing experience. To overcome these problems Tiwari et al. [7] propose a step by step approach to check for scripts tags in the input by analyzing the existence of special characters and monitoring the flow of data. Most XSS solutions are server side where researchers think that it’s better to be installed in the same place where the web application is. Shanmugam and Ponnavaikko [6] introduce a signature based server side solution cover many web application languages and improve the response time. Another server side framework is XSS-GUARD by Bisht and Venkatakrishnan [2]. XSS-Guard compares the script contents present in the real page with web-application intended contents, present in the shadow page (the pages that retain the “authorized” scripts that were intended by the web application to be included without any injected scripts). Any “difference” detected here indicates a deviation from the web application’s intentions, and therefore signals an attack. Server side solutions in general must avoid excessive checking and filtering of XSS, where this can severely degrade the performance of the web server. Saxena et al. [5] claim that

Page 20 of 107

ISSN 2229 5208

purely server-side or client side defenses are insufficient. Each of them completes the role of other and the defense must address attacks that target server-side as well as client-side languages. The idea behind [5] is to identify and isolate nodes derived from user-generated data, in the parse tree during parsing. The author work to prevent the untrusted nodes from changing the intended web document structure. Complexity and diversity of XSS methods and format, web programming languages and browser application make it difficult to build a general and universal solution. Some solutions like Xhunter [1] have focused only on XSS attacks that are carried out using URLs. XHunter tool monitor the network for identifying suspicious URLs. IV.

PROPOSED SOLUTION

We devote our research to solve stored XSS attacks and apply it for PHP and HTML web programming language. We believe that danger of XSS attack comes from two sources: the first is $_GET and $_POST input that is used in HTTP requests. Second source is the dynamic printing and display message fetched from database or any external file. This makes dynamic pages are vulnerable to XSS where static pages are immune to this type of attack because they have full control over how their web pages will be interpreted.

International Journal of Computer Information Systems, Vol. 3, No. 2, 2011 A. Select any possible input portion in the web page. In this step, any possible input field for the user will be selected. An indication for this is tags. The tag is used to create an HTML form for user input. A form can contain input elements like text fields, checkboxes, radiobuttons, submit buttons and more. A form can also contain select menus, textarea, fieldset, legend, and label elements. Forms are used to pass data to a server using the two methods POST and GET. Selected parts of the web page will be passed to next step. Figure 2 illustrate a simple example for a selected form.

1 2 3 4 5




Figure 2. An example of selected form B. Generate the corresponding XSD schema for the selected parts. In this step, an XSD schema will be generated for the selected parts in step 1. To clarify the idea Figure 3 illustrate the generated schema for example in Figure 2. Note that the element name and type derived from attributes. Type of allowed input is set to string because the type of the input in the form is set to text. C. Store the generated schema at permanent storage. After generating the corresponding schema, it will be stored at a permanent storage. This is considered to preserve the structure of input allowed.

1 2 3 4 5 6

Figure 1. Approach Overview Figure 1 present our approach overview. This involves generating an XML document for the dynamic portions in the web page requested by the user. Based on the selected portions a schema will be generated and stored. When the user request any page and submit his input back to server, the user input will stored at XML document and validated to the corresponding stored XSD schema. Any malicious script will end up creating an invalid or not-well-formed XML, and thus the schema will not match the XML document generated from the user input. Our approach includes three main components each of them will be described in the following sub sections.

August Issue



Figure 3. generated schema for example in Figure 2 All the previous three steps will be applied for all pages at the web application as initial step. When the user request the form in Figure 2 and submit his message back to server, the input of user will be stored at XML file and validated to the real schema stored at the beginning. Any malicious script will make the XML document of user inputs to be invalid to the stored schema.

Page 21 of 107

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 2, 2011 Developer can contribute to generate a more advance schema. Advance example illustrated at Figure 7. Assume a message forum with required text message optional image. The minOccurs attribute specify the minimum images at the user board and its assigned to 0 that make the image at user post optional . I. IMPLEMENTATION AND EVALUATION

Figure 4. Example of Attacker input that cause XSS attack Assume the input illustrated in Figure 4. When this input stored in XML file and validated to schema in Figure 3, it will not match the schema because the structure of the input changed. The schema that matches the attacker input illustrated in Figure 5. The difference between the two schemas is clear in Figure 6. A new element inside message element is added.

1 2 3 4 5 6 7 8 9 10 11 12 13

Using Stylus Studio 2011 XML Enterprise Suite and a simple PHP program the proposed solution has been tested with thousands of malicious inputs, non vulnerable input with white listed tags and vulnerable websites. We try a set of XSS attack listed in [9]. The results show that our solution can detect any injected script breaks the input schema rules.

1 2 3 4 5 6 7 8







Figure 7. Example of message forum with optional image



II. CONCLUSION AND FUTURE WORK



Figure 5. Schema associated with attacker input at Figure 4 To ensure that printing back dynamic printing and display message fetched from database or any external file do not include any XSS vulnerability each external file and database record will be restricted to XSD schema. This will increase the degree of security and take into consideration any possibility of database or files content modification.

As usually, dealing with user input data is a very sensitive issue, and Cross Site Scripting falls under this category. This paper presents a server-side solution to effectively detect and block XSS attack for pages written in HTML and PHP programming languages. The idea is to store the allowed input structure in from of XSD schema file, so any malicious script will end up creating an invalid or not-well-formed XML, and thus the schema will not match the XML document generated from the user input. We try a set of XSS attack listed in [9]. The results show that our solution can detect any injected script breaks the input schema rules. Using XML make our solution platform independent. Our approach is better than DOM tree tracing in which it chose only the dangerous portions but this require some effort from developer.

Figure 6. Tree illustration of difference between stored schema and generated schema from user input

August Issue

Page 22 of 107

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 2, 2011 Our future will include a full implementation for methodology. Also we will try to reduce the load on the server by giving some part of the work to client side where huge number of requests can reduce the performance of massive visitors server in open network. REFERENCES [1]

Athanasopoulos, E.; Krithinakis,A.; Markatos, E.;,"Hunting Cross-Site Scripting Attacks in the Network," workshop of Web 2.0 Security & Privacy. 2010. [2] Bisht, P. and Venkatakrishnan, V.; "XSS-GUARD: Precise dynamic prevention of cross-site scripting attacks," in 5th Conference on Detection of Intrusions & Malware, and Vulnerability Assessment, Paris, France, Jul. 2008. [3] Ismail, O.; Etoh, M.; Kadobayashi, Y.; Yamaguchi, S.;, "A proposal and implementation of automatic detection/collection system for cross-site scripting vulnerability," Advanced Information Networking and Applications, vol.1, no., pp. 145- 151. 2004. [4] Kirda, E.; Jovanovic, N.; Kruegel, C.; Vigna, G.;, "Client-side cross-site scripting protection,", Computers & Security, vol.28, pp. 592-604. 2009. [5] Saxena, P.; Song, D.; Nadji, Y.; “Document structure integrity: A robust basis for cross-site scripting defense, " in 16th Annual Network & Distributed System Security Symposium, San Diego, CA, USA, Feb. 2009. [6] Shanmugam, J.; Ponnavaikko, M.; , "Risk mitigation for cross site scripting attacks using signature based model on the server side," Computer and Computational Sciences, 2007. IMSCCS 2007. Second International Multi-Symposiums on, pp.398-405, 13-15 Aug. 2007. [7] Tiwari, S.; Bansal, R.; Bansal, D.; , "Optimized client side solution for cross site scripting," Networks, 2008. ICON 2008. 16th IEEE International Conference on , pp.1-4, 12-14 Dec. 2008. [8] Wassermann, G. and Su, Z.; "Static Detection of CrossSite Scripting Vulnerabilities," In Proceedings of the 30th International Conference on Software Engineering, May 2008. [9] http://ha.ckers.org/xss.html. [10] http://phpsec.org/projects/guide/2.html. [11] http://www.acunetix.com/websitesecurity/cross-sitescripting.htm. [12] http://www.acunetix.com/websitesecurity/xss.htm.

August Issue

Page 23 of 107

AUTHORS PROFILE Dr. Tawfiq S. Barhoom received his Ph.D degree from ShangHai Jiao Tong University (SJTU), in 2004. This author is head of computer science department, faculty of IT, Islamic University-Gaza. His current interest research include Design Patterns, Secure Software, Modeling, XMLs security, Web services and its Applications and Information retrieving.

Sarah N. Kohail received her BSc in Software Development in 2009 from the Islamic university of Gaza, Palestine. She is MSc student in Information Technology at the same university. Her area of research is Data Mining , Machine Learning and Web Services.

ISSN 2229 5208