Security Vulnerabilities in a Web Application

Application Related Security Vulnerabilities in a Web Application

APPLICATION RELATED SECURITY VULNERABILITIES IN A WEB 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. 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. ®Rational

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

5 1 APPLICATION RELATED VULNERABILITIES...... ............ ............ ............. ............. ........... ......... ........ ........ ........ ......6 Cross-Site Scripting..................................................................................................................................................................7 Security Risks........................................................................................................................................................................7 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... .............................................7 ...................................7 Technical Description............................................................................................................................................................7 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................11 .........................11 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................11 ..............................11 Stored Cross-Site Scripting...................................................................................................................................................12 Security Risks......................................................................................................................................................................12 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................12 .................................12 Technical Description..........................................................................................................................................................12 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................16 .........................16 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................16 ..............................16 SQL Injection..........................................................................................................................................................................17 Security Risks......................................................................................................................................................................17 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................17 .................................17 Technical Description..........................................................................................................................................................17 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................18 .........................18 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................19 ..............................19 Database Error Pattern Found.............................................................................................................................................20 Security Risks......................................................................................................................................................................20 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................20 .................................20 Technical Description..........................................................................................................................................................20 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................21 .........................21 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................22 ..............................22 SQL Query in Parameter Value............................................................................................................................................23 Security Risks......................................................................................................................................................................23 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................23 .................................23 Technical Description..........................................................................................................................................................23 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................23 .........................23 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................23 ..............................23 Cross-Site Request Forgery...................................................................................................................................................24 Security Risks......................................................................................................................................................................24 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................24 .................................24 Technical Description..........................................................................................................................................................24 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................25 .........................25 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................25 ..............................25 Link Injection (facilitates Cross-Site Request Forgery).....................................................................................................26 Security Risks......................................................................................................................................................................26 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................26 .................................26 Technical Description..........................................................................................................................................................26 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................27 .........................27

-3-

Application Related Security Vulnerabilities in a Web Application References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................27 ..............................27 Phishing through Frames......................................................................................................................................................28 Security Risks......................................................................................................................................................................28 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................28 .................................28 Technical Description..........................................................................................................................................................28 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................28 .........................28 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................28 ..............................28 Permanent Cookie Contains Sensitive Session Information..............................................................................................29 Security Risks......................................................................................................................................................................29 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................29 .................................29 Technical Description..........................................................................................................................................................29 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................29 .........................29 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................29 ..............................29 Session Not Invalidated After Logout..................................................................................................................................30 Security Risks......................................................................................................................................................................30 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................30 .................................30 Technical Description..........................................................................................................................................................30 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................30 .........................30 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................30 ..............................30 Cacheable SSL Page Found...................................................................................................................................................31 Security Risks......................................................................................................................................................................31 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................31 .................................31 Technical Description..........................................................................................................................................................31 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................31 .........................31 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................31 ..............................31 HTML Comments Sensitive Information Disclosure.........................................................................................................32 Security Risks......................................................................................................................................................................32 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................32 .................................32 Technical Description..........................................................................................................................................................32 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................32 .........................32 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................32 ..............................32 Missing Secure Attribute in Encrypted Session (SSL) Cookie..........................................................................................33 Security Risks......................................................................................................................................................................33 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................33 .................................33 Technical Description..........................................................................................................................................................33 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................33 .........................33 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................33 ..............................33 Query Parameter in SSL Request.........................................................................................................................................34 Security Risks......................................................................................................................................................................34 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................34 .................................34 Technical Description..........................................................................................................................................................34 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................34 .........................34 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................34 ..............................34 Cacheable Login Page Found................................................................................................................................................35 Security Risks......................................................................................................................................................................35 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................35 .................................35 Technical Description..........................................................................................................................................................35 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................35 .........................35 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................35 ..............................35

-4-

Application Related Security Vulnerabilities in a Web Application Session Identifier Not Updated.............................................................................................................................................36 Security Risks......................................................................................................................................................................36 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................36 .................................36 Technical Description..........................................................................................................................................................36 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................37 .........................37 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................37 ..............................37 Inadequate Account Lockout................................................................................................................................................38 Security Risks......................................................................................................................................................................38 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................38 .................................38 Technical Description..........................................................................................................................................................38 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................38 .........................38 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................38 ..............................38 Authentication Bypass Using SQL Injection.......................................................................................................................39 Security Risks......................................................................................................................................................................39 Possible Causes................ Causes.......................... ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ...........................................39 .................................39 Technical Description..........................................................................................................................................................39 General Fix Recommendations.......... Recommendations.................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ...................................39 .........................39 References and Relevant Links............... Links.......................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................... ........................................40 ..............................40

