Cross-Site Scripting: Reflected - http://zero.webappsecurity.com:80/join.asp?name=&email=&surname=%22%3e%3csCrIpT%3ealert(18247)%3c%2fsCrIpT%3e&house=&street=&address2=&town=&postcode=&country=&homephone=&mobilephone=&msg=Please+fill+in+your+name
Created by: armorcodegithubapp[bot]
Category: Cross-Site Scripting: Reflected
Scan Type: Dynamic
CheckType: Vulnerability
Abstract:
A Cross-Site Scripting (XSS) vulnerability was detected in the web application. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. In this instance, the web application was vulnerable to an automatic payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross-Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Recommendations include implementing secure programming techniques that ensure proper filtration of user-supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a format that can be executed.
Request: GET /join.asp?name=&email=&surname=%22%3e%3csCrIpT%3ealert(18247)%3c%2fsCrIpT%3e&house=&street=&address2=&town=&postcode=&country=&homephone=&mobilephone=&msg=Please+fill+in+your+name HTTP/1.1
Referer: http://zero.webappsecurity.com:80/join1.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Accept: /
Pragma: no-cache
Host: zero.webappsecurity.com
X-Scan-Memo: Category="Audit"; Function="createStateRequestFromAttackDefinition"; SID="BB49F6B00E240C2B14422463C8065375"; PSID="62F0ACFFC03919EC68870F363A133936"; SessionType="AuditAttack"; CrawlType="None"; AttackType="QueryParamManipulation"; OriginatingEngineID="1354e211-9d7d-4cc1-80e6-4de3fd128002"; AttackSequence="2"; AttackParamDesc="surname"; AttackParamIndex="2"; AttackParamSubIndex="0"; CheckId="(null)"; Engine="Cross+Site+Scripting"; Retry="False"; SmartMode="NonServerSpecificOnly"; AttackString="%2522%253e%253csCrIpT%253ealert(18247)%253c%252fsCrIpT%253e";
Connection: Keep-Alive
Cookie: CustomCookie=WebInspect69383ZXB3FCEA2CCD6849B0A63D3EFF65615601Y3637;status=yes;username=;userid=;sessionid=;ASPSESSIONIDCARBTACT=ICEJMBECJHFNADIHCNBMIDHJ;state=;passes3=;passes=;passes2=;Keyed=Var2=Second+Value&Var1=First+Value;Second=Oatmal+Chocolate;FirstCookie=Chocolate+Chip
File Path: //zero.webappsecurity.com:0
Mitigation:
For Development:
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. When validating user input,
verify that it matches the strictest definition of valid input possible. For example, if a certain parameter is supposed to be a number, attempt
to convert it to a numeric data type in your programming language.
PHP: intval("0".$_GET['q']);
ASP.NET:
int.TryParse(Request.QueryString["q"], out val);
The same applies to date and time values, or anything that can be converted to a stricter type before being used. When accepting other types of
text input, make sure the value matches either a list of acceptable values (white-listing), or a strict regular expression. If at any point the
value appears invalid, do not accept it. Also, do not attempt to return the value to the user in an error message.
Most server side scripting languages provide built in methods to convert the value of the input variable into correct, non-interpretable HTML.
These should be used to sanitize all input before it is displayed to the client.
PHP: string htmlspecialchars (string string
[, int quote_style])
ASP.NET: Server.HTMLEncode (strHTML String)
When reflecting values into JavaScript or another format, make sure to use a type of encoding that is appropriate. Encoding data for HTML is not
sufficient when it is reflected inside of a script or style sheet. For example, when reflecting data in a JavaScript string, make sure to encode
all non-alphanumeric characters using hex (\xHH) encoding.
If you have JavaScript on your page that accesses unsafe information (like location.href) and writes it to the page (either with document.write,
or by modifying a DOM element), make sure you encode data for HTML before writing it to the page. JavaScript does not have a built-in function to
do this, but many frameworks do. If you are lacking an available function, something like the following will handle most cases:
s = s.replace(/&/g,'&').replace(/"/i,'"').replace(/</i,'<').replace(/>/i,'>').replace(/'/i,''')
Ensure that you are always using the right approach at the right time. Validating user input should be done as soon as it is received. Encoding
data for display should be done immediately before displaying it.
For Security Operations:
Server-side encoding, where all dynamic content is first sent through an encoding function where Scripting tags will be replaced with codes in the
selected character set, can help to prevent Cross-Site Scripting attacks.
Many web application platforms and frameworks have some built-in support for preventing Cross-Site Scripting. Make sure that any built-in
protection is enabled for your platform. In some cases, a misconfiguration could allow Cross-Site Scripting. In ASP.NET, if a page's
EnableViewStateMac property is set to False, the ASP.NET view state can be used as a vector for Cross-Site Scripting.
An IDS or IPS can also be used to detect or filter out XSS attacks. Below are a few regular expressions that will help detect Cross-Site
Scripting.
Regex for a simple XSS attack:
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site Scripting attempt"; flow:to_server,established;
pcre:"/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Paranoid regex for
XSS attacks:
/((%3C)|<)[^\n]+((%3E)|>)/I
This signature simply looks for the opening HTML tag, and its hex equivalent, followed by one or more characters other than the new line, and then
followed by the closing tag or its hex equivalent. This may end up giving a few false positives depending upon how your web application and web
server are structured, but it is guaranteed to catch anything that even remotely resembles a Cross-Site Scripting attack.
For QA:
Fixes for Cross-Site Scripting defects will ultimately require code based fixes.
https://app.armorcode.com/#/findings/62962317
Knowledge Base: Man in the Middle (MITM) Attack:https://app.armorcode.com/#/knowledgeBase/45