10016 Web Browser XSS Protection Not Enabled Web Browser XSS Protection Not Enabled 1 2 Low (Medium) Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection' HTTP response header on the web server http://demo.testfire.net/default.aspx?content=inside_press.htm GET X-XSS-Protection http://demo.testfire.net/high_yield_investments.htm GET X-XSS-Protection http://demo.testfire.net/disclaimer.htm?url=http://www.microsoft.com GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=pr/20060720.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=business_other.htm GET X-XSS-Protection http://demo.testfire.net/bank/login.aspx GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=business_insurance.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=privacy.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=inside_executives.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=business_lending.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=inside_jobs.htm GET X-XSS-Protection http://demo.testfire.net/search.aspx?txtSearch=ZAP GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=inside_contact.htm GET X-XSS-Protection http://demo.testfire.net/images/icon_top.gif GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=inside.htm GET X-XSS-Protection http://demo.testfire.net/bank/login.aspx POST X-XSS-Protection http://demo.testfire.net/default.aspx?content=jobs/20061024.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=inside_community.htm GET X-XSS-Protection http://demo.testfire.net/default.aspx?content=business_cards.htm GET X-XSS-Protection http://demo.testfire.net/security.htm GET X-XSS-Protection 62 Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'. The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism. The following values would attempt to enable it: X-XSS-Protection: 1; mode=blockX-XSS-Protection: 1; report=http://www.example.com/xssThe following values would disable it:X-XSS-Protection: 0The X-XSS-Protection HTTP response header is currently supported on Internet Explorer, Chrome and Safari (WebKit).Note that this alert is only raised if the response body could potentially contain an XSS payload (with a text-based content type, with a non-zero length). https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheethttps://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/ 933 14 3 10020 X-Frame-Options Header Not Set X-Frame-Options Header Not Set 2 2 Medium (Medium) X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks. http://demo.testfire.net/default.aspx?content=privacy.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_community.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=pr/20061005.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=jobs/20061024.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=business_lending.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=jobs/20061026.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=personal_loans.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_press.htm GET X-Frame-Options http://demo.testfire.net/bank/login.aspx POST X-Frame-Options http://demo.testfire.net/default.aspx?content=business_retirement.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=personal_investments.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=pr/20060720.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_jobs.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=business_deposit.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_trainee.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_investor.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=business_cards.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=personal_deposit.htm GET X-Frame-Options http://demo.testfire.net/default.aspx?content=inside_contact.htm GET X-Frame-Options 56 Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers). http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx 16 15 3 10021 X-Content-Type-Options Header Missing X-Content-Type-Options Header Missing 1 2 Low (Medium) The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing. http://demo.testfire.net/survey_questions.aspx?step=a GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=pr/20060928.htm GET X-Content-Type-Options http://demo.testfire.net/images/p_deposit.jpg GET X-Content-Type-Options http://demo.testfire.net/images/p_cards.jpg GET X-Content-Type-Options http://demo.testfire.net/survey_questions.aspx GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=inside_about.htm GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=personal_investments.htm GET X-Content-Type-Options http://demo.testfire.net/images/inside6.jpg GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=pr/20060413.htm GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=inside_trainee.htm GET X-Content-Type-Options http://demo.testfire.net/images/header_pic.jpg GET X-Content-Type-Options http://demo.testfire.net/style.css GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=personal.htm GET X-Content-Type-Options http://demo.testfire.net/images/pf_lock.gif GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=inside_internships.htm GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=personal_deposit.htm GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=personal_loans.htm GET X-Content-Type-Options http://demo.testfire.net/default.aspx?content=pr/20060817.htm GET X-Content-Type-Options http://demo.testfire.net/disclaimer.htm?url=http://www.netscape.com GET X-Content-Type-Options http://demo.testfire.net/images/p_checking.jpg GET X-Content-Type-Options 92 Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing. This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.At "High" threshold this scanner will not alert on client or server error responses. http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspxhttps://www.owasp.org/index.php/List_of_useful_HTTP_headers 16 15 3 10010 Cookie No HttpOnly Flag Cookie No HttpOnly Flag 1 2 Low (Medium) A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible. http://demo.testfire.net GET amSessionId Set-Cookie: amSessionId 1 Ensure that the HttpOnly flag is set for all cookies. http://www.owasp.org/index.php/HttpOnly 16 13 3 40012 Cross Site Scripting (Reflected) Cross Site Scripting (Reflected) 3 2 High (Medium) Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code. http://demo.testfire.net/search.aspx?txtSearch=%3C%2Fspan%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Cspan%3E GET txtSearch <script>alert(1);</script> <script>alert(1);</script> http://demo.testfire.net/notfound.aspx?aspxerrorpath=%3C%2Fb%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Cb%3E GET aspxerrorpath <script>alert(1);</script> <script>alert(1);</script> 2 Phase: Architecture and DesignUse a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.Phases: Implementation; Architecture and DesignUnderstand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.Phase: Architecture and DesignFor any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.Phase: ImplementationFor every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere. http://projects.webappsec.org/Cross-Site-Scriptinghttp://cwe.mitre.org/data/definitions/79.html 79 8 1 90022 Application Error Disclosure Application Error Disclosure 2 2 Medium (Medium) This page contains an error/warning message that may disclose sensitive information like the location of the file that produced the unhandled exception. This information can be used to launch further attacks against the web application. The alert could be a false positive if the error message is found inside a documentation page. http://demo.testfire.net/default.aspx?content=personal_savings.htm GET HTTP/1.1 500 Internal Server Error http://demo.testfire.net/comment.aspx POST HTTP/1.1 500 Internal Server Error 2 Review the source code of this page. Implement custom error pages. Consider implementing a mechanism to provide a unique error reference/identifier to the client (browser) while logging the details on the server side and not exposing them to the user. 200 13 3 0 Directory Browsing Directory Browsing 2 2 Medium (Medium) It is possible to view the directory listing. Directory listing may reveal hidden scripts, include files , backup source files etc which can be accessed to read sensitive information. http://demo.testfire.net/bank/ GET Parent Directory http://demo.testfire.net/pr/ GET Parent Directory 2 Disable directory browsing. If this is required, make sure the listed files does not induce risks. http://httpd.apache.org/docs/mod/core.html#optionshttp://alamo.satlug.org/pipermail/satlug/2002-February/000053.html 548 48 1 10017 Cross-Domain JavaScript Source File Inclusion Cross-Domain JavaScript Source File Inclusion 1 2 Low (Medium) The page includes one or more script files from a third-party domain. http://demo.testfire.net/default.aspx?content=personal_investments.htm GET http://demo-analytics.testfire.net/urchin.js <script src="http://demo-analytics.testfire.net/urchin.js" type="text/javascript"> </script> 1 Ensure JavaScript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application. 829 15 3 90030 WSDL File Passive Scanner WSDL File Passive Scanner 0 2 Informational (Medium) A WSDL File has been detected. http://demo.testfire.net/sitemap.xml GET text/xml 1 Make your WSDL files visible only for technical issues (p.e. testing purposes). A WSDL File has been detected. No references. 13 3