-5-


1

Appli Applicat cation ion Re Relat lated ed Vulne Vulnerab rabili ilitie ties s

Contents 1. Cros Crosss-Si Site te Scr Scrip ipti ting ng 2. Stored Stored CrossCross-Sit Site e Scri Scripti pting ng 3. SQL Query Query in Paramet Parameter er Valu Value e 4. Cros Crosss-Si Site te Reque Request st Forge Forgery ry 5. Link Inject Injection ion (facil (facilitates itates Cross-Site Cross-Site Request Request Forgery) Forgery) 6. Phis Phishi hing ng thro throug ugh h Frame Frames s 7. Permanent Permanent Cookie Cookie Contain Contains s Sensitive Sensitive Session Session Informat Information ion 8. Sessio Session n Not Inva Invalid lidate ated d After After Logout Logout 9. Cach Cacheab eable le SSL SSL Pag Page e Foun Found d 10. HTML Comments Sensitive Sensitive Information Disclosure 11. Missing Secure Attribute Attribute in Encrypted Session (SSL) Cookie 12. Query Parameter Parameter in SSL Request Request

-6-


Cross-Site Scripting

Security Risks It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Possible Causes Sanitation of hazardous characters was not performed correctly on user input. Technical Description The The CrossCross-Sit Site e Script Scripting ing attack attack is a privac privacy y viola violatio tion, n, that that allows allows an attack attacker er to acquir acquire e a legiti legitimat mate e user's user's creden credentia tials ls and to imperso impersonat nate e that that user user when when interac interactin ting g with with a specif specific ic website. The attack hinges on the fact that the web site contains a script that returns a user's input (usually a parame parameter ter value) value) in an HTML HTML page, page, withou withoutt first first saniti sanitizin zing g the input. input. This This allows allows an input 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 the user'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 website 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 le gitimate 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 Explor Explorer er to show show the vulnera vulnerabil bility ity.. In the case of varian variants ts to which which Intern Internet et Explor Explorer er 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 crosssite scripting: -7-

Application Related Security Vulnerabilities in a Web Application A. The parameter parameter value sent to the CGI script is returned in the response response page, embedded in the HTML. For example: [request] GET /cgi-bin/script.pl?name=JSmith HTTP/1.0 [response] HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 27 Hello JSmith 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 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 254 Please fill in your zip code:
t.pl">

Example 1 - scenario A The following request is sent by the user: [attack request] GET /cgi-b -biin/script.p .pll?name=>"'><script>aler ertt('Wat atc chfire% e%2 20XSS%20Test %20Successful') HTTP/1.0 [attack response scenario A] HTTP/1.1 200 OK Server: SomeServer 4/21/2009 8:10:17 AM 233/350 Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 83 Hello >"'><script>alert('Watchfire XSS Test Successful') pt> In this case, the JavaScript code will be executed by the browser (The >"'> part is irrelevant here). Example 2 - scenario B Using the same script and input as in Example 1 to invoke the attack: [attack response scenario B] HTTP/1.1 200 OK Server: SomeServer -8-

Application Related Security Vulnerabilities in a Web Application Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 310 Please fill in your zip code:
t.pl"> <script>alert('Watchfire XSS Test Successful') ">

