Project OWASP and two most frequent vulnerabilities in web applications

Transcription

1 Project OWASP and two most frequent vulnerabilities in web applications Filip Šebesta, Wilson Tuladhar 2010

2 Abstract With the rapid use of the Internet, there has been a rapid growth in websites and web applications published into the web using HTTP. This increase has also increased the web hacking activities through viruses, worms, etc. The use of firewall has come into existence for this very problem, to prevent and detect the intrusion so that necessary precautionary measures could be taken. But still hackers have found one way or the other to get around these security walls to infect and extract the unauthorized and confidential information. The web hacking is the result of faults in the web page design or development rather than the firewall issue as web traffic (HTTP) is the most commonly allowed protocol through the Internet firewalls. A web hacker just needs three things: a web browser, an Internet connection and a corrupt intent to damage something. The aim of this document is to present frequent security flaws in web application, namely, SQL injection and cross site scripting. The document covers also security project OWASP, due to the fact that it plays significant role in web security. 1. OWASP Open Web Application Security Project is a community of people which works on creating a methodology and tools for building and maintaining secure web applications. It is developed as open-source, so all of the parts are freely available on the Internet. OWASP is not strictly connected with any special technology nor even a company. It is meant to be free from organizational pressures. OWASP most successful documents and tools include OWASP Top 10, OWASP Guide, WebGoat, WebScrap. 1.1 OWASP Top 10 OWASP Top 10 is an awareness document presented in the form of a list. The list enumerates the most critical vulnerabilities on web sites. It is made by security experts all around the world who share the experience concerning the most frequent security flaws. The document is adopted by wide range of companies as well as government institutions especially in the United States. The last release candidate from 2010 includes following vulnerabilities: A1 Injection A2 Cross Site Scripting (XSS) A3 Broken Authentication and Session Management A4 Insecure Direct Object References A5 Cross Site Request Forgery (CSRF) A6 Security Misconfiguration A7 Failure to Restrict URL Access A8 Unvalidated Redirects and Forwards A9 Insecure Cryptographic Storage A10 - Insufficient Transport Layer Protection 1.2 OWASP Guide This document is a guide which provides practical guidance for all phases of the development of secure web applications. It covers technologies such as J2EE, ASP.NET and PHP and very extensive range of security issues. 1.3 WebGoat WebGoat is a web application which purpose is to build a teaching environment for security lessons. It is deliberatively full of vulnerabilities and the user's task is to find them. I addition, it provides hints and code examples to explain security concepts. 1.4 WebScrap WebScrap is a framework written in Java for analyzing of HTTP and HTTPS communications. It can work as an intercepting proxy. The user is then able to see and modify browser's requests before they are sent to the server 2. Injection Injection is type of attack which aim is to insert unintended commands via user input in order to trick the interpreter of the attacked application into executing malicious code. This makes

3 possible to read, write, create or delete arbitrary data available on the remote machine. There are many types of injections attacks: SQL, XPath, XQuery, XSLT, HTML, XML etc. 2.1 SQL Injection SQL injection (sometimes called SQL insertion) is an attack that allows an malicious user to manipulate SQL statements within an application and modify its action. It is one of the most common methods of data theft. 2.2 Impact of SQL injection After successful exploitation the attacker may be able to perform: modification of database data execution of administration operations recovery of a given file present on the database file system issuing commands to the OS 2.3 Example Following example demonstrates the process of exploiting SQL injection vulnerability. This statements send a query to the database: users WHERE name = '" + typedname + "';" If an user types following statement as a name : a' or 'b'='b the application program construct the query in form of: users WHERE name = 'a' or 'b'='b';" This can threat the authorization procedure due to the fact that 'b' = 'b' is always true. We can also use all possible SQL commands. For example, the following statement a';drop TABLE users; -- makes the application program construct following query: users WHERE name = 'a';drop TABLE users; --';" The query will erase the table of users. The last semicolon is commented, therefore it makes no effect. There are plenty of attacks on similar base. With commands UNION and JOIN we are even able to list data from any part of the database, not only from the part specified in the sensed query. 2.4 Preventing SQL injection attacks Prevention of the SQL attack may take place on application layer as well as inside the database. Application layer The easies way to prevent SQL injection on the application layer is to sanitize the user input. The special characters should be processed in an appropriate manner. Generally, every scripting language includes a function for transition potentially harmful characters in to a safe sequence. See an example in PHP for MySQL: $sql = "SELECT * FROM users WHERE name = ". mysql_real_escape_string($typedn ame); mysql_query($sql); //or else $typedname=htmlspecialchars($typ edname, ENT_QUOTES); $sql = "SELECT * FROM users WHERE name='{$typedname}'"; mysql_query($sql); Inside the database We may also set up the DBMS to avoid SQL injection or at least make it harder. Basically, user's privileges should contains only necessary actions. In most of cases it means that it should

