Security Evaluation
Our team used the security tool Zed Attack Proxy (ZAP) from Open Web Application Security Project (OWASP) to evaluate the security aspects of our application. It is run as a proxy between our browser and server, by attacking our web application to find common security vulnerabilities.
We have performed an active scanning with ZAP on our application, in an attempt to find any vulnerabilities which arise from using known attacks. The results are as follows:
View link: https://drive.google.com/open?id=0B_XZfqDthY7eLXlNMFNoOGp3Ym8
There are 3 medium priority alerts and 4 low priority alerts as shown above. The results are also summarised below:
| Message | Description | Suggested Solution |
|---|---|---|
| Application Error Disclosure (Medium priority) | 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. | 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. |
| Format String Error (Medium priority) | A Format String error occurs when the submitted data of an input string is evaluated as a command by the application. The script closed the connection on a /%s | Rewrite the background program using proper deletion of bad character strings. This will require a recompile of the background executable. |
| X-Frame-Options Header Not Set (Medium priority) | X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks. | Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site |
| Cookie No HttpOnly Flag (Low priority) | 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. | Ensure that the HttpOnly flag is set for all cookies. |
| Password Autocomplete in Browser (Low priority) | The AUTOCOMPLETE attribute is not disabled on an HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved. | Turn off the AUTOCOMPLETE attribute in forms or individual input elements containing password inputs by using AUTOCOMPLETE='OFF'. |
| Web Browser XSS Protection Not Enabled (Low priority) | 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. The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism. | Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'. |
| X-Content-Type-Options Header Missing (Low priority) | 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. | 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. |
We then further scanned the application with spider scan (using ZAP) and subsequently with AJAX spider scan. Both the scans do not further reveal any additional vulnerabilities.
We discovered that the “Application Error Disclosure” warning from above arises as our web application is currently running in debug mode. To resolve this, we have to disable the debug mode when we are deploying our application.
For the “Format String Error” warning, we realised that input validation is only done at frontend side and it is absent in the backend side, therefore, we have added input validation to our backend code as well to resolve this.
We resolved the "Password Autocomplete" issue by setting the autocomplete attribute in the password input fields to off.
We also resolved the "Cookie No HttpOnly Flag" issue by setting the httponly argument in the setcookie() function call to True.
Lastly, we resolved all header-related security issues by adding explicit function calls to set the required header options in the GET and POST methods of all the page handler classes.
After all the improvements we have made above, we have performed another active scanning with ZAP on our application. The results are as follows:
View link: https://drive.google.com/open?id=0B_XZfqDthY7eRnFTT3NNSzVQaEE
As seen from the results above, we have resolved 3 medium priority warnings - Application Error Disclosure, Format String Error and X-Frame-Options Header Not Set and 2 low priority warnings - Cookie No HttpOnly Flag and Password Autocomplete. However, this scan has revealed 2 additional warnings which are Path Traversal and Multiple X-Frame-Options Header Entries.
It is also worth to note that the 2 low priority issues Web Browser XSS Protection Not Enabled and X-Content-Type-Options Header Missing are resolved in all of our web pages, and those that are picked up by ZAP are either non-existent urls tested by ZAP or are our static directory files which are not web pages that we can set the X-Content-Type-Options Header.
The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate a URL in such a way that the web site will execute or reveal the contents of arbitrary files anywhere on the web server.
The suggested solution is to use a whitelist instead of blacklist for input validation, which is already currently employed by our team for the application. Another solution is to run our code using the lowest privileges that are required to accomplish the necessary tasks. We have realised that it is impossible to fix this problem on web.py, a framework used for this application. In order to fix this problem, we would require hosting the application on an apache server and then altering the .htaccess file. However, we are not using an apache server at the moment. We have alleviated this issue by not storing any sensitive configuration files inside the web root, i.e., an attacker is unable to read or edit any sensitive or crucial information. We believe this minimizes the risk this problem creates at the moment, and thus is not a high priority issue.
As for the Multiple X-Frame-Options Header Entries warning, it is reported by ZAP that multiple X-Frame-Options headers were found and this kind of response might not be predictably treated by all user-agents. However, we have only set X-Frame-Options to SAMEORIGIN multiple times and there is no other X-Frame-Options set, so it is believed to be a false positive case.
It is also worth to note that running a spider scan and AJAX spider scan subsequently did not reveal any additional vulnerabilities.
Note: Our AJAX Spider Scan is run on Google Chrome and Mozilla Firefox web browsers, as our Non-Functional Requirement #2 requires our program to be run on either Google Chrome or Mozilla Firefox.