Checks make up the most useful part of Watcher - they provide analysis of the HTTP traffic and reporting of security findings. As someone running the tool you can enable, disable, and configure checks independently. As a developer you can create custom and new checks for private use or to contribute to the public project.

Watcher currently ships with 38 standard checks. A check is defined as one set of logic usually stored in a single source code file. Checks can look for multiple issues, so a single check can end up reporting several separate findings.

The contents below are dividied by the categories in which different checks operate. Within each category individual checks have been documented separately.

Contents

  1. ASP.NET checks
    1. Insecure VIEWSTATE tampering possibility
  2. Charset checks
    1. Charset declaration was not UTF-8
    2. A Charset mismatch was identified
  3. Cookie checks
    1. Loosely scoped cookie was identified
    2. Cookie's secure flag was not set
    3. Cookie's HttpOnly flag was not set
  4. Cross-Domain checks
    1. Cross-domain CSS resource
    2. Cross-domain JavaScript src reference
    3. Cross-domain JavaScript DOM reference
    4. Cross-domain Form action
  5. Flash checks
    1. Flash allows JavaScript access
    2. Flash Crossdomain.xml file contains insecure domain references
  6. HTTP Header checks
    1. Cache-Control not set to 'no-store'
    2. Content-Type declaration missing
    3. X-XSS-PROTECTION disables Internet Explorer protection
    4. X-XFRAMES-OPTIONS not set to prevent click-jacking
    5. X-CONTENT-TYPE-OPTIONS not set to prevent MIME-type sniffing
    6. Weak authentication
    7. Private IP address disclosure
  7. Information Disclosure checks
    1. Information disclosure in error messages
    2. Information disclosure in database error messages
    3. Information disclosure in comments
    4. Information disclosure in HTTP referrer
    5. Information disclosure in URL parameters
  8. Java checks
    1. Java Server MyFaces vulnerable to VIEWSTATE tampering
  9. Javascript checks
    1. Use of javascript eval methods
    2. Use of javascript domain lowering techniques
  10. Sharepoint checks
    1. Sharepoint insecure document library
  11. Silverlight checks
    1. Silverlight clientaccesspolicy.xml/crossdomain.xml contains insecure domain references
    2. Silverlight settings allow javascript access
  12. SSL checks
    1. Insecure transition from HTTP to HTTPS
    2. Insecure transition from HTTPS to HTTP
    3. SSL certificates failed validation
    4. Legacy SSL v2 protocol was accepted by server
  13. Unicode checks
    1. Ill-formed UTF-8 byte sequence was identified
  14. User-Controlled Input checks
    1. A user-controlled charset declaration was identified
    2. A potential cookie-poisoning vulnerability was found
    3. A potential XSS vulnerability was found
    4. A likely XSS vulnerability was found in a user-controlled page event
    5. A potential XSS vulnerability was found through a user-controlled javascript reference
    6. A user-controlled open redirect was identified


ASP.NET checks

Microsoft ASP.NET is a programming framework for building Web-applications.

1. ASP.NET VIEWSTATE vulnerable to tampering
Look for ASP.NET VIEWSTATE that has the MAC protection disabled. When disabled, the VIEWSTATE is vulnerable to tampering and XSS attacks - see the Trustwave advisory for details. Watcher checks the VIEWSTATE bydeserializing it with the LosFormatter class, then reserializing it and comparing the length of the two results. If the length's are equal, then a cryptographic MAC was not configured to protect the VIEWSTATE. If the length was different by 20 bytes (.NET 1.1 to .NET 3.5) or 32 bytes (.NET 4.0), then a MAC hash was protecting the VIEWSTATE.
Exploit scenario
By tampering with the VIEWSTATE an attacker could perform reflected or persistent XSS attacks.
Recommendation
Secure VIEWSTATE with a MAC by setting EnableViewStateMac to true, which is on by default.
References
Web Application Security Consoritum "Cross-site-scripting"
Vulnerability Summary for CVE-2010-2088
For code-level settings see MSDN "Page.EnableViewStateMac Property"
For web.config options see MSDN "pages Element (ASP.NET Settings Schema)"

Charset checks

HTTP responses as well as HTML, XML, and other text-based content are encoded using specific character encodings, dubbed 'charset' by W3 and other standards bodies. The concept of charsets is to allow for text to be transmitted, stored, and displayed in native languages, extending far beyond US-ASCII. Applications such as Web-browsers make decisions based on charset encodings, which are numerous and include legacy as well as modern Unicode encodings. If you can remember only one thing from here, remember to force all Web-pages to emit UTF-8.

