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.
®Rational AppScan, is a tool which is used to identify the vulnerable areas in a web application. It
provides us a handful of information about the vulnerability and various ways to fix it.
This document is partially based on the reports that were received from the ®Rational AppScan.
Document Revision History
Date Version Author Remarks
19-Jul-2010 1.0 Rupesh Kumar R Jain Finalized the document to upload.
21-Jul-2010 2.0 Rupesh Kumar R Jain Added two more vulnerabilities in the
list.
Added the document history section.
-2-
TABLE OF CONTENTS
1 APPLICATION RELATED VULNERABILITIES.....................................................6
Cross-Site Scripting..................................................................................................................................................................7
Security Risks........................................................................................................................................................................7
Possible Causes.....................................................................................................................................................................7
Technical Description............................................................................................................................................................7
General Fix Recommendations...........................................................................................................................................11
References and Relevant Links...........................................................................................................................................11
Stored Cross-Site Scripting...................................................................................................................................................12

Security Risks......................................................................................................................................................................12
Possible Causes...................................................................................................................................................................12
Technical Description..........................................................................................................................................................12
SQL Injection..........................................................................................................................................................................17
Security Risks......................................................................................................................................................................17
Possible Causes...................................................................................................................................................................17
Database Error Pattern Found.............................................................................................................................................20

Security Risks......................................................................................................................................................................20
Possible Causes...................................................................................................................................................................20
SQL Query in Parameter Value............................................................................................................................................23

Security Risks......................................................................................................................................................................23
Possible Causes...................................................................................................................................................................23
Cross-Site Request Forgery...................................................................................................................................................24

Security Risks......................................................................................................................................................................24
Possible Causes...................................................................................................................................................................24
Link Injection (facilitates Cross-Site Request Forgery).....................................................................................................26

Security Risks......................................................................................................................................................................26
Possible Causes...................................................................................................................................................................26
-3-
Phishing through Frames......................................................................................................................................................28

Security Risks......................................................................................................................................................................28
Possible Causes...................................................................................................................................................................28
Permanent Cookie Contains Sensitive Session Information..............................................................................................29

Security Risks......................................................................................................................................................................29
Possible Causes...................................................................................................................................................................29
Session Not Invalidated After Logout..................................................................................................................................30

Security Risks......................................................................................................................................................................30
Possible Causes...................................................................................................................................................................30
Cacheable SSL Page Found...................................................................................................................................................31

Security Risks......................................................................................................................................................................31
Possible Causes...................................................................................................................................................................31
HTML Comments Sensitive Information Disclosure.........................................................................................................32

Security Risks......................................................................................................................................................................32
Possible Causes...................................................................................................................................................................32
Missing Secure Attribute in Encrypted Session (SSL) Cookie..........................................................................................33

Security Risks......................................................................................................................................................................33
Possible Causes...................................................................................................................................................................33
Query Parameter in SSL Request.........................................................................................................................................34

Security Risks......................................................................................................................................................................34
Possible Causes...................................................................................................................................................................34
Cacheable Login Page Found................................................................................................................................................35

Security Risks......................................................................................................................................................................35
Possible Causes...................................................................................................................................................................35
-4-
Session Identifier Not Updated.............................................................................................................................................36

Security Risks......................................................................................................................................................................36
Possible Causes...................................................................................................................................................................36
Inadequate Account Lockout................................................................................................................................................38

Security Risks......................................................................................................................................................................38
Possible Causes...................................................................................................................................................................38
Authentication Bypass Using SQL Injection.......................................................................................................................39