The >"'> prefix is used to break out of the parameter value context. Closing the parameter value field ( "'> ) and then closing the 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 Te st Successful') [2] >"><script>alert("Watchfire XSS Test Successful") Successful") [3] <script>alert('Watchfire XSS Test Successful') Successful') [4] >"'> [5] >"'> [6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA=" [7] --><script>alert('Watchfire XSS Test Successful') Successful') [8] '+alert('Watchfire XSS Test Successful')+' [9] "+alert('Watchfire XSS Test Successful')+" [10] >'><%00script>alert('Watchfire XSS Test Successful') (.NET 1.1 specific variant) [11] >"><%00script>alert("Watchfire XSS Test Successful") (.NET 1.1 specific variant) [12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SC >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4RIPT+AD4[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire% 5%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 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-<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 resulting response 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 data submi submitte tted d by a client client browse browserr and raises raises an except exception ion if potent potential ially ly danger dangerous ous data 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.1 ASP.NET 1.1 blocks input containing '<' followed by an alphanumeric character or an exclamation mark (e.g. <script> , <img, <script>alert('Watchfire XSS Test Successful') Successful') [8] '+alert('Watchfire XSS Test Successful')+' [9] "+alert('Watchfire XSS Test Successful')+" [10] >'><%00script>alert('Watchfire XSS Test Successful') (.NET 1.1 specific variant) [11] >"><%00script>alert("Watchfire XSS Test Successful") (.NET 1.1 specific variant) [12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SC >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4RIPT+AD4[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire% 5%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 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 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 resulting response 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 data submi submitte tted d by a client client browse browserr and raises raises an except exception ion if potent potential ially ly danger dangerous ous data 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.1 ASP.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.1 In 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 securi security ty proble problem m presen presented ted above, above, any HTML tag can be inject injected ed throug through h ASP.NE ASP.NET T 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 anothe anotherr charset charset encodi encoding ng is alread already y enforc enforced. ed. This This automa automatic tic encodi encoding ng featur feature e may help 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 e ncoding enforcement (unless utf-7 is enforced) in: - 15 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application [*] 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 Test varian variantt [13]: [13]: The purpos purpose e of this this varian variantt is to exploi exploitt the way Intern Internetet-Exp Explor lorer er treats 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. General Fix Recommendations There are several issues whose remediation lies in sanitizing user input. By verify verifying ing that that user user input input does does not contai contain n hazard hazardous ous charac characters ters,, it is possib possible le to preven preventt malicious users from causing your application to execute unintended operations, such as launch arbitr arbitrary ary SQL queries, queries, embed embed Javasc Javascrip riptt code code to be execut executed ed on the client client side, side, run various 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) References and Relevant Links CERT Advisory CA-2000-02 Microsoft How To: Prevent Cross-Site Scripting Security Issues (Q252985) Microsoft How To: Prevent Cross-Site Scripting in ASP.NET Microsoft How To: Protect From Injection Attacks in ASP.NET Microsoft How To: Use Regular Expressions to Constrain Input in ASP.NET Microsoft .NET Anti-Cross Site Scripting Library Cross-Site Scripting Training Module<br /> <br /> - 16 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> SQL Injection<br /> <br /> Security Risks It is possible to view, modify or delete database entries and tables. Possible Causes Sanitation of hazardous characters was not performed performed correctly on user input. Technical Description 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 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 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 differen differentt data yanking yanking query, query, a query query that modifies modifies the database database,, or a query 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 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 The attack attacker er is inform informed ed that that the query query is built built around around the expre expressi ssion on userna username me='$ ='$use user' r' AND password=' password='$pas $pass'. s'. This crucial crucial informati information on is needed needed to exploit exploit the SQL query at hand. hand. When When the attacker understands understands the format of the query, his next step would simply be to use: user = ' or 1=1 or ''=' password = foobar The 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<br /> <br /> - 17 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 The follow following ing input input strin strings gs can be used used to yield yield sensi sensiti tive ve infor informat mation ion from from syste system m tables tables in the 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 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 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 injection payload sent: ' || UTL_HTTP.REQUEST('htt UTL_HTTP.REQUEST('http://IP_Addre p://IP_Address:80/SQL_In ss:80/SQL_Injection_Val jection_Validation') idation') || ' Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' 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/ ('http://IP_Address:80/SQL_Inject SQL_Injection_Validation ion_Validation') ') || '' AND password='$pass' 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_Validati '/SQL_Injection_Validation' on' 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' 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=DB ('sqloledb','Network=DBMSSOCN;Ad MSSOCN;Address=[IP_Ad dress=[IP_Address],999 dress],9999;uid=myUsr;p 9;uid=myUsr;pwd=myPass', wd=myPass','select '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.<br /> <br /> 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. - 18 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 (backslash-escaped quotation mark) [11] <> (triangular parenthesis) parenthesis) [12] () (parenthesis) [13] + (plus sign) [14] CR (Carriage return, ASCII 0x0d) [15] LF (Line feed, ASCII 0x0a) [16] , (comma sign) [17] \ (backslash)<br /> <br /> References and Relevant Links "Web Application Disassembly with ODBC Error Messages" (By David Litchfield) SQL Injection Training Module<br /> <br /> - 19 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Database Error Pattern Found<br /> <br /> Security Risks It is possible to view, modify or delete database entries and tables. Possible Causes Sanitation of hazardous characters was not performed performed correctly on user input. Technical Description AppScan discovered 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 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 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 differen differentt data yanking yanking query, query, a query query that modifies modifies the database database,, or a query 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 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 atta attack cker er is info inform rmed ed that that the the quer query y is buil builtt arou around nd the the expr expres essi sion on user userna name me=' ='$u $use ser' r' AND AND password=' password='$pas $pass'. s'. This crucial crucial informati information on is needed needed to exploit exploit the SQL query at hand. hand. When When the attacker understands understands the format of the query, his next step would simply be to use: user = ' or 1=1 or ''=' password = foobar The 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",<br /> <br /> - 20 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 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 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. 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_Add UTL_HTTP.REQUEST('http://IP_Address:80/SQL ress:80/SQL_Injection_V _Injection_Validation') alidation') || ' Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' 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/ ('http://IP_Address:80/SQL_Inject SQL_Injection_Validation ion_Validation') ') || '' AND password='$pass' 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_Validati '/SQL_Injection_Validation' on' 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=DBM ('sqloledb','Network=DBMSSOCN;A SSOCN;Address=IP_Add ddress=IP_Address,9999; ress,9999;uid=myUsr;pwd uid=myUsr;pwd=myPass','sel =myPass','select ect foo from bar')-Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user' 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=DB ('sqloledb','Network=DBMSSOCN;Ad MSSOCN;Address=[IP_Ad dress=[IP_Address],999 dress],9999;uid=myUsr;p 9;uid=myUsr;pwd=myPass', wd=myPass','select '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.<br /> <br /> General Fix Recommendations If the error indicates a SQL Injection vulnerability, please follow the following guidelines: - 21 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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, queries, embed Javascript Javascript code to be execute executed d on the client client side, side, run various operating 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 (backslash-escaped quotation mark) [11] <> (triangular parenthesis) parenthesis) [12] () (parenthesis) [13] + (plus sign) [14] CR (Carriage return, ASCII 0x0d) [15] LF (Line feed, ASCII 0x0a) [16] , (comma sign) [17] \ (backslash)<br /> <br /> References and Relevant Links "Web Application Disassembly with ODBC Error Messages" (By David Litchfield) SQL Injection Training Module<br /> <br /> - 22 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> SQL Query in Parameter Value<br /> <br /> Security Risks It is possible to view, modify or delete database entries and tables. Possible Causes Parameter values were 'hardcoded' in the HTML as a parameter of type 'hidden'. Technical Description Web applic applicati ations ons often often use use databa databases ses at the backen backend d to interac interactt with with the enterp enterpris rise e data 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> General Fix Recommendations [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.<br /> <br /> References and Relevant Links WASC Threat Classification: SQL Injection SQL Injection Training Module CWE-89: Failure to Preserve SQL Query Structure ('SQL Injection')<br /> <br /> - 23 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Cross-Site Request Forgery<br /> <br /> Security Risks It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Possible Causes Insufficient authentication method was used by the application. Technical Description 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 user's creden credentia tials ls (like (like sessio session n cookie cookies, s, user's user's IP addres address, s, and other other browse browserr authen authentic ticati ation on 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 re quest 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 Using Cross Cross-Si -Site te Script Scripting ing or Link Link Inject Injection ion vulner vulnerabi abilit lities ies in the site site (or anothe anotherr site) site) and automatically redirecting the browser to the vulnerable site. If the attacker attacker uses a Link Injection Injection vulnerability vulnerability on the vulnerable vulnerable site itself itself he or she increases 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, options, an attacker attacker can lure the victim to view a page containing: <img src="http://bank/transfer?destinatio src="http://bank/transfer?destination=John&money=1000" n=John&money=1000" style='visibili style='visibility:hidden'> ty: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, CrossSite 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<br /> <br /> - 24 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application An application application that contains contains a sensitive sensitive action, action, which can be accessed accessed directly by a request 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 atta attack cker' er's s usern usernam ame e and and pass passwo word rd.. Logi Login n CSRF CSRF atta attack cks s can can have have seri seriou ous s cons conseq eque uenc nces es,, 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. General Fix Recommendations In order order to avoid avoid CSRF CSRF attack attacks, s, every every request request should should contain contain a uniqu unique e identi identifie fier, r, which 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 attacker cannot 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. References and Relevant Links Cross-site request forgery wiki page "JavaScript Hijacking" by Fortify Cross-Site Request Forgery Training Module<br /> <br /> - 25 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Link Injection (facilitates Cross-Site Request Forgery)<br /> <br /> Security Risks It is possib possible le to persua persuade de a naive naive user user to supply supply sensitiv sensitive e inform informati ation on such such as userna username, me, password, credit card number, social security number etc. It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used 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. Possible Causes Sanitation of hazardous characters was not performed correctly on user input. Technical Description 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 launch launching ing these these attack attacks s from from the vulner vulnerabl able e site site itself itself the attack attacker er increa increases ses the chance chances s of success, because the user is more likely to be logged in. The The Link Link Inject Injection ion vulnera vulnerabil bility ity is a result result of insuff insuffici icient ent user user input input sanita sanitatio tion, n, which which is later later returned to the user in the site response. The ability to inject hazardous characters into the respo respons nse e make makes s it poss possib ible le for for atta attack ckers ers to embed embed URLs URLs,, amon among g othe otherr poss possib ible le cont conten entt 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 Smith Will 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/ANYSCRIP SRC="http://www.ANY-SITE.com/ANYSCRIPT. T. asp"> This will return the following response: <HTML> <BODY> 10/22/2009 9:38:02 AM 1254/1261 Hello, <IMG SRC="http://www.ANY-SITE.com/ANY-SCRIPT.as SRC="http://www.ANY-SITE.com/ANY-SCRIPT.asp">. p">. </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 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application includ include e unregi unregiste sterin ring g from from the site, site, or modify modifying ing the user's user's profil profile, e, email email addres address s 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. An incautious user may click 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. General Fix Recommendations There are several issues whose remediation lies in sanitizing user input. By verify verifying ing that that user user input input does does not contai contain n hazard hazardous ous charac characters ters,, it is possib possible le to preven preventt malicious users from causing your application to execute unintended operations, such as launch arbitr arbitrary ary SQL queries, queries, embed embed Javasc Javascrip riptt code code to be execut executed ed on the client client side, side, run various 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) References and Relevant Links OWASP Article The Cross-Site Request Forgery FAQ Cross-Site Request Forgery Training Module CWE-74: Failure to Sanitize Data into a Different Plane ('Injection')<br /> <br /> - 27 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Phishing through Frames<br /> <br /> Security Risks It is possib possible le to persua persuade de a naive naive user user to supply supply sensitiv sensitive e inform informati ation on such such as userna username, me, password, credit card number, social security number etc. Possible Causes Sanitation of hazardous characters was not performed correctly on user input. Technical Description 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 http://[SERVER]/script.as px?parameter=<frame name="evil" src="www.evil.com"> will cause the response to contain a frame to the evil site. General Fix Recommendations There are several issues whose remediation lies in sanitizing user input. By verify verifying ing that that user user input input does does not contai contain n hazard hazardous ous charac characters ters,, it is possib possible le to preven preventt malicious users from causing your application to execute unintended operations, such as launch arbitr arbitrary ary SQL queries, queries, embed embed Javasc Javascrip riptt code code to be execut executed ed on the client client side, side, run various 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) References and Relevant Links FTC Consumer Alert - "How Not to Get Hooked by a 'Phishing' Scam" CWE-301: Reflection Attack in an Authentication Protocol - 28 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Permanent Cookie Contains Sensitive Session Information<br /> <br /> Security Risks It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Possible Causes The web application stores sensitive session information in a permanent cookie (on disk). Technical Description During During the applic applicati ation on test, test, it was detect detected ed that that sensit sensitive ive sessio session n inform informati ation on such such as user 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 additi addition, on, several several privac privacy y regula regulatio tions ns require require that that users users will will be identi identifie fied d unique uniquely ly before 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. General Fix Recommendations Make sure that sensitive session information such as user credentials or session tokens will always be stored stored in non-pe non-perma rmanen nentt cookie cookies s (RAM (RAM cooki cookies) es) only. only. This This is achiev achieved ed by not settin setting g the "Expires" field in the cookie. References and Relevant Links Financial Privacy: The Gramm-Leach Bliley Act Health Insurance Portability and Accountability Act (HIPAA) Sarbanes-Oxley Act California SB1386 HTTP State Management Mechanism (RFC 2109) CWE-539: Information Leak Through Persistent Cookies<br /> <br /> - 29 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Session Not Invalidated After Logout<br /> <br /> Security Risks It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Possible Causes Insecure web application programming or configuration. Technical Description According to WASC: "Insu "Insuffi fficie cient nt Sessio Session n Expira Expiratio tion n is when when a web site site permits permits an attack attacker er to reuse reuse old sessio session n 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. General Fix Recommendations 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. References and Relevant Links 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 Science CWE-613: Insufficient Session Expiration<br /> <br /> - 30 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Cacheable SSL Page Found<br /> <br /> Security Risks It is possib possible le to gather gather sensit sensitive ive inform informati ation on about about the web applic applicati ation on such such as userna usernames mes,, passwords, machine name and/or sensitive file locations. Possible Causes Sensitive information might have been cached by your browser. Technical Description 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 not recom recomme mend nded ed to enabl enable e the the web web brow browse serr to save save any any SSL SSL info inform rmat ation ion,, sinc since e this this information might be compromised when a vulnerability exists. General Fix Recommendations 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. References and Relevant Links N/A<br /> <br /> - 31 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> HTML Comments Sensitive Information Disclosure<br /> <br /> Security Risks It is possib possible le to gather gather sensit sensitive ive inform informati ation on about about the web applic applicati ation on such such as userna usernames mes,, passwords, machine name and/or sensitive file locations Possible Causes Debugging information was left by the programmer in web pages. Technical Description Many web application programmers use HTML comments to help debug the application when needed. needed. While While adding adding general general commen comments ts is very very usefu useful, l, some some progra programme mmers rs tend tend to leave 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. General Fix Recommendations [1] Do not leave any vital information such as filenames or file paths in HTML comments. [2] Remove traces of previous pre vious (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. References and Relevant Links WASC Threat Classification: Information Leakage<br /> <br /> - 32 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Missing Secure Attribute in Encrypted Session (SSL) Cookie<br /> <br /> Security Risks It may be possib possible le to steal steal user user and sessi session on inform informati ation on (cooki (cookies) es) that was sent sent during during an encrypted session. Possible Causes The web application sends non-secure cookies over SSL. Technical Description During the application test, it was detected that the tested web application set a cookie without the "secur "secure" e" attrib attribute ute,, during during an encryp encrypted ted sessio session. n. Since Since this this cooki cookie e does does not contai contain n 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. General Fix Recommendations 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 w henever it sends back this cookie, to protect the confidentially and authenticity of the information in the cookie." For furt furthe herr refer referen ence ce pleas please e see see the the HTTP HTTP Stat State e Mana Manage geme ment nt Mech Mechan anis ism m RFC 2965 2965 at: at: http://www.ietf.org/rfc/rfc2965.txt And for "Best curren rent prac ractice" for use of HTTP State Manageme ement pleas ease see link:http://tools.ietf.org/html/rfc2964 link:http://tools.ietf.org/html/rfc2964 References and Relevant Links Financial Privacy: The Gramm-Leach Bliley Act Health Insurance Portability and Accountability Act (HIPAA) Sarbanes-Oxley Act California SB1386<br /> <br /> - 33 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Query Parameter in SSL Request<br /> <br /> Security Risks It may be possible to steal sensitive data such as credit card numbers, social security numbers etc. that are sent unencrypted. Possible Causes Query parameters were passed over SSL, and may contain sensitive information. Technical Description 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. General Fix Recommendations Make sure that sensitive information such as: - Username - Password - Social Security number - Credit Card number - Driver's License number - Email address - Phone number - Zip code is always sent in the body part of an HTTP POST request. References and Relevant Links Financial Privacy: The Gramm-Leach Bliley Act Health Insurance Portability and Accountability Act (HIPAA) Sarbanes-Oxley Act California SB1386<br /> <br /> - 34 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Cacheable Login Page Found<br /> <br /> Security Risks It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Possible Causes Sensitive information might have been cached by your browser. Technical Description Most web browsers are configured by default to cache the user's pages during use. This means that login pages are cached as well. w ell. It is not recommen recommended ded to enable enable the web browser browser to save save any login informat information ion,, since since this this information might be compromised when a vulnerability exists. General Fix Recommendations 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. References and Relevant Links N/A<br /> <br /> - 35 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Session Identifier Not Updated<br /> <br /> Security Risks It is possib possible le to steal steal or manipu manipulat late e custom customer er sessio session n and cookies, cookies, which which might might be used used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Possible Causes Insecure web application programming or configuration. Technical Description According to WASC: "Sessi "Session on Fixati Fixation on is an attack attack techniqu technique e that that forces forces a user's user's session session ID to an explic explicit it value. 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" system systems, s, that that only only accept accept server server-si -side de generat generated ed values values.. With With permis permissiv sive e system systems, s, arbitr arbitrary ary session IDs are maintained without contact with the web site. Strict systems require that the attack attacker er mainta maintain in the "trap"trap-ses sessio sion", n", with with periodi periodic c web site site contac contact, t, preven preventin ting g inacti inactivit vity y 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-Up The attacker sets up a "trap-sess "trap-session" ion" for the target web site and obtains that session's 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 Fixation The attacker introduces the trap session value into the user's browser and fixes the user's session ID. 3) Session Entrance The 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=1234 According to WASC: "Issuing a new session ID cookie value using a client-side script<br /> <br /> - 36 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application 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 e ffectively 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 re sponse 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 The sessio session n identi identifie fierr value value can be obtain obtained ed by utiliz utilizing ing a CrossCross-Sit Site e Script Scripting ing vulnera vulnerabil bility ity,, 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. General Fix Recommendations 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 References and Relevant Links "Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security PHP Manual, Session Handling Functions, Sessions and security<br /> <br /> - 37 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Inadequate Account Lockout<br /> <br /> Security Risks It might be possible to escalate user privileges and gain administrative permissions over the web application. Possible Causes Insecure web application programming or configuration. Technical Description 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_PASSWORD If the site site does does not lock the tested tested accoun accountt after after several several false false attemp attempts, ts, the attacker attacker may eventually discover the account password and use it to impersonate the account's legitimate user. General Fix Recommendations 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. References and Relevant Links "Blocking Brute-Force Attacks" by Mark Burnett<br /> <br /> - 38 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application<br /> <br /> Authentication Bypass Using SQL Injection<br /> <br /> Security Risks It may be possible to bypass the web we b application's authentication mechanism. Possible Causes Sanitation of hazardous characters was not performed correctly on user input. Technical Description Web applic applicati ations ons often often use use databa databases ses at the backen backend d to interac interactt with with the enterp enterpris rise e data 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 which when incorpo incorporat rated ed into into an SQL query, query, change changes s the original original syntax syntax of the query into into someth something ing comple completel tely y differe different. nt. For exampl example, e, if an applic applicati ation on uses uses user's user's input input (such (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 the quer query y - eith either er from from a GET GET requ reques estt quer query y para parame mete ters rs,, or from from a POST POST requ reques estt body body param ramete eters). A regu egular usage of this query ery wou would be with values $us $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. General Fix Recommendations There are several issues whose remediation lies in sanitizing user input. By verify verifying ing that that user user input input does does not contai contain n hazard hazardous ous charac characters ters,, it is possib possible le to preven preventt malicious users from causing your application to execute unintended operations, such as launch arbitr arbitrary ary SQL queries, queries, embed embed Javasc Javascrip riptt code code to be execut executed ed on the client client side, side, run various 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 -<br /> <br /> Application Related Security Vulnerabilities in a Web Application [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) References and Relevant Links "Web Application Disassembly with ODBC Error Messages" (By David Litchfield) SQL Injection Training Module<br /> <br /> - 40 -<br /> <br /> </div> </div> </div> </div> </div> </div> </div> </div> <div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true"> <div class="modal-dialog"> <div class="modal-content"> <form role="form" method="post" action="https://idoc.tips/report/security-vulnerabilities-in-a-web-application-pdf-free" style="border: none;"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button> <h4 class="modal-title">Report "Security Vulnerabilities in a Web Application"</h4> </div> <div class="modal-body"> <div class="form-group"> <label>Your name</label> <input type="text" name="name" required="required" class="form-control" /> </div> <div class="form-group"> <label>Email</label> <input type="email" name="email" required="required" class="form-control" /> </div> <div class="form-group"> <label>Reason</label> <select name="reason" required="required" class="form-control"> <option value="">-Select Reason-</option> <option value="pornographic" selected="selected">Pornographic</option> <option value="defamatory">Defamatory</option> <option value="illegal">Illegal/Unlawful</option> <option value="spam">Spam</option> <option value="others">Other Terms Of Service Violation</option> <option value="copyright">File a copyright complaint</option> </select> </div> <div class="form-group"> <label>Description</label> <textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;">

Security Vulnerabilities in a Web Application

Recommend Documents