Ends in:
01 DAYS
01 HRS
01 MIN
01 SEC
Project

ASP.NET ZERO Penetration Test Report

Asp.Net Zero has been scanned for vulnerabilities with the OWASP ZAP (v2.7.0). The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular security tools and is actively maintained by hundreds of international volunteers.

The automated scanner has been reported several alerts. Asp.Net Zero Team has fixed the positive alerts regarding the report. On the other hand most of the alerts can be stated as false-positive. The reasons for the false-positive alerts that are subject to these issues are clearly stated below.

Summary of Alerts

Path Traversal

High (Medium)

Description

The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory.

Comment

The report has stated some CSS, JS links are open to path traversal attack. But these alerts are false-positive. You can see the reasons why they are evaluated as false-positive.

Recommendation

If your application has to accept input file names, file paths, or URL paths, you need to validate that the path is in the correct format and that it points to a valid location within the context of your application. To prevent a malicious user manipulating your code's file operations, avoid writing code that accepts user-supplied file or path input.

  • If you must accept file names as input, use the full name of the file by using System.IO.Path.GetFileName.
  • If you must accept file paths as input, use the full file path by using System.IO.Path.GetFullPath.

If you use MapPath to map a supplied virtual path to a physical path on the server, use the overload of Request.MapPath that accepts a bool parameter so that you can prevent cross-application mapping.

Application Error Disclosure

Medium (Medium)

Description

If a page contains an error/warning message that may disclose sensitive information, this can be used to launch further attacks against the web application.

  • URL: http://localhost:8082/api/TokenAuth/Authenticate

    • Method: POST
    • Evidence: HTTP/1.1 500 Internal Server Error

    This is false-positive alert. As seen in the below screenshot, Asp.Net Zero returns a HTPP 500 Internal Server Error without any sensitive information. Actually it's not an exception result. While the error detail is not being sent to the client, it is logged on the server.

    Application Error Disclosure

Asp.Net Zero never returns error details, if only developer sends it deliberatively. When the project runs on development, exceptions are being sent to client. But publishing application in release mode prevents exception details to be sent. Web.Host project sends a JSON with including the message: "An internal error occurred during your request!"

The following alerts are same as the above alert. No sensitive data is being exposed.

The response of "File/DownloadTempFile" resulted with Http-500, because there's no file to download. The action result returns empty data (Content-Length: 0) and does not disclose any information about the problem.

Recommendation

If your website must return error then review the source code of the action and implement custom error pages or 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.

X-Frame-Options Header Not Set

Medium (Medium)

Description

The X-Frame-Options HTPP header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

ASP.NET Zero uses ASP.NET Boilerplate framework. After version 3.4.X, the framework adds X-Frame-Options header to all responses with the value SAMEORIGIN. If you want to remove the header you can do it via UseAbp() options in Configure method of Startup class.

public class Startup
{
	public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
	{
		app.UseAbp(options =>
		{
			options.AddSecurityHeaders = false;
		});
	}
}

Recommendation

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

X-Content-Type-Options Header Missing

Low (Medium)

Description

The X-Content-Type-Options HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing. Some of the requests which are alerted to have the X-Content-Type-Options header;

Comment

ASP.NET Boilerplate framework v3.4.X adds the X-Content-Type-Options header to all responses with the value nosniff. If you want to remove the header you can do it via UseAbp() options in Configure method of Startup class.

Recommendation

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.

Web Browser XSS Protection Not Enabled

Low (Medium)

Description

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.

Comment

Asp.Net Boilerplate framework v3.4.X adds the X-XSS-Protection header to all responses with the value 1; mode=block. If you want to remove the header you can do it via UseAbp() options in Configure method of Startup class.

Recommendation

Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.

Cross Site Scripting Weakness (Reflected in JSON Response)

Low (Low)

Description

A XSS attack was reflected in a JSON response, this might leave content consumers vulnerable to attack if they don't appropriately handle the data (response).

Comment

There are about 180 instances of this alert. AspNet Zero doesn't return any HTML response in Web.Host project. Thus all of the instances are raised with LOW confidence as the Content-Type is not HTML. In reflected XSS the it's important where this result is being evaluated. The responses are being evaluated by Angular. Angular has built-in protections against common web-application vulnerabilities including XSS attacks. We have used the tree library JsTree which was open to XSS. It is fixed by this commit.

Recommendation

To block XSS attacks, you must prevent malicious code from entering the DOM. When a value is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, you need to sanitize and escape untrusted values.

Reference

For all the other OWASP standardizations, download the OWASP sheet.

Open Web Application Security Project (OWASP) - Application Security Verification Standard 3.0 PDF sheet

Contributors


Last updated: March 20, 2019 Edit this page on GitHub
In this document