Deutsche Version (DE_DE)
English version (EN_US)
Test Methods ( Detailed Overview )
Here is a list of every test performed by Web Scan Service.
Cross Site ScriptingRemediation Task
Filter out hazardous characters from user inputWASC ClassificationClient-side Attacks: Cross-site ScriptingAffected ProductsThis issue may affect different types of productsTechnical DescriptionCross Site Scripting enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by site owner.Fix RecommendationThere are several issues whose remediation lies in sanitizing user input.
By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.
It is advised to filter out all the following characters:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign) [4] $ (dollar sign) [5] % (percent sign) [6] @ (at sign) [7] ' (single apostrophe) [8] " (quotation mark) [9] \' (backslash-escaped apostrophe) [10] \" (backslash-escaped quotation mark) [11] <> (triangular parenthesis) [12] () (parenthesis) [13] + (plus sign) [14] CR (Carriage return, ASCII 0x0d) [15] LF (Line feed, ASCII 0x0a) [16] , (comma sign) [17] \ (backslash)
The following sections describe the various issues, their fix recommendations and the hazardous characters that might trigger these issues:
SQL injection and blind SQL injection:
A. Make sure the value and type (such as Integer, Date, etc.) of the user input is valid and expected by the application.
B. Use stored procedures to abstract data access so that users do not directly access tables or views. When using stored procedures, use the ADO command object to implement them, so that variables are strongly typed.
C. Sanitize input to exclude context-changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) [3] \' (backslash-escaped apostrophe) [4] \" (backslash-escaped quotation mark) [5] ) (closing parenthesis) [6] ; (semicolon)
Cross site scripting:
A. Sanitize user input and filter out JavaScript code. We suggest that you filter the following characters:
[1] <> (triangular parenthesis) [2] " (quotation mark) [3] ' (single apostrophe) [4] % (percent sign) [5] ; (semicolon) [6] () (parenthesis) [7] & (ampersand sign) [8] + (plus sign)B. To fix the <%00script> variant see MS article 821349
C. For UTF-7 attacks:
[-] When possible, it is recommended to enforce a specific charset encoding (using 'Content-Type' header or <meta> tag).
HTTP response splitting:
Sanitize user input (at least, such input that is later embedded in HTTP responses).
Make sure that malicious characters are not part of the input, such as:
[1] CR (Carriage return, ASCII 0x0d) [2] LF (Line feed, ASCII 0x0a)
Remote command execution:
Sanitize input to exclude symbols that are meaningful to the operating system's command execution, such as:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign)
Shell command execution:
A. Never pass unchecked user-input to Perl commands such as: eval(), open(), sysopen(), system().
B. Make sure malicious characters are not part of the input, such as:
[1] $ (dollar sign) [2] % (percent sign) [3] @ (at sign)
XPath injection:
Sanitize input to exclude context changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) Etc.
LDAP injection:
A. Use positive validation. Alphanumeric filtering (A..Z,a..z,0..9) is suitable for most LDAP queries.
B. Special LDAP characters which should be filtered out or escaped:
[1] A space or "#" character at the beginning of the string [2] A space character at the end of the string [3] , (comma sign) [4] + (plus sign) [5] " (quotation mark) [6] \ (backslash) [7] <> (triangular parenthesis) [8] ; (semicolon sign) [9] () (parenthesis)
Technical DescriptionCross Site Scripting enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by site owner.Fix RecommendationThere are several issues whose remediation lies in sanitizing user input.
By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.
It is advised to filter out all the following characters:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign) [4] $ (dollar sign) [5] % (percent sign) [6] @ (at sign) [7] ' (single apostrophe) [8] " (quotation mark) [9] \' (backslash-escaped apostrophe) [10] \" (backslash-escaped quotation mark) [11] <> (triangular parenthesis) [12] () (parenthesis) [13] + (plus sign) [14] CR (Carriage return, ASCII 0x0d) [15] LF (Line feed, ASCII 0x0a) [16] , (comma sign) [17] \ (backslash)
The following sections describe the various issues, their fix recommendations and the hazardous characters that might trigger these issues:
SQL injection and blind SQL injection:
A. Make sure the value and type (such as Integer, Date, etc.) of the user input is valid and expected by the application.
B. Use stored procedures to abstract data access so that users do not directly access tables or views. When using stored procedures, use the ADO command object to implement them, so that variables are strongly typed.
C. Sanitize input to exclude context-changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) [3] \' (backslash-escaped apostrophe) [4] \" (backslash-escaped quotation mark) [5] ) (closing parenthesis) [6] ; (semicolon)
Cross site scripting:
A. Sanitize user input and filter out JavaScript code. We suggest that you filter the following characters:
[1] <> (triangular parenthesis) [2] " (quotation mark) [3] ' (single apostrophe) [4] % (percent sign) [5] ; (semicolon) [6] () (parenthesis) [7] & (ampersand sign) [8] + (plus sign)B. To fix the <%00script> variant see MS article 821349
C. For UTF-7 attacks:
[-] When possible, it is recommended to enforce a specific charset encoding (using 'Content-Type' header or <meta> tag).
HTTP response splitting:
Sanitize user input (at least, such input that is later embedded in HTTP responses).
Make sure that malicious characters are not part of the input, such as:
[1] CR (Carriage return, ASCII 0x0d) [2] LF (Line feed, ASCII 0x0a)
Remote command execution:
Sanitize input to exclude symbols that are meaningful to the operating system's command execution, such as:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign)
Shell command execution:
A. Never pass unchecked user-input to Perl commands such as: eval(), open(), sysopen(), system().
B. Make sure malicious characters are not part of the input, such as:
[1] $ (dollar sign) [2] % (percent sign) [3] @ (at sign)
XPath injection:
Sanitize input to exclude context changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) Etc.
LDAP injection:
A. Use positive validation. Alphanumeric filtering (A..Z,a..z,0..9) is suitable for most LDAP queries.
B. Special LDAP characters which should be filtered out or escaped:
[1] A space or "#" character at the beginning of the string [2] A space character at the end of the string [3] , (comma sign) [4] + (plus sign) [5] " (quotation mark) [6] \ (backslash) [7] <> (triangular parenthesis) [8] ; (semicolon sign) [9] () (parenthesis)
There are several issues whose remediation lies in sanitizing user input.
By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.
It is advised to filter out all the following characters:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign) [4] $ (dollar sign) [5] % (percent sign) [6] @ (at sign) [7] ' (single apostrophe) [8] " (quotation mark) [9] \' (backslash-escaped apostrophe) [10] \" (backslash-escaped quotation mark) [11] <> (triangular parenthesis) [12] () (parenthesis) [13] + (plus sign) [14] CR (Carriage return, ASCII 0x0d) [15] LF (Line feed, ASCII 0x0a) [16] , (comma sign) [17] \ (backslash)
The following sections describe the various issues, their fix recommendations and the hazardous characters that might trigger these issues:
SQL injection and blind SQL injection:
A. Make sure the value and type (such as Integer, Date, etc.) of the user input is valid and expected by the application.
B. Use stored procedures to abstract data access so that users do not directly access tables or views. When using stored procedures, use the ADO command object to implement them, so that variables are strongly typed.
C. Sanitize input to exclude context-changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) [3] \' (backslash-escaped apostrophe) [4] \" (backslash-escaped quotation mark) [5] ) (closing parenthesis) [6] ; (semicolon)
Cross site scripting:
A. Sanitize user input and filter out JavaScript code. We suggest that you filter the following characters:
[1] <> (triangular parenthesis) [2] " (quotation mark) [3] ' (single apostrophe) [4] % (percent sign) [5] ; (semicolon) [6] () (parenthesis) [7] & (ampersand sign) [8] + (plus sign)B. To fix the <%00script> variant see MS article 821349
C. For UTF-7 attacks:
[-] When possible, it is recommended to enforce a specific charset encoding (using 'Content-Type' header or <meta> tag).
HTTP response splitting:
Sanitize user input (at least, such input that is later embedded in HTTP responses).
Make sure that malicious characters are not part of the input, such as:
[1] CR (Carriage return, ASCII 0x0d) [2] LF (Line feed, ASCII 0x0a)
Remote command execution:
Sanitize input to exclude symbols that are meaningful to the operating system's command execution, such as:
[1] | (pipe sign) [2] & (ampersand sign) [3] ; (semicolon sign)
Shell command execution:
A. Never pass unchecked user-input to Perl commands such as: eval(), open(), sysopen(), system().
B. Make sure malicious characters are not part of the input, such as:
[1] $ (dollar sign) [2] % (percent sign) [3] @ (at sign)
XPath injection:
Sanitize input to exclude context changing symbols such as:
[1] ' (single apostrophe) [2] " (quotation mark) Etc.
LDAP injection:
A. Use positive validation. Alphanumeric filtering (A..Z,a..z,0..9) is suitable for most LDAP queries.
B. Special LDAP characters which should be filtered out or escaped:
[1] A space or "#" character at the beginning of the string [2] A space character at the end of the string [3] , (comma sign) [4] + (plus sign) [5] " (quotation mark) [6] \ (backslash) [7] <> (triangular parenthesis) [8] ; (semicolon sign) [9] () (parenthesis)