1. Charset not explicitly set to UTF-8 in HTML/XML content
This check identifies HTTP headers, meta tags, and XML documents that don't explicitly set a charset value to UTF-8. UTF-8 is supported in all major Web browsers today, and from a security perspective it is the preferred charset for most Web-applications. When a charset is not explicitly declared, Web browsers are forced into an undesirable content-sniffing mode to determine the content's character set.
Exploit scenario
An attacker could manipulate content on the page to be interpreted in an encoding of their choice. For example, if an attacker can control content at the beginning of the page, they could inject script using UTF-7 encoded text and manipulate some browsers into interpreting that text.
Recommendation
Force UTF-8 for all text content, such as HTML and XML.
References
Browser Security Handbook


2. Detect charset mismatches between HTTP header and HTML/XML bodies
This check identifies responses where the HTTP Content-Type header declares a charset different from the charset defined by the body of the HTML or XML. When there's a charset mismatch between the HTTP header and content body Web browsers can be forced into an undesirable content-sniffing mode to determine the content's correct character set.
Exploit scenario
An attacker could manipulate content on the page to be interpreted in an encoding of their choice. For example, if an attacker can control content at the beginning of the page, they could inject script using UTF-7 encoded text and manipulate some browsers into interpreting that text.
Recommendation
Force UTF-8 for all text content in both the HTTP header and meta tags or encoding declarations in XML.
References
Browser Security Handbook

Cookie checks

Note that cookie checks are configurable with inclusive and exclusive filters. Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.


1. Look for cookies with loosely scoped domain restrictions
Cookies can be scoped by domain or path. This check is only concerned with domain scope.The domain scope applied to a cookie determines which domains can access it. For example, a cookie can be scoped strictly to a subdomain e.g. www.nottrusted.com, or loosely scoped to a parent domain e.g. nottrusted.com. In the latter case, any subdomain of nottrusted.com can access the cookieLoosely scoped cookies are common in mega-applications like google.com and live.com.
Exploit scenario
Cookies set from a subdomain like app.foo.bar are transmitted only to that domain by the browser. However, cookies scoped to a parent-level domain may be transmitted to the parent, or any subdomain of the parent.
Recommendation
Always scope cookies to a FQDN.
References
Browser Security Handbook