Security Risks......................................................................................................................................................................39
Possible Causes...................................................................................................................................................................39
-5-
1 Application Related Vulnerabilities
Contents
1. Cross-Site Scripting
2. Stored Cross-Site Scripting
3. SQL Query in Parameter Value
4. Cross-Site Request Forgery
5. Link Injection (facilitates Cross-Site Request Forgery)
6. Phishing through Frames
7. Permanent Cookie Contains Sensitive Session Information
8. Session Not Invalidated After Logout
9. Cacheable SSL Page Found
10. HTML Comments Sensitive Information Disclosure
11. Missing Secure Attribute in Encrypted Session (SSL) Cookie
12. Query Parameter in SSL Request
-6-
Cross-Site Scripting
Security Risks
It is possible to steal or manipulate customer session and cookies, which might be used to
impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform
transactions as that user.
Possible Causes
Sanitation of hazardous characters was not performed correctly on user input.
Technical Description
The Cross-Site Scripting attack is a privacy violation, that allows an attacker to acquire a
legitimate user's credentials and to impersonate that user when interacting with a specific
website.
The attack hinges on the fact that the web site contains a script that returns a user's input (usually
a parameter value) in an HTML page, without first sanitizing the input. This allows an input
consisting of JavaScript code to be executed by the browser when the script returns this input in
the response page. As a result, it is possible to form links to the site where one of the parameters
consists of malicious JavaScript code. This code will be executed (by a user's browser) in the site
context, granting it access to cookies that the user has for the site, and other windows in the site
through 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 web-
site containing a parameter value with malicious JavaScript code. If the web-site embeds this
parameter value into the response HTML page (this is the essence of the site issue), the malicious
code will run in the user's browser.
Possible actions that can be performed by the script are:

[1] Send user's cookies (for the legitimate site) to the attacker.
[2] Send information that is accessible through the DOM (URLs, Form fields, etc.), to the attacker.
The result is that the security and privacy of the victim user is compromised on the vulnerable
site.
Some notes:
[1] Although the attacked web site is involved, it is not compromised directly. It is used as a 'jump
station' for the malicious script sent by the attacker, to return to the victim's browser, as if it is
legitimate. However, since the privacy of the victim is breached in the context of the specific site,
and since the site is directly responsible, it is considered a security flaw in the site.
[2] The malicious link can be provided by the attacker, using a web site link, if the attacker
maintains a site that is visited by the victim user. The malicious link can also be provided by email,
if the attacker knows the user's email address, and the user's email client uses the browser to
render the HTML message.
[3] While user input is most commonly found in form field values (i.e. URL parameters), there are
known attacks where the malicious code is embedded in the path, query, or in the HTTP Referrer
headers, and even in cookies.
[4] AppScan sends many types of Cross-Site Scripting attacks, including attacks that work only on
specific browsers or versions of browsers. AppScan's "Show in Browser" feature uses Internet
Explorer to show the vulnerability. In the case of variants to which Internet Explorer is not
vulnerable, but other browsers are, the "Show in Browser" facility does not work and the popup is
not shown.
There are two possible scenarios for sending input to a web application that is vulnerable to cross-
site scripting:
-7-
A. The parameter value sent to the CGI script is returned in the response page, embedded in the
HTML.
For example:
[request]
GET /cgi-bin/script.pl?name=JSmith HTTP/1.0
[response]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 27
<HTML>
Hello JSmith
</HTML>
B. The parameter value sent to the CGI script is returned in an HTML parameter value context.
For example:
[request]
[response]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Length: 254
<HTML>
Please fill in your zip code:
<FORM METHOD=GET ACTION="/cgi-bin/script.pl">
<INPUT TYPE=text NAME="name" value="JSmith"> <br>
<INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br>
<INPUT TYPE=submit value="Submit">
</FORM>
</HTML>
Example 1 - scenario A
The following request is sent by the user:
[attack request]
GET /cgi-bin/script.pl?name=>"'><script>alert('Watchfire%20XSS%20Test
%20Successful')</script>
HTTP/1.0
[attack response scenario A]
HTTP/1.1 200 OK
Server: SomeServer
4/21/2009 8:10:17 AM 233/350
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Length: 83
<HTML>
Hello >"'><script>alert('Watchfire XSS Test Successful')</script>
</HTML>
In this case, the JavaScript code will be executed by the browser (The >"'> part is irrelevant here).
Example 2 - scenario 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-
Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Length: 310
<HTML>
<INPUT TYPE=text NAME="name" value=">"'><script>alert('Watchfire XSS Test Successful')
</script>"> <br>
</FORM>
</HTML>
The >"'> prefix is used to break out of the parameter value context. Closing the parameter value
field ( "'> ) and then closing the <INPUT> tag ( > ) will cause the JavaScript to be executed by the
browser and not to be treated as a parameter value that would have been parsed or executed as
JavaScript code.
Listed below are the different test variants:

[1] >'><script>alert('Watchfire XSS Test Successful')</script>
[2] >"><script>alert("Watchfire XSS Test Successful")</script>
[3] </TextArea><script>alert('Watchfire XSS Test Successful')</script>
[4] >"'><img src="javascript:alert('Watchfire XSS Test Successful')">
[5] >"'><img
src=javascript:alert
("Watchfire XSS Test Successful")>
[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="
[7] --><script>alert('Watchfire XSS Test Successful')</script>
[8] '+alert('Watchfire XSS Test Successful')+'
[9] "+alert('Watchfire XSS Test Successful')+"
[10] >'><%00script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)
[11] >"><%00script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)
[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-
[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%
20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be
Variant details:
Test variants [1] & [2]: These are the most basic cross-site scripting variants. The difference
between the two variants is the use of quotes or of an apostrophe in the JavaScript code. Some
web application programmers only sanitize user input for apostrophe or for quotes, but not both.
This vulnerability is detected by running both variants.
Test variant [3]: This test variant is specifically designed for user input that is returned embedded
in <TEXTAREA> parameters. During the test, an attempt is made to break out of the parameter
value (text area), to force the JavaScript to be executed by the browser.
Test variant [4]: Some web application programmers sanitize <SCRIPT> tags from user input, but
forget to sanitize the "javascript:" specifier, which can be used in HTML links. During this test, an
attempt is made to embed the malicious JavaScript code by using an <img> tag with a JavaScript
link as its source.
Test variant [5]: This variant is very similar to variant #4. It uses HTML entities to bypass security
measures which sanitize user input of the <, >, quotes and the "javascript:" specifier.
Test variant [6]: This variant uses the least number of non-standard characters. Unlike former
variants, it does not use &, >, < , # or ; characters. Assuming that the user input is embedded in
an HTML form parameter value (inside an <INPUT> tag), the malicious string first escapes from
parameter value context and then proceeds to add a STYLE attribute to the <INPUT> tag, in which
it embeds the malicious JavaScript code. Note: this variant will only succeed in scenario B, or if
user input is embedded in attributes of other HTML elements.
-9-
Test variant [7]: Some web applications embed user input inside HTML comments. To test the
application for this vulnerability, the HTML comment ( --> ) is first closed, and then the malicious
JavaScript code is embedded.
Test variants [8] & [9]: Some web applications embed user input in JavaScript string literals, for
example:
<HTML>
<SCRIPT LANGUAGE="JavaScript">
var str = 'Hello $user_input';
...
</SCRIPT>
</HTML>
If we send the following parameter value: '+alert('Watchfire XSS Test Successful')+', the resulting
response page will look like this:
<HTML>
var str = 'Hello ' + alert('Watchfire XSS Test Successful') + '';
...
</SCRIPT>
</HTML>
The application is tricked into concatenating the malicious JavaScript code in the middle of the
original string literal, causing the browser to execute our JavaScript code. The difference between
variants #8 and #9 is the use of quotes or of an apostrophe, which customizes the attack for both
string terminating characters.
Test variants [10] & [11]: In Microsoft .NET 1.1, the HttpRequest. ValidateInput method validates
data submitted by a client browser and raises an exception if potentially dangerous data is
present.
From MSDN: "If the validation feature is enabled by page directive or configuration, this method is
called during the Page's ProcessRequest processing phase. ValidateInput can be called by your
code if the validation feature is not enabled. Request validation works by checking all input data
against a hard-coded list of potentially dangerous data."
Input data is checked during request validation in the following members:
- HttpRequest.Form,
- HttpRequest.QueryString,
- HttpRequest.Cookies
** Note: The HttpRequest.ValidateInput is enabled by default in ASP.NET 1.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')</script>
[8] '+alert('Watchfire XSS Test Successful')+'
[9] "+alert('Watchfire XSS Test Successful')+"
[10] >'><%00script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)
[11] >"><%00script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)
[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-
[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%
20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be
Variant details:
Test variants [1] & [2]: These are the most basic cross-site scripting variants. The difference
between the two variants is the use of quotes or of an apostrophe in the JavaScript code. Some
web application programmers only sanitize user input for apostrophe or for quotes, but not both.
This vulnerability is detected by running both variants.
Test variant [3]: This test variant is specifically designed for user input that is returned embedded
in <TEXTAREA> parameters. During the test, an attempt is made to break out of the parameter
value (text area), to force the JavaScript to be executed by the browser.
Test variant [4]: Some web application programmers sanitize <SCRIPT> tags from user input, but
forget to sanitize the "javascript:" specifier, which can be used in HTML links. During this test, an
attempt is made to embed the malicious JavaScript code by using an <img> tag with a JavaScript
link as its source.
Test variant [5]: This variant is very similar to variant #4. It uses HTML entities to bypass security
measures which sanitize user input of the <, >, quotes and the "javascript:" specifier.
Test variant [6]: This variant uses the least number of non-standard characters. Unlike former
variants, it does not use &, >, < , # or ; characters. Assuming that the user input is embedded in
an HTML form parameter value (inside an <INPUT> tag), the malicious string first escapes from
parameter value context and then proceeds to add a STYLE attribute to the <INPUT> tag, in which
it embeds the malicious JavaScript code. Note: this variant will only succeed in scenario B, or if
user input is embedded in attributes of other HTML elements.
Test variant [7]: Some web applications embed user input inside HTML comments. To test the
application for this vulnerability, the HTML comment ( --> ) is first closed, and then the malicious
JavaScript code is embedded.
- 14 -
Test variants [8] & [9]: Some web applications embed user input in JavaScript string literals, for
example:
<HTML>
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>
var str = 'Hello ' + alert('Watchfire XSS Test Successful') + '';
...
</SCRIPT>
</HTML>
The application is tricked into concatenating the malicious JavaScript code in the middle of the
original string literal, causing the browser to execute our JavaScript code. The difference between
variants #8 and #9 is the use of quotes or of an apostrophe, which customizes the attack for both
string terminating characters.
Test variants [10] & [11]: In Microsoft .NET 1.1, the HttpRequest.ValidateInput method validates
data submitted by a client browser and raises an exception if potentially dangerous data is
present.
From MSDN: "If the validation feature is enabled by page directive or configuration, this method is
called during the Page's ProcessRequest processing phase. ValidateInput can be called by your
code if the validation feature is not enabled. Request validation works by checking all input data
against a hard-coded list of potentially dangerous data."
Input data is checked during request validation in the following members:
- HttpRequest.Form,
- HttpRequest.QueryString,
- HttpRequest.Cookies
** Note: The HttpRequest.ValidateInput is enabled by default in ASP.NET 1.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 security problem presented above, any HTML tag can be injected through ASP.NET 1.1
HttpRequest. ValidateInput security mechanism, leaving it vulnerable to cross site scripting, and
injection of other malicious HTML tags.
Test variant [12]: While many input validation functions properly filter out or escape common
characters used for XSS (such as <> (triangular parenthesis)), only a few manage to handle
hazardous UTF-7 encoded strings.
Therefore, in many cases, when sending an XSS attack payload encoded in UTF-7, the payload will
return in the response without being altered.
For the attack to succeed, the victim's browser should treat the XSS payload as UTF-7, otherwise
the script will not be executed.
If 'Encoding' is set to 'Auto-Detect', and Internet Explorer finds a UTF-7 string in the first 4096
characters of the response body, it will set the charset encoding to UTF-7 automatically, unless
another charset encoding is already enforced. This automatic encoding feature may help a
malicious user to mount the UTF-7 XSS attack.
A successful attack for this variant requires the following:
[*] The victim uses an Internet Explorer client with 'Encoding' set to 'Auto-Detect'.
[*] There is no charset encoding enforcement (unless utf-7 is enforced) in:
- 15 -
[*] The response headers ("Content-Type: text/html; charset=[encoding]").

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

[1] | (pipe sign)
[4] $ (dollar sign)
[6] @ (at sign)
[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

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
- 16 -
SQL Injection
Security Risks
It is possible to view, modify or delete database entries and tables.
Possible Causes
Web applications often use databases at the backend to interact with the enterprise data warehouse.
The de-facto standard language for querying databases is SQL (each major database vendor has its own
dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an
SQL query, which is then sent to the backend database. The query results are then processed by the
application and sometimes displayed to the user.
This mode of operation can be exploited by an attacker if the application is not careful enough with its
treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when
incorporated into an SQL query, changes the original syntax of the query into something completely
different. For example, if an application uses user's input (such as username and password) to query a
database table of users' accounts in order to authenticate the user, and the attacker has the ability to
inject malicious data into the username part of the query (or the password part, or both), the query can
be changed into a different data yanking query, a query that modifies the database, or a query that
runs shell commands on the database server.
Typically, the attacker achieves this goal in steps. He/she will first learn the structure of the SQL query,
and then use this knowledge to thwart the query (by injecting data that changes the query syntax) into
performing differently than intended. Suppose the query in question is:
SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user and
$pass are user input (collected from the HTTP request which invoked the script that constructs the
query - either from a GET request query parameters, or from a POST request body parameters). A
regular usage of this query would be with values $user=john, $password=secret123.
The query formed would be:

SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123' The expected
query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e.
there is a user named 'john' in the database, whose password is 'secret123'). This would serve as a
basic authentication mechanism for the application. But an attacker can alter this query in the following
ways:
1. By providing an input consisting of a single apostrophe character ('), the attacker can cause the
database to emit an error message, which usually contains valuable information regarding the SQL
query. The attack would simply involve sending a request with the user value ' and a password with any
value (e.g. foobar). The result would be the following (malformed) SQL query:
SELECT COUNT(*) FROM accounts WHERE username=''' AND password='foobar'
This may yield the following error message (depending on the specific database in use at the backend):
Syntax error (missing operator) in query expression 'username = ''' AND password = 'foobar''.
The attacker is informed that the query is built around the expression username='$user' AND
password='$pass'. This crucial information is needed to exploit the SQL query at hand. When the
attacker understands the format of the query, his next step would simply be to use:
user = ' or 1=1 or ''='
password = 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
- 17 -
own unique SQL 'dialect'). Specifically sending ' having 1=1 is also known to produce error messages
that reveal information about column names. In some cases, the user input is not incorporated in a
string context (encompassed in apostrophes), but rather in numeric context, that is, embedded as-is.
Thus the input string 1 having 1=1 can be used in such cases.
2. In some cases, it is possible to replace the original query with any other query. The way to do it is to
prematurely terminate the original query (e.g. by closing the string context using apostrophe, force
termination by a query separator character such as semicolon and then write a new query). If the
application is flexible enough to receive (and display) data from the modified query (although it is not
exactly the expected data), then this technique may be used to download various database tables and
records.
Even if the application does not process the unexpected data returned from the database in such way
that this data is displayed, it may still be possible to run malicious queries on the database (e.g. to
change tables, delete tables, and run shell commands).
Finally, in some cases the desired data can be acquired by crafting the malicious queries in such way
that the desired data is returned in the format expected by the application.
The following input strings can be used to yield sensitive information from system tables in the
database (depending on the way the application handles returned query results, of course):
'; select @@version,1,1,1--
(MS-SQL database - returns the database version)
'; select * from master..sysmessages
(MS-SQL database - returns system information)
'; select * from dbo.sysdatabases
(MS-SQL database - returns database names managed by the database server)
'; select * from sys.dba_users
(Oracle database - returns database usernames)
We see therefore that if user input is not santized (that is, string data is ensured not to have ' or " -
these characters must be encoded/escaped, and numeric/boolean or other typed data is ensured to be
of proper format), an attacker can make use of this fact and manipulate the database.
In the Oracle test variant, the SQL injection is validated by forcing the Oracle database to establish an
HTTP connection back from the Oracle server, to the testing machine, using the UTL_HTTP package.
The injection payload sent: ' || UTL_HTTP.REQUEST('http://IP_Address:80/SQL_Injection_Validation')
|| '
Assuming that the original SQL query was: SELECT COUNT(*) FROM accounts WHERE username='$user'
AND password='$pass', the actual SQL query during the SQL injection test will be:
SELECT COUNT(*) FROM accounts WHERE username='' || UTL_HTTP.REQUEST
('http://IP_Address:80/SQL_Injection_Validation') || '' AND password='$pass'
When running this SQL query, the Oracle server will execute the UTL_HTTP.REQUEST entry point, which
will contact the testing machine and request the file '/SQL_Injection_Validation' over HTTP.
Note: For this test to be validated properly, a direct TCP connection must be possible between the
Oracle server and the testing machine.
A similar approach is used in an MS SQL port listener test variant.
The injection payload sent: '; select * from openrowset
('sqloledb','Network=DBMSSOCN;Address=IP_Address,9999;uid=myUsr;pwd=myPass','select foo
from bar')--
SELECT COUNT(*) FROM accounts WHERE username=''; select * from openrowset
('sqloledb','Network=DBMSSOCN;Address=[IP_Address],9999;uid=myUsr;pwd=myPass','select foo from
bar')--' AND password='$pass'
When running this SQL query, MS SQL server will establish a connection to [IP_Address] on port 9999,
as a result of the openrowset() execution.
Note: For this test to be validated properly, a direct TCP connection must be possible between the MS
SQL server and the testing machine.

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 -

[1] | (pipe sign)
[4] $ (dollar sign)
[6] @ (at sign)
[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

"Web Application Disassembly with ODBC Error Messages" (By David Litchfield)
SQL Injection Training Module
- 19 -
Database Error Pattern Found
Security Risks
Possible Causes
AppScan discovered Database Errors in the test response, which may have been triggered by an attack
other than SQL Injection.
It is possible, though not certain, that this error indicates a possible SQL Injection vulnerability in the
application.
If it does, please read the following SQL Injection advisory carefully:
Web applications often use databases at the backend to interact with the enterprise data warehouse.
The de-facto standard language for querying databases is SQL (each major database vendor has its own
dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an
SQL query, which is then sent to the backend database. The query results are then processed by the
application and sometimes displayed to the user.
This mode of operation can be exploited by an attacker if the application is not careful enough with its
treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when
incorporated into an SQL query, changes the original syntax of the query into something completely
different. For example, if an application uses user's input (such as username and password) to query a
database table of users' accounts in order to authenticate the user, and the attacker has the ability to
inject malicious data into the username part of the query (or the password part, or both), the query can
be changed into a different data yanking query, a query that modifies the database, or a query that
runs shell commands on the database server.
Typically, the attacker achieves this goal in steps. He/she will first learn the structure of the SQL query,
and then use this knowledge to thwart the query (by injecting data that changes the query syntax) into
performing differently than intended. Suppose the query in question is:
SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user and
$pass are user input (collected from the HTTP request which invoked the script that constructs the
query - either from a GET request query parameters, or from a POST request body parameters). A
regular usage of this query would be with values $user=john, $password=secret123.
SELECT COUNT(*) FROM accounts WHERE username='john' AND password='secret123' The expected
query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e.
there is a user named 'john' in the database, whose password is 'secret123'). This would serve as a
basic authentication mechanism for the application. But an attacker can alter this query in the following
ways:
1. By providing an input consisting of a single apostrophe character ('), the attacker can cause the
database to emit an error message, which usually contains valuable information regarding the SQL
query. The attack would simply involve sending a request with the user value ' and a password with any
value (e.g. foobar). The result would be the following (malformed) SQL query:
SELECT COUNT(*) FROM accounts WHERE username=''' AND password='foobar' This may yield the
following error message (depending on the specific database in use at the backend):
Syntax error (missing operator) in query expression 'username = ''' AND password = 'foobar''. The
attacker is informed that the query is built around the expression username='$user' AND
password='$pass'. This crucial information is needed to exploit the SQL query at hand. When the
attacker understands the format of the query, his next step would simply be to use:
user = ' or 1=1 or ''='
password = foobar
SELECT COUNT(*) FROM accounts WHERE username='' or 1=1 or ''='' AND password='foobar' This
means that the query (in the SQL database) will return TRUE for every record of the table "accounts",
- 20 -
since the expression 1=1 is always true. Therefore, the query will return the number of records in
"accounts", and thus the user (attacker) will be considered valid. There are several variants of this
probing method, such as sending '; or \' (it should be remembered that almost all vendors have their
own unique SQL 'dialect'). Specifically sending ' having 1=1 is also known to produce error messages
that reveal information about column names. In some cases, the user input is not incorporated in a
string context (encompassed in apostrophes), but rather in numeric context, that is, embedded as-is.
Thus the input string 1 having 1=1 can be used in such cases.
2. In some cases, it is possible to replace the original query with any other query. The way to do it is to
prematurely terminate the original query (e.g. by closing the string context using apostrophe, force
termination by a query separator character such as semicolon and then write a new query). If the
application is flexible enough to receive (and display) data from the modified query (although it is not
exactly the expected data), then this technique may be used to download various database tables and
records.
Even if the application does not process the unexpected data returned from the database in such way
that this data is displayed, it may still be possible to run malicious queries on the database (e.g. to
change tables, delete tables, and run shell commands).
Finally, in some cases the desired data can be acquired by crafting the malicious queries in such way
that the desired data is returned in the format expected by the application. The following input strings
can be used to yield sensitive information from system tables in the database (depending on the way
the application handles returned query results, of course):
'; select @@version,1,1,1--
(MS-SQL database - returns the database version)
'; select * from master..sysmessages
(MS-SQL database - returns system information)
'; select * from dbo.sysdatabases
(MS-SQL database - returns database names managed by the database server)
'; select * from sys.dba_users
(Oracle database - returns database usernames)
We see therefore that if user input is not santized (that is, string data is ensured not to have ' or " -
these characters must be encoded/escaped, and numeric/boolean or other typed data is ensured to be
of proper format), an attacker can make use of this fact and manipulate the database. In the Oracle test
variant, the SQL injection is validated by forcing the Oracle database to establish an HTTP connection
back from the Oracle server, to the testing machine, using the UTL_HTTP package.
The injection payload sent: ' || UTL_HTTP.REQUEST('http://IP_Address:80/SQL_Injection_Validation') || '
SELECT COUNT(*) FROM accounts WHERE username='' || UTL_HTTP.REQUEST
('http://IP_Address:80/SQL_Injection_Validation') || '' AND password='$pass'
When running this SQL query, the Oracle server will execute the UTL_HTTP.REQUEST entry point, which
will contact the testing machine and request the file '/SQL_Injection_Validation' over HTTP.
Note: For this test to be validated properly, a direct TCP connection must be possible between the
Oracle server and the testing machine.
A similar approach is used in an MS SQL port listener test variant.
The injection payload sent: '; select * from openrowset
('sqloledb','Network=DBMSSOCN;Address=IP_Address,9999;uid=myUsr;pwd=myPass','select foo from
bar')--
SELECT COUNT(*) FROM accounts WHERE username=''; select * from openrowset
('sqloledb','Network=DBMSSOCN;Address=[IP_Address],9999;uid=myUsr;pwd=myPass','select foo from
bar')--' AND password='$pass'
When running this SQL query, MS SQL server will establish a connection to [IP_Address] on port 9999,
as a result of the openrowset() execution.
Note: For this test to be validated properly, a direct TCP connection must be possible between the MS
SQL server and the testing machine.

If the error indicates a SQL Injection vulnerability, please follow the following guidelines:
- 21 -
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.
[1] | (pipe sign)
[4] $ (dollar sign)
[6] @ (at sign)
[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

- 22 -
SQL Query in Parameter Value
Security Risks
Possible Causes
Parameter values were 'hardcoded' in the HTML as a parameter of type 'hidden'.
Web applications often use databases at the backend to interact with the enterprise data
warehouse. The de-facto standard language for querying databases is SQL (each major database
vendor has its own 'dialect'). In order to provide database functionality to the client, HTML pages
often contain complete SQL queries in form fields. For example, consider the following HTML
source snippet:
<FORM...>
...
<INPUT TYPE=HIDDEN NAME=SQL_QUERY VALUE="Select * from table1 where table1.id=1234">
...
</FORM>
This practice can lead to issues in the web application, since it is unlikely that the application
validates that the query is legitimate/unchanged. As a result, an attacker can modify the query
and manipulate the database.
Sample Exploit:
Consider the above HTML form example. It is possible to manually change the parameter value in
order to delete the table "table1", as following (submit the following form):
<FORM...>
...
<INPUT TYPE=HIDDEN NAME=SQL_QUERY VALUE="Drop table1">
...
</FORM>

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

WASC Threat Classification: SQL Injection
CWE-89: Failure to Preserve SQL Query Structure ('SQL Injection')
- 23 -
Cross-Site Request Forgery
Security Risks
Possible Causes
Insufficient authentication method was used by the application.
Cross-Site Request Forgery (CSRF) is an attack that allows a hacker to perform an action on the
vulnerable site on behalf of the victim. The attack is possible when the vulnerable site does not
properly validate the origin of the request.
The severity of this vulnerability depends on the functionality of the affected application, for
example, a CSRF attack on a search page is less severe than a CSRF attack on a money-transfer or
profile update pages.
The attack is performed by forcing the victim's browser to issue an HTTP request to the vulnerable
site. If the user is currently logged-in to the victim site, the request will automatically use the
user's credentials (like session cookies, user's IP address, and other browser authentication
methods). Using this method, the attacker forges the victim's identity and submits actions on his
or her behalf. In other words, the vulnerable site does not take the proper measures to validate
that the user indeed wanted to perform the specific action.
Forcing the victim to send the unintended request can be done in numerous ways:
- Sending the victim a malicious link to the vulnerable application via email.
- Putting a hot-link (like an image or frame) to the vulnerable site on the hacker's web page.
- Posting a link to the vulnerable site in a public forum.
- Using Cross-Site Scripting or Link Injection vulnerabilities in the site (or another site) and
automatically redirecting the browser to the vulnerable site.
If the attacker uses a Link Injection vulnerability on the vulnerable site itself he or she increases
the likelihood of the user being authenticated to the site, and by that increases the likelihood of
the attack to succeed.
For example, using any of the above described options, an attacker can lure the victim to view a
page containing:
<img src="http://bank/transfer?destination=John&money=1000" style='visibility:hidden'>
This will cause the victim's browser to automatically request the URL together with the current
credentials of the browser.
If this banking site is vulnerable to CSRF, it will transfer 1000 dollars from the victim's account to
John's bank account according to the application logic.
The Cross-Site Request Forgery attack is also known as CSRF (pronounced C-Serf), XSRF, Cross-
Site Reference Forgery, One-Click Attack and Session Riding.
You can verify that your application is vulnerable to CSRF by:

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

In order to avoid CSRF attacks, every request should contain a unique identifier, which is a
parameter that an attacker cannot guess.
One suggested option is to add the session id taken from the session cookie and adding it as a
parameter. The server must check that this parameter matches the session cookie, and if not
discard the request. The reason an 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.

Cross-site request forgery wiki page
"JavaScript Hijacking" by Fortify
Cross-Site Request Forgery Training Module
- 25 -
Link Injection (facilitates Cross-Site Request Forgery)
Security Risks
It is possible to persuade a naive user to supply sensitive information such as username,
password, credit card number, social security number etc.
It is possible to upload, modify or delete web pages, scripts and files on the web server.
Possible Causes
Link Injection is the act of modifying the content of a site by embedding in it a URL to an external
site, or to a script in the vulnerable site. By embedding a URL in the vulnerable site, an attacker is
then able to use it as a platform to launch attacks against other sites, as well as against the
vulnerable site itself.
Some of these possible attacks require the user to be logged in to the site during the attack. By
launching these attacks from the vulnerable site itself the attacker increases the chances of
success, because the user is more likely to be logged in.
The Link Injection vulnerability is a result of insufficient user input sanitation, which is later
returned to the user in the site response. The ability to inject hazardous characters into the
response makes it possible for attackers to embed URLs, among other possible content
modifications.
Below is an example for a Link Injection (We will assume that site "www.vulnerable.com" has a
parameter called "name", which is used to greet users).
The following request:

HTTP://www.vulnerable.com/greet.asp?name=John 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/ANYSCRIPT.
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.asp">.
</BODY>
</HTML>
As this example shows, it is possible to cause a user's browser to issue automatic requests to
virtually any site the attacker desires. As a result, he may use this Link Injection vulnerability to
launch several types of attacks:
Cross-Site Request Forgery:

An attacker is able to cause the user's browser to send a request to a site where the user is
currently logged in, and perform actions that the user did not intend to do. Such actions may
- 26 -
include unregistering from the site, or modifying the user's profile, email address or even
password, which could result in a complete account takeover.
Cross-Site Scripting:
Any Cross-Site scripting attack begins with the act of luring users into clicking a specially crafted
URL that exploits vulnerability in the victim site. This is usually done by sending emails that
contain the malicious link, or creating a web site that contains a link to the vulnerable site.
With the Link Injection vulnerability, it is possible to embed a malicious URL in site A, that when
clicked will launch a Cross-Site Scripting attack against site B.
Phishing:
It is possible for an attacker to inject a link to a malicious site that resembles the attacked site. 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.


[1] | (pipe sign)
[4] $ (dollar sign)
[6] @ (at sign)
[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

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')
- 27 -
Phishing through Frames
Security Risks
It is possible to persuade a naive user to supply sensitive information such as username,
password, credit card number, social security number etc.
Possible Causes
Phishing is a general term for attempts to scam users into surrendering private information that
will be used for identity theft.
It is possible for an attacker to inject a frame or an iframe tag with malicious content which
resembles the attacked site. An incautious user may browse it and not realize that he is leaving
the original site and surfing to a malicious site. The attacker may then lure the user to login again,
thus acquiring his login credentials.
The fact that the fake site is embedded in the original site helps the attacker by giving his phishing
attempts a more reliable appearance.
Sample Exploit:
If the parameter value is reflected in the response without proper sanitation, the following request:
http://[SERVER]/script.aspx?parameter=<frame name="evil" src="www.evil.com">
will cause the response to contain a frame to the evil site.


[1] | (pipe sign)
[4] $ (dollar sign)
[6] @ (at sign)
[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

FTC Consumer Alert - "How Not to Get Hooked by a 'Phishing' Scam"
CWE-301: Reflection Attack in an Authentication Protocol
- 28 -
Permanent Cookie Contains Sensitive Session Information
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).
During the application test, it was detected that sensitive session information such as user
credentials or session tokens was stored in a permanent cookie on the client's computer.
[1] Since other users may use the computer, this information may be compromised or used for
identity theft or user impersonation.
[2] If the computer will be compromised, the account information may be stolen and used later by
a malicious user.
In addition, several privacy regulations require that users will be identified uniquely before
accessing sensitive information. Since a permanent cookie may allow other users to logon to the
web application without authenticating, this may not comply with several privacy regulations.

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

Financial Privacy: The Gramm-Leach Bliley 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
- 29 -
Session Not Invalidated After Logout
Security Risks
Possible Causes
Insecure web application programming or configuration.
According to WASC:
"Insufficient Session Expiration is when a web site permits an attacker to reuse old session
credentials or session IDs for authorization. Insufficient Session Expiration increases a web site's
exposure to attacks that steal or impersonate other users."
After a user signs out of the application, the identifiers that were used during the session are
supposed to be invalidated. If the server fails to invalidate the session identifiers, it is possible for
other users to use those identifiers to impersonate that user and perform actions on his behalf.
Sample Exploit:
This test logs out of the application, and then tries to access a protected resource using the
session identifiers.
If the resource is retreived successfully, it means that the cookie was not expired by the server.

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

WASC Threat Classification: Insufficient Session Expiration
"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil Sit, Kendra Smith, Nick
Feamster - MIT Laboratory for Computer Science
CWE-613: Insufficient Session Expiration
- 30 -
Cacheable SSL Page Found
Security Risks
It is possible to gather sensitive information about the web application such as usernames,
passwords, machine name and/or sensitive file locations.
Possible Causes
Sensitive information might have been cached by your browser.
Most web browsers are configured by default to cache the user's pages during use. This means
that SSL pages are cached as well.
It is not recommended to enable the web browser to save any SSL information, since this
information might be compromised when a vulnerability exists.

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

N/A
- 31 -
HTML Comments Sensitive Information Disclosure
Security Risks
It is possible to gather sensitive information about the web application such as usernames,
passwords, machine name and/or sensitive file locations
Possible Causes
Debugging information was left by the programmer in web pages.
Many web application programmers use HTML comments to help debug the application when
needed. While adding general comments is very useful, some programmers tend to leave
important data, such as: filenames related to the web application, old links or links which were not
meant to be browsed by users, old code fragments, etc. An attacker who finds these comments
can map the application's structure and files, expose hidden parts of the site, and study the
fragments of code to reverse engineer the application, which may help develop further attacks
against the site.

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

WASC Threat Classification: Information Leakage
- 32 -
Missing Secure Attribute in Encrypted Session (SSL) Cookie
Security Risks
It may be possible to steal user and session information (cookies) that was sent during an
encrypted session.
Possible Causes
The web application sends non-secure cookies over SSL.
During the application test, it was detected that the tested web application set a cookie without
the "secure" attribute, during an encrypted session. Since this cookie does not contain the
"secure" attribute, it might also be sent to the site during an unencrypted session. Any information
such as cookies, session tokens or user credentials that are sent to the server as clear text, may
be stolen and used later for identity theft or user impersonation.
In addition, several privacy regulations state that sensitive information such as user credentials
will always be sent encrypted to the web site.

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

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

Sarbanes-Oxley Act
California SB1386
- 33 -
Query Parameter in SSL Request
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.
During the application test, it was detected that a request, which was sent over SSL, contained
parameters that were transmitted in the Query part of an HTTP GET request.
When sending GET requests, the browser's history can be used to reveal the URLs, which contain
the query parameter names and values.
Due to the sensitivity of encrypted requests, it is suggested to use HTTP POST when possible, in
order to avoid the disclosure of URLs and parameter values to others.

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

Sarbanes-Oxley Act
California SB1386
- 34 -
Cacheable Login Page Found
Security Risks
Possible Causes
Sensitive information might have been cached by your browser.
Most web browsers are configured by default to cache the user's pages during use. This means
that login pages are cached as well.
It is not recommended to enable the web browser to save any login information, since this
information might be compromised when a vulnerability exists.

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

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

1) Session Set-Up
The attacker sets up a "trap-session" for the target web site and obtains that session's ID, or the
attacker may select an arbitrary session ID used in the attack. In some cases, the established trap
session value must be maintained with repeated web site contact.
2) Session 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
- 36 -
A Cross-Site Scripting vulnerability on any web site in the domain can be used to modify the
current cookie value.
Code Snippet:
http://example/<script>document.cookie="sessionid=1234;%20domain=.example.dom";</script
>
Another similar example (using META tag injection):
http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%
20domain=.example.dom">
Issuing a cookie using an HTTP response header
The attacker forces the target web site, or any other site in the domain, to issue a session ID
cookie.
This can be achieved in many ways:
- Breaking into a web server in the domain (e.g., a poorly maintained WAP server)
- Poisoning a user's DNS server, effectively adding the attacker's web server to the domain
- Setting up a malicious web server in the domain (e.g., on a workstation in Windows 2000 domain,
all workstations are also in the DNS domain)
- Exploiting an HTTP response splitting attack"
----------------------------------------------
Comparison of the session identifiers before and after the login process revealed they were not
updated, which means that user impersonation may be possible. Preliminary knowledge of the
session identifier value may enable a remote attacker to pose as a logged-in legitimate user.
The session identifier value can be obtained by utilizing a Cross-Site Scripting vulnerability,
causing the victim's browser to use a predefined session identifier when contacting the vulnerable
site, or by launching a Session Fixation attack that will cause the site to present a predefined
session identifier to the victim's browser.

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

"Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security
PHP Manual, Session Handling Functions, Sessions and security
- 37 -
Inadequate Account Lockout
Security Risks
It might be possible to escalate user privileges and gain administrative permissions over the web
application.
Possible Causes
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 does not lock the tested account after several false attempts, the attacker may
eventually discover the account password and use it to impersonate the account's legitimate user.

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

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

SELECT COUNT(*) FROM accounts WHERE username='$user' AND password='$pass' Where $user
and $pass are user input (collected from the HTTP request which invoked the script that constructs
the query - either from a GET request query parameters, or from a POST request body
parameters). A regular usage of this query would be with values $user=john,
$password=secret123.
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.
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.

[1] | (pipe sign)
[4] $ (dollar sign)
- 39 -
[6] @ (at sign)

[13] + (plus sign)
[16] , (comma sign)
[17] \ (backslash)

- 40 -

Security Vulnerabilities in A Web Application

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Security Vulnerabilities in A Web Application

Încărcat de

Drepturi de autor:

Formate disponibile

Application Related Security

Vulnerabilities in a Web Application

Who should read this?

Document Revision History

Date Version Author Remarks

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

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

Stored Cross-Site Scripting...................................................................................................................................................12

Database Error Pattern Found.............................................................................................................................................20

SQL Query in Parameter Value............................................................................................................................................23

Cross-Site Request Forgery...................................................................................................................................................24

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

References and Relevant Links...........................................................................................................................................27

Phishing through Frames......................................................................................................................................................28

Permanent Cookie Contains Sensitive Session Information..............................................................................................29

Session Not Invalidated After Logout..................................................................................................................................30

Cacheable SSL Page Found...................................................................................................................................................31

HTML Comments Sensitive Information Disclosure.........................................................................................................32

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

Query Parameter in SSL Request.........................................................................................................................................34

Cacheable Login Page Found................................................................................................................................................35

Session Identifier Not Updated.............................................................................................................................................36

Inadequate Account Lockout................................................................................................................................................38

Authentication Bypass Using SQL Injection.......................................................................................................................39

1 Application Related Vulnerabilities

Possible actions that can be performed by the script are:

Date: Sun, 01 Jan 2002 00:31:19 GMT

Listed below are the different test variants:

A successful attack for this variant requires the following:

General Fix Recommendations

References and Relevant Links

Stored Cross-Site Scripting

Possible actions that can be performed by the script are:

[*] The response headers ("Content-Type: text/html; charset=[encoding]").

General Fix Recommendations

References and Relevant Links

The query formed would be:

General Fix Recommendations

It is advised to filter out all the following characters:

References and Relevant Links

Database Error Pattern Found

General Fix Recommendations

References and Relevant Links

SQL Query in Parameter Value

General Fix Recommendations

References and Relevant Links

Cross-Site Request Forgery

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

You can verify that your application is vulnerable to CSRF by:

General Fix Recommendations

References and Relevant Links

Link Injection (facilitates Cross-Site Request Forgery)

The following request:

Cross-Site Request Forgery:

General Fix Recommendations

It is advised to filter out all the following characters:

References and Relevant Links

Phishing through Frames

General Fix Recommendations

It is advised to filter out all the following characters:

References and Relevant Links

Permanent Cookie Contains Sensitive Session Information

General Fix Recommendations