Beta

Automated Security Analyser for ASP.NET Websites


Scans overview

Its early days for ASafaWeb so it's kicked off with a baseline of scans for common ASP.NET configuration related vulnerabilities. New scans will be added in the future.

For each of the scans listed below, different request patterns may be executed to attempt to identify the website's configuration. The request pattern will differ from site to site and it's fully explained when the scan is actually run.

Many scans looks for the presence of a particular markup pattern in the response. By looking for a pattern rather than for content, ASafaWeb is able to identify responses in different languages which all have the same HTML structure.

Tracing

Is tracing still on and publicly accessible. This scan makes a request for "/trace.axd" and looks for the presence of a heading titled "Application Trace" or markup matching the pattern <span class="tracecontent"><a href="trace.axd?clear=1" class="link">.

Custom errors

Have custom errors been enabled and a default redirect page defined for a custom error page. This scan is run after some of the ones below as an error page may have already been encountered from one of these. Both the hash DoS and request validation tests can cause a server error so the results from these are inspected first.

If an error hasn't been found yet and the app is a web forms site (as indicated by the presence of View State), an attempt is made to post an invalid View State to the site. This should cause an HTTP 500 "Internal server error" to be raised.

If the previous step can't cause a yellow screen of death (YSOD) to be returned, an attempt is made to access an invalid URL by appending an escaped left angle bracket. This should consistently return an HTTP 400 "Bad request" as the "<" symbol is an illegal URL character.

If no error has been caused yet, the request(s) from the tracing scan above are inspected. These may cause an error but if they do, it won't contain a stack trace so they can't be used in the next scan below.

If none of these approaches return a YSOD, a request is made for "/foo/Trace.axd" which should always be invalid. This should return an HTTP 403 "Forbidden" as the path is invalid and it won't be able to load the trace. It also won't contain a stack trace.

When the response is returned from each of the custom errors tests listed above, it's inspected for the presence of a heading containing the words "Server Error in" or markup matching the pattern <body bgcolor="white"><span><H1><hr width=100% size=1 color=silver>. This confirms no default redirect page is defined for that error.

Stack trace

Was a stack trace returned in the custom errors scan above. This is identified by the presence of a <b>Stack Trace:</b> entry or the markup pattern <br><b>[text]</b><br><br> within an error page from the custom errors scan.

Request validation

This test is run for web forms sites only as it can't be reliably tested for in MVC sites. The test appends a "?<script>" query string to the original URL entered and checks the response body. When request validation is on, a different response should be received from the application (normally an error page). If the same response body is received (after some basic cleansing to remove patterns which regularly change between requests), as for a legitimate request to the URL, request validation is probably turned off.

Note: when looking for matching response bodies, some tags are omitted from the comparison as they often hold dynamic content such as banner advertising which can change between requests.

HTTP to HTTPS redirect

Are HTTP requests redirecting to an HTTPS address (potential man in the middle vulnerability). This is simply tested by comparing the scheme the request was made to with the scheme in the response after any redirects are processed. If this pattern is identified, it's reported as a warning given the usability impact of not redirecting requests made using the default HTTP scheme.

Hash DoS patch

Has the hash DoS patch released in Microsoft Security Bulletin MS11-100 been applied or does .NET 4.5 exist which fixes the root cause. When the patch doesn't exist or the framework is older, the site is highly vulnerable to a denial of service attack following the disclosure of a hash collision vulnerability which consumes all available CPU resources.

This test runs by looking for the version of .NET running and posting 1,001 form variables to the site. Each variable has a sequentially incrementing name from "0" to "1000" and no corresponding value. Older sites with the patch will return an error whereas sites without the patch will return an identical response to a legitimate request for the same resource. Sites running under .NET 4 and with .NET 4.5 installed (whether compiled against it or nor), will not return an error and are not vulnerable.

Publicly accessible ELMAH logs

ELMAH is a fantastic tool for logging and reviewing internal errors but it also contains sensitive information which can be used to exploit the website. Many sites leave ELMAH publicly accessible without any access control which poses a serious risk to the application

The ELMAH scan makes a request to the "/elmah.axd" path which is the default handler path for ELMAH. If the response returns a page with a title containing the words "Error log for" then ELMAH is present and not secured.

If the page redirects to a logon page using forms authentication — identified by the query string containing "ReturnUrl=" — then the path "/foo/elmah.axd" is also tested. This is due to the guidance for securing ELMAH incorrectly stating that only "/elmah.axd" needs to be protected whereas in reality, the default setting will allow the handler to serve requests to any path.

Excessive headers

By default, an ASP.NET application running on IIS returns a lot of information about the server and framework via the headers. This information can be used to help exploit vulnerabilities that are present in the technologies the headers identify. If any of the following response headers are returned, ASafaWeb will report a warning for this scan:

  1. Server
  2. X-Powered-By
  3. X-AspNet-Version
  4. X-AspNetMvc-Version

HTTP only cookies

All cookies have the ability to be flagged as "HttpOnly" which ensures they cannot be accessed via client side scripting. When this flag isn't set, the extent of potential damage an XSS attack can do increases as it opens the possibility of attacks involving cookie theft such as session hijacking.

When this test runs, ASafaWeb looks at the responses from each request and identifies any cookies returned that aren't flagged as "HttpOnly". If any exist, the test will show a warning rather than a failure because there are legitimate cases where client script needs to read cookies set by the server.

Secure cookies

This is quite similar to the HTTP only cookies scan in that all cookies also have the ability to be flagged "Secure" which ensures they will not be sent by the browser over an HTTP connection. When this flag isn't set, a simple oversight such as requesting a bitmap over HTTP puts the cookie at risk of interception by a man in the middle.

Also similar to the HTTP only scan, ASafaWeb looks for any HTTPS responses and identifies any cookies returned that aren't flagged as "Secure". If any exist, the test will show a warning rather than a failure because there are legitimate cases where cookies need to be sent across both the HTTP and HTTPS schemes.

Clickjacking

Clickjacking involves an attacker embedding the target website in a frame and tricking users into clicking on links. Usually this involves creating a rogue website that entices the user to click on text which actually sits underneath the target site which is made invisible by adjusting the opacity level.

This scan looks for defence by way of the server returning an "X-Frame-Options" header (XFO). This header instructs the browser as to how the page may be framed, if at all. When no header exists, the site may be loaded into a frame which then poses a clickjacking risk. The test is performed only against the requested URL and none of the pages loaded in the ASafaWeb scan as it's possible to have different XFO policies on different pages.

View state MAC

By default, the integrity of the view state in a web forms application is checked by including a MAC (message authentication code) which is validated when the view state is posted back to the server. This is an essential security defence as it prohibits an attacker tampering with the view state which can have a serious adverse impact on the security position of the web site.

View state MAC is sometimes disabled which can pose a serious risk to the application. ASafaWeb inspects the view state returned by other scans and checks to ensure a valid MAC exists.