4 not be possible to delete the tables or perform other undesirable actions. 3. Cross-site Scripting (XSS) Cross-site scripting (XSS) is one of the computer security vulnerabilities found typically in web applications which enable malicious attackers to inject client-site script into web pages which are viewed by others. The sites that are dynamically created are the target for such kind of attacks because these dynamically created sites have no control over how the client will interpret it. So, an attacker will use this information to his advantage. He can use exploiting XSS vulnerability to bypass the access control such as the same origin policy. So the impact of the vulnerability ranges from general annoyance to the general users to major security risks depending upon the data / web pages being exploited and what security majors have been taken by the owner of the web page. The attack proceeds with the attacker injecting some malicious code / scripts into the web pages and hence gaining an elevated access privilege to sensitive page content, session cookies and variety of other information maintained by the browser on behalf of the user. The major flaws to this kind of attack being successful are when the web application accepts inputs through untrusted source through web request and when the data is included in the dynamic contents are sent to the web user without being validated for the malicious code. The malicious code generally takes the form of client-side scripting languages like JavaScript or some other forms of scripts that are executed by the browser like Flash, HTML, Java, VBScript, etc. There are lots of ways to attack based on XSS, but the most common ones are transmission of private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. XSS attacks are categorized into three categories: 1. Stored XSS Attacks 2. Reflected XSS Attacks 3. DOM based XSS Attacks 3.1 Stored XSS Attacks In stored XSS attacks, the malicious code is stored in the web server permanently may that be in a database, a message forum or any other way. The victim (general user) receives the malicious code when it requests the stored information. 3.2 Reflected XSS Attacks As the name suggests, these attacks occur when the malicious codes are reflected from the web server such as search result, error message, etc. In reflected attacks, a user gets tricked into clicking on a fake link or submitting a fake form which acts as a trigger to inject the malicious code to the vulnerable web server which then reflects the attack back to the user s browser. The browser thinks that the code came from the trusted server and executes it. 3.3 DOM Based XSS Attack DOM Based XSS, also called type-0 XSS, is an XSS attack that occurs not due to flaw in the server side but due to modification of the DOM environment in the client s browser. Here the clients DOM environment is altered such that the client side code runs in an unexpected manner i.e. the actual HTTP response does not change but the code after reaching the clients machine executes in different than it usually should due to the modification of the DOM environment by the malicious code. Some Examples of how the attack actual works XSS attacks are conducted with or without <script></script> tags. Let s say that a URL to the site is like shown below language=swedish Here, the developer s intension was to get the language setting for the site, but the attacker on the other hand would send modify the URL with DOM based XSS to

5 language=<script>alert(document. cookie)</alert> Now when the victim clicks this link, the browser will seen a request for /index.html? language=<script>alert(document.cookie)</alert > to The server will then respond to this which in turn will lead to the browser creating a DOM object for the page, in which the document.location object contains the above string which will result in the browser rendering the attacker s script. In this case, however, the server could find out that the script and the attacker s intension as the full URL is sent to the server-side. But if the above link is modified as anguage=<script>alert(document.c ookie)</alert> Then, the part of the URL after # is not sent to the server and the result could still be the same. Some examples without the script tag are: <body onload=alert( something )> <bonmouseover=alert( mouse over )> Click here</> 3.4 How to check for the XSS vulnerabilities? There are tools available to check for the XSS vulnerabilities in one s site. One of them is Web Vulnerability Scanner which crawls through the entire website and checks for XSS vulnerabilities. It will trace out the URLs and scripts which are suspicious to be vulnerable to these attacks. It will also check for the possible SQL injection check and other web vulnerabilities also. Cookie Security This method is not for prevention of XSS attack rather to be precautions if such kind of attacks attempts to steal the cookie. The website could tie up the session cookie to the users IP and allow only that user to access the cookie. Disable scripts Since XSS is a client based scripting attack, it would not be effective if the client disables the JavaScript option in his browser. The malicious code would reach the clients browser but will not be executed. 4. References [1] OWASP Testing Guide v3.0, 2008 [2] on, last revision 6 th of March 2010 [3] last revision 6 th of March 2010 [4] last revision 6 th of March 2010 [5] XSS, last revision 6 th of March Preventing Cross Site Scripting (XSS) attacks Proper validation and Escaping The validation of the user input must be carried out and reject or escape all undesirable characters if such scripts are found at the user input. These should be filtered out both in their ASCII and HEX values.