2. Look for cookies without the secure flag set
This check identifes cookies set over SSL which don't set the 'secure' flag. When a cookie is set with the 'secure' flag, it instructs the browser that the cookie can only be accessed over secure SSL channels. This is an important security protection for session cookies and other sensitive cookies that should never leak or be passed over an unencrypted channel.
Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.
Exploit scenario
Consider a session cookie that gets set over secure SSL or TLS channels (e.g. https://foo.bar), but without a 'secure' flag on the cookie. An attacker with local network access could steal those cookies by directing the user to an unencrypted channel (e.g. http://foo.bar) and sniffing the HTTP request from the network. In some cases, the cookies will be sent to unencrypted HTTP connections without any attacker intervention. This is common when fetching javascript and other resource files.
Recommendation
Always set the 'secure' flag for session cookies and other sensitive cookies that should never be sent over unencrypted channels.
References
Browser Security Handbook


3. Look for instances where the HTTPOnly flag is not set
This check looks for cookies that don't have the HTTPOnly flag set. The HttpOnly flag was invented to reduce the affect of XSS vulnerabilities, by preventing them from reading user cookies. When a cookie is set with the HTTPOnly flag, it instructs the browser that the cookie can only be accessed by the server. In other words, client-side script is forbidden from accessing the cookie. This is an important security protection for session cookies and other sensitive cookies, but less important for others.
Because Watcher can't distinguish between the important and unimportant cookies, you can configure an inclusive or exclusive list of cookie names to watch.
Exploit scenario
Consider a session cookie that gets set without the 'HttpOnly' flag. An attacker finding an XSS vulnerability in the web-application could inject javascript and read a victim's cookie, gaining access to their session or other sensitive information.
Recommendation
Always set the 'HttpOnly' flag for session cookies and other sensitive cookies that should never be read by javascript.
References
Browser Security Handbook


Cross-Domain checks

The term cross-domain refers to a domain other than the origin domain hosting the page. For example, if you're visiting a webpage at www.codeplex.com, then www.codeplex.com is the hosting domain, where www is the subdomain, and codeplex.com is the parent domain. In that case, images.codeplex.com would be considered cross-domain, since it is not the origin domain. Likewise, ads.google.com would be considered cross-domain. Cross-domain sites can be filtered out in Watcher's configuration - for example - if you wanted to ignore all references to any subdomain of codeplex.com and consider it part of the origin, then you could add *.codeplex.com as the origin domain.


1. Check for cross-domain CSS source file references, akin to client-side mashups
This check tries to identify cross-domain CSS stylesheet references in the page, e.g. import url('nottrusted.com/foo.css'). This can be an issue when untrusted CSS code gets introduced to the page, leading to XSS attacks, clickjacking attacks, and other exploits related to UI layout.
Exploit scenario
An attacker who can control a stylesheet loaded into the DOM of a site, could inject XSS through directives such as Internet Explorer's expression(). For example: * { width:expression(alert(1)); }
Recommendation
Ensure CSS files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Browser Security Handbook


2. Check for cross-domain javascript source file inclusion
This check tries to identify cross-domain javascript src references in the page, e.g. <script src='nottrusted.com'>. This can be an issue when untrusted javascript code gets introduced to the page.

Unfortunately, this is a typical pattern when third-party advertising and tracking code is used (e.g. Google Analytics or DoubleClick).
Exploit scenario
An attacker who can control javascript loaded into the DOM of a site can perform any malicious actions they desire on the site's visitors.
Recommendation
Ensure javascript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Web Application Security Consoritum "Cross-site-scripting"


3. Check for references to untrusted domains in javascript source
This check tries to identify javascript code that uses functions like createElement(tag) to programmatically add javascript src references to the DOM, and only reports when cross-domain javascript src references are made. This would be an issue when untrusted javascript code get introduced to the page.

Unfortunately, this is a typical pattern when third-party advertising and tracking code is used (e.g. Google Analytics or DoubleClick). Since this check doesn't implement a javascript interpreter we're limited to regular expressions to find these potential issues.
Exploit scenario
An attacker who can control references to javascript sources loaded into the DOM of a site can perform any malicious actions they desire on the site's visitors.
Recommendation
Ensure javascript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
References
Web Application Security Consoritum "Cross-site-scripting"



4. Check for cross-domain form submissions
Form-data sent to third-party sites may be considered a privacy violation. This check identifies HTML forms that post data offsite to a domain other than the origin domain. This would include subdomains if you didn't specify a wildcard or a trusted domain in your configuration, e.g. *.nottrusted.com.
Exploit scenario
Form-data sent to third-party sites may be an issue in and of itself. Worse yet would be the case where an attacker could control the location for the form-data to post to.
Recommendation
Ensure forms only post data to trusted locations, and that all data transmitted meet appropriate privacy requirements.
References

Flash checks


1. Look for instantiations of the Flash player which don't restrict javascript access
The Flash object includes a parameter named AllowScriptAccess which can be set to allow a Flash SWF file to access the browser's javascript DOM, even if the page embedding the SWF is different from the page hosting it. This means the SWF could inject javascript, open windows, or perform other dangerous actions if the SWF was vulnerable to such manipulation. Typical values are 'sameDomain', 'always', and 'never'. This check flags patterns which don't set this value to 'never', which allows script access. You may not be concerned when this value is set to 'sameDomain' as that limits the scope of access somewhat, however this gets flagged as well.
Exploit scenario
An attacker finds loads a vulnerable SWF file into their social networking blog (e.g. Spaces, Facebook, MySpace, etc.). If the social network sets the flag for AllowScriptAccess to always, then the attacker can inject into the DOM of that application, affecting all users who visit their page.
Recommendation
Set AllowScriptAccess to 'never'.
References
Adobe: Controlling access to scripts in a host web page


2. Look for issues with Flash cross-domain policy file
Flash objects can allow cross-domain access defined through a crossdomain.xml. This can introduce security vulnerability when access is allowed from untrusted domains. For example, if a wildcard '*' is set in the access list Flash will allow access from any domain. The potential security issues around this are numerous, for more info check out:
Exploit scenario
If an attacker can control code running in one of the cross-domain file's trusted domains, either via XSS or other injection, they can control the Flash object across domains. This vulnerability could be used to give the attacker access to cookies, cross-domain DOM information, and more.
Recommendation
Narrow the scope of a crossdomain.xml file to a small set of required hosts. Never use wildcards '*' to denote allowed domains.
References
Crossdomain.xml Invites Cross-site Mayhem
Adobe: Cross-domain policy file specification

HTTP Header checks


1. Check that the cache-control HTTP header is set to 'no-store'
Even in secure SSL channels sensitive data could be stored by intermediary proxies and SSL terminators. To direct such proxies from storing data, the 'no-store' Cache-Control header should be specified. This check will flag all SSL responses which don't set this value.

False positives are likey with this as the check doesn't have a good way to determine what's truly sensitive data and what's not.
Exploit scenario
When a cache-control directive is not set on sensitive content, a browser or proxy can cache it locally to disk. As an example, in a kiosk scenario, sensitive information could be stored locally when a user browses their online Web-based email, in which case the next person could easily retrieve the contents of their messages.
Recommendation
Set the cache-control directive to no-cache and no-store.
References
Cache Control Directives Demystified


2. Check that a Content-Type header is included in the HTTP response
This check flags HTTP responses which don't set a Content-Type value.The HTTP Content-Type header lets a browser know what type of content to expect e.g. HTML, javascript, images, media, etc. When a Content-Type value is not specified, the browser is forced to sniff the content to determine what it might be. Forcing browsers into this state is undesirable as it can lead to exploitable conditions.
Exploit scenario
An attacker finds a page that returns some user-controlled content (e.g. text or images) without setting the HTTP Content-Type header to the appropriate MIME value. The attacker can manipulate the content to exploit this condition, but forcing the browser into a state of content-sniffing, in which case the attacker could execute code through XSS attacks.
Recommendation
Ensure each page is setting the specific and appropriate content-type value for the content being delivered.
References
Browser Security Handbook


3. Check that IE's XSS protection filter is not being disabled by the Web-application
This check is specific to Internet Explorer 8. It flags when an HTTP response sets the 'X-XSS-Protection' header to a value of 0, which disables IE8's XSS protection filter.
Exploit scenario
An attacker finds a XSS vulnerability in a website, however it's mitigated by visitors using Internet Explorer 8 because of it's built-in XSS filter. Later the attacker finds a page that disables IE's filter, which they can now use to exploit visitors using IE.
Recommendation
If IE's XSS filter must be disabled for functional or other reasons, ensure that every page of the website is properly sanitizing user input and output, and well-protected against XSS vulnerability.
References
XSS defenses in Internet Explorer


4. Check that the X-FRAME-OPTIONS header is being set for Clickjacking defense
Including the X-FRAME-OPTIONS header in the server HTTP response instructs the browser to prevent the web page from being displayed in a subframe of the page. That is, it's a security measure similar to 'framebusting' which prevents malicious websites from hosting your website in an iframe. This check flags HTTP responses which don't set this header.
Exploit scenario
A malicious website wants to spoof your company's website and capture user login credentials. They craft a webpage that loads your website into an iframe, then they use style sheets to layover your site's login form with their own malicious form. When users land on the malicious website they could be fooled into logging in and compromising their account credentials.
Recommendation
Most modern Web browsers support the X-FRAME-OPTIONS HTTP header, ensure it's set on all web pages returned by your site.
References
Clickjacking defenses in Internet Explorer


5. Checks that the X-CONTENT-TYPE-OPTIONS defense against MIME-sniffing has been declared
This check is specific to Internet Explorer 8 and Google Chrome. It flags HTTP responses which don't set the X-CONTENT-TYPE-OPTIONS header in responses. This 'nosniff' HTTP header is used by certain browsers such as IE8 and Chrome to reduce the potential for vulnerability that can occur when an attacker can trigger and manipulate a browser's MIME-sniffing behavior.
Exploit scenario
An attacker finds a page that returns some user-controlled content (e.g. text or images) without setting the HTTP Content-Type header to the appropriate MIME value. The attacker can manipulate the content to exploit this condition, but forcing the browser into a state of content-sniffing, in which case the attacker could execute code through XSS attacks.
Recommendation
Ensure each page sets a Content-Type header and the X-CONTENT-TYPE-OPTIONS if the Content-Type header is unknown.
References
Browser Security Handbook
MSDN IE Blog


6. Look for weak authentication protocols
This check flags HTTP responses which request a weak authentication protocol such as Basic or Digest.You will need to determine whether this would be considered a vulnerability in your organization. Typically usage of these protocols are frowned upon but can be protected from snooping by using SSL channels.
Exploit scenario
An attacker could snoop on the credentials of a user logging into a site using Basic authentication without SSL enabled.
Recommendation
Ensure SSL is being forced for basic and digest
References
Browser Security Handbook


7. Look for private IP address disclosure
This check applies a regular expression to all HTTP headers to identify non-routable private IP addresses as defined in RFC 1918.
Exploit scenario
Disclosure of internal, or private, IP addresses provides network information useful to an attacker. It may be possible to abuse load balancers, proxies, or even Web servers when internal IP addresses are known.
Recommendation
Ensure private IP addresses are not revealed. Each server or load balancer may have a different configuration to control this. For example, Microsoft IIS provides some settings that will ensure the hostname is always returned instead of the internal IP address, when a request does not include a host header. See http://support.microsoft.com/kb/834141.
References
RFC 1918

Information Disclosure checks


1. Check for common debugging error messages
This check will search HTML content, including comments, for common error messages returned by platforms such as ASP.NET, and Web-servers such as IIS and Apache. You can configure the list of common debug messages.
Exploit scenario
An attacker finds path information through a stack trace returned in an error page. Using the path, the attacker is able to access sensitive files and/or functionality.
Recommendation
Disable debugging messages before pushing to production.
References
Web Application Security Consoritum "Information Leakage"
OWAS ASVS "ASVL 1 and 2"


2. Check for common error messages returned by databases (may indicate SQL injection)
This check will review HTML content, including comments, for common error messages returned by database providers such as MSSQL, MySQL, and Oracle. If found, this may indicate SQL injection potential, which will need to be tested separately. You can configure the list of common error messages.
Exploit scenario
An attacker finds SQL query information through a stack trace returned in an error page. Using this information, the attacker is able to craft a query and bypass security checks.
Recommendation
Disable debugging messages before pushing to production.
References
Web Application Security Consoritum "Information Leakage"
OWAS ASVS "ASVL 1 and 2"


3. Check for dubious comments
This check looks for common patterns in HTML and javascript comments that may be useful to inspect in a security review or audit. This performs a pattern match looking for a list of words like BUG, TODO, and profanity. You can configure the list of words to search.
Exploit scenario
An attacker finds comments in the HTML and/or javascript of an application. The comments reveal information about bugs the application hasn't been able to fix, enabling the attacker to use the bugs to their advantage.
Recommendation
Scrub all comments before pushing to production.
References
Web Application Security Consoritum "Information Leakage"


4. Look for sensitive information passed through HTTP request referrer headers
This check looks for string patterns to identify sensitive information leaked in the HTTP Referrer headers. This can violate PCI and most organizational compliance policies. You can configure the list of strings for this check to add or remove values specific to your environment. In addition this check will look for credit card numbers, SSN's, and email addresses.
Exploit scenario
An attacker is able to embed a link in your application which directs to their own website. As the referrer information is passed to the attacker's website, they can collect all information from the referring URL.
Recommendation
Do not pass sensitive information in URI's.
References
Hypertext Transfer Protocol -- HTTP/1.1 "Security Considerations"


5. Look for sensitive information passed through URL parameter
This check looks for string patterns to identify sensitive information leaked in the URL. This can violate PCI and most organizational compliance policies. You can configure the list of strings for this check to add or remove values specific to your environment. In addition this check will find credit card numbers, SSN's, and email addresses.
Exploit scenario
Sensitive information passed in the URL gets logged to an intervening proxy cache, where it gets recorded to disk and is subject to eavesdropping. The same URL's can also be recorded in the Web browser's history. In a kiosk or shared computer scenario this could be a real danger.
Recommendation
Do not pass sensitive information in URI's.
References
Hypertext Transfer Protocol -- HTTP/1.1 "Security Considerations"

Java checks


1. JavaServer Faces - identify when ViewState data is insecure.
This check looks at JavaServer Faces values implemented in Apache MyFaces and Sun's Mojarra project, to detect when cryptographic protection has been disabled. If disabled, it's possible for attackers to tamper with the ViewState and create XSS attacks.
Exploit scenario
By tampering with the VIEWSTATE an attacker could perform reflected or persistent XSS attacks.
Recommendation
Secure VIEWSTATE with a MAC specific to your environment.
References
Web Application Security Consoritum "Cross-site-scripting"
Trustwave advisory

Javascript checks


1. Examine javascript code for use of dangerous eval() methods
This check identifies the use of eval(), setTimeout(), and setInterval() in javascript code. These functions evaluate a string and execute it as javascript code. When they're passed attacker-controlled values, cross-site scripting and other attacks could be possible. These findings should be reviewed by a security analyst for exploitability. Their use may also violate your organizational policy.
Exploit scenario
An eval statement in the web-application takes user-input from a JSON response. An attacker can easily control the string passed to eval(string) to perform an XSS attack.
Recommendation
Never pass un-sanitized user-input to eval() statements. Replace eval() statements with safe
References
Web Application Security Consoritum "Cross-site-scripting"


2. Examine javascript code for domain lowering tactics
Domain lowering is a method commonly used for sharing functionality across subdomains of a site. For example, when sub.foo.bar wants to access data or functions in sub2.foo.bar, it can 'lower' the document.domain property to foo.bar in javascript. This will create a cross-domain scenario where all subdomains of foo.bar can communicate freely.
Exploit scenario
Recommendation
Avoid domain lowering.
References
MSDN CROSS-DOMAIN COMMUNICATION USING DOMAIN LOWERING


Sharepoint checks


1. Look for dangerous HTML content hosted in the Shared Document Library
This check flags SharePoint document libraries which return HTML content without setting the Content-Disposition HTTP header. Setting this header tells the Web browser to download the content rather than to parse and display it. Without setting this header, users could upload malicious HTML content that would load and execute in a visitor's browser.
Exploit scenario
An attacker hosts an HTML page in the Sharepoint doclib. When a user loads that file it will get rendered in the browser as HTML from the site.
Recommendation
You need to force the Content-Disposition HTTP header on doclibs to force downloads, otherwise a .html file will get rendered in the browser as HTML from the site.
References
How To Raise a "File Download" Dialog Box for a Known MIME Type


Silverlight checks


1. Search for insecure domain references in Silverlight client access policy
Silverlight assemblies can allow cross-domain access defined through a clientaccesspolicy.xml or crossdomain.xml. This can introduce security vulnerability when access is allowed to and from untrusted domains. For example, if a wildcard '*' is set in the access list Silverlight assemblies may introduce Cross-Site Request Forgery or other issues. The potential security issues around this are numerous depending on the functionality of the application, for more info check out the Silverlight security white paper referenced.
Exploit scenario
Recommendation
Narrow the scope of a crossdomain.xml file to a small set of required hosts. Never use wildcards '*' to denote allowed domains.
References
Security Guidance for Writing and Deploying Silverlight Applications
Silverlight 4 security overview whitepaper


2. Look for instantiations of Silverlight Player which don't restrict javascript access.
The Silverlight object includes a parameter named EnableHtmlAccess which can be used to scope how javascript can access the Silverlight code. Values can be either true or false.This check flags patterns which don't set this value to 'false', which allows script access.
Exploit scenario
Recommendation
References
Security Guidance for Writing and Deploying Silverlight Applications
Silverlight 4 security overview whitepaper
MSDN Silverlight Security

SSL checks


1. Look for insecure transition from HTTP to HTTPS during form post
This check looks for insecure HTTP pages that host HTTPS forms. The issue is that an insecure HTTP page can easily be hijacked through MITM and the secure HTTPS form can be replaced or spoofed.
Exploit scenario
Because an HTTP page is sent over unsecured channels, an attacker could modify HTML content via man-in-the-middle attack, and change the form post action to point to a malicious website.
Recommendation
Use HTTPS for landing pages that host secure forms.
References


2. Look for insecure transition from HTTPS to HTTP during form post
This check identifies secure HTTPS pages that host insecure HTTP forms. The issue is that a secure page is transitioning to an insecure page when data is uploaded through a form. The user may think they're submitting data to a secure page when in fact they are not.
Exploit scenario
When data is sent to in the clear, it's subject to snooping and tampering.
Recommendation
Ensure sensitive data is only sent over secured HTTPS channels.
References


3. Check SSL certificate validation
This check validates SSL certificates and reports a finding when validation errors such as host name mis-match and expiration are found. If configured, this check will also attempt to walk the certificate chain and perform CRL revocation checking.
Exploit scenario
SSL certificates provide a way to verify the authenticity of the server in some regards, such as the hostname and expiration date of the cert.
Recommendation
Websites should use SSL certificates that match their selected hostnames, and should be re-provisioned prior to expiration.
References


4. SSLv2 protocol check
When an SSL connection is initiated, this check attempts to connect to the server using the insecure SSL v2 protocol. If the server allows this, a finding is reported. Most servers today should support SSL v3 and disallow the legacy versions of SSL.
Exploit scenario
SSLv2 is vulnerable to a number of security issues, making it undesirable in production use.
Recommendation
Ensure that SSL version 3.0 or TLS are being forced, and SSL v2 is prohibited on the server-side application.
References
Wikipedia

Unicode checks


1. Identify ill-formed Unicode UTF-8 content, and null bytes in HTML
This check reviews the byte stream of an UTF-8 encoded HTML page, and identifies ill-formed byte sequences as well as null bytes. When a web-app emits illegal UTF-8 byte sequences, then something more detrimental could be happening deeper in the server-side code.

The types of ill-formed byte sequences detected include:
  • Valid lead byte, followed by one or more invalid trailing bytes
  • Non-shortest form (overlong) UTF-8
  • Invalid lead byte
Exploit scenario
By injecting illegal UTF-8 byte sequences, an attacker may be able to bypass security filters or other boundaries. Worse still they may be able to perform remote code execution attacks on the server through buffer or integer overflows.
Recommendation
If an alert is returned from this check, have a developer investigate the string handling on the server-side to identify how the string is being handled.
References
http://www.lookout.net/2009/03/25/detecting-ill-formed-utf-8-byte-sequences-in-html-content/

User-Controlled Input checks


1. Charset values
This check looks at user-supplied input in query string parameters and POST data to identify where Content-Type or meta tag charset declarations might be user-controlled. Such charset declarations should always be declared by the application. If an attacker can control the response charset, they could manipulate the HTML to perform XSS or other attacks.
Exploit scenario
An attacker controlling the <meta> element charset value is able to declare UTF-7 and is also able to include enough user-controlled payload early in the HTML document to have it interpreted as UTF-7. By encoding their payload with UTF-7 the attacker is able to bypass any server-side XSS protections and embed script in the page.
Recommendation
Force UTF-8 in all charset declarations. If user-input is required to decide a charset declaration, ensure that only an allowed list is used.
References


2. Cookie poisoning
This check looks at user-supplied input in query string parameters and POST data to identify where cookie parameters might be controlled. This is called a cookie poisoning attack, and becomes exploitable when an attacker can manipulate the cookie in nafarious ways. In some cases this will not be exploitable, however, allowing URL parameters to set cookie values is generally considered a bug.
Exploit scenario
Recommendation
Do not allow user input to control cookie names and values. If some query string parameters must be set in cookie values, be sure to filter out semicolon's that can serve as name/value pair delimiters.
References


3. HTML element attributes (potential XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker could control an html href attribute to inject script using syntax like javascript:alert(1);
Recommendation
Validate all input and sanitize output it before writing to any HTML attributes.
References
Web Application Security Consoritum "Cross-site-scripting"


4. Javascript events (likely XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain javascript events (e.g. onclick) might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker who can control the string passed to a javascript on* event can likely execute script in the DOM of the page.
Recommendation
Validate all input and sanitize it before writing to any on* events.
References
Web Application Security Consoritum "Cross-site-scripting"


5. Javascript references (potential XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where URL's in certain javascript properties (e.g. createElement src) might becontrolled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Exploit scenario
An attacker who can control the reference location to a javascript source file can load script of their choice into an application.
Recommendation
Do not allow user-input to control javascript source location references.
References


6. Open redirect
Open redirects are one of the OWASP 2010 Top Ten vulnerabilities. This check looks at user-supplied input in query string parameters and POST data to identify where open redirects might be possible. Open redirects occur when an application allows user-supplied input (e.g. http://nottrusted.com) to control an offsite redirect. This is generally a pretty accurate way to find where 301 or 302 redirects could be exploited by spammers or phishing attacks.
Exploit scenario
An attacker finds an open redirect on a site that looks like http://www.foo.bar?redirect=http://www.nottrusted.com. They leverage this to craft a mass phishing attack and coerce users to clicking the link and downloading malware. Because the malicious link is often out of view and loaded from a trusted domain, naive end users will not suspect any foul play.
Recommendation
Implement safe redirect functionality that only redirects to relative URI's, or a list of trusted domains.
References
OWASP top ten

Last edited Oct 1, 2011 at 8:42 PM by chrisweber, version 35

Comments

No comments yet.