After developing multiple web applications, I have noticed that the general question before deployment is whether the application is secure enough to be exposed to the World Wide Web. Even though during development your team has taken authorization and authentication into account, you might still wonder if you have overlooked any obvious vulnerabilities in the application.

Introduction

Everyone in the field of application security can tell you that you can never guarantee that your application is fully secure. To assess where the vulnerabilities reside in your application, it is a good idea to request a security scan, which can be done by an external auditor. A security scan involves both manual and automatic black box vulnerability detection. The automatic part executes scripts flagging well-documented and common exploits. The manual part is a more in-depth analysis done by a security engineer. A security scan results in a list of vulnerabilities detected in the system each with a severity indication, a reproduction scenario (when applicable) and advice on how to resolve the exploit.

Every web application I worked on had pretty much the same vulnerabilities on the first security scan. Since a security scan iteration is costly and time intensive, I made a checklist for myself with these returning vulnerabilities, which you may not be particularly aware of when you are focused on developing a web application. This list proved useful in reducing the number of security scan iterations or when the project does not have the luxury to execute security scans at all. This is the reason I decided to summarize the list in this blog, so more people can make use of it. Please note that it is by far not a complete list since every application requires individual attention to get a good idea what vulnerabilities it might have.

Password management policy

Whether you develop your user management yourself or make use of external system, it is a good idea to verify that the password policy of your system is sufficient for your applications needs. A good password policy consists of:

  • Solid password strength: think of number of characters, the use of letters, numbers, etc.
  • Sufficient password expiration time: the duration of time before the password expires and a new password needs to be chosen;
  • Limit password repetition: to prevent users from using the same password within a specific time span, you should remember a certain number of previous passwords;
  • Make sure that the password is never sent over email. For onboarding users and for password reset functions, consider using temporary URLs for (re)setting passwords;
  • Make sure the password is not saved in plain text;
  • Use sufficient salting and hashing to encrypt passwords(1).

Authorization cookie policy

Cookies are the most likely candidate for authorization tokens in a web application. Although most development frameworks come with many features out of the box, it is wise to check whether the cookie mechanism is safe enough.

First, you might want to specify the expiration time of a cookie. This is often decided based on the balance between how long or often the user makes use of the application versus how sensitive the information being stored is. Is it acceptable for an administrative application to have a cookie with an expiration time of 8 hours? What if it the program has medical data and is only used in sessions of 2 hours?

Cookies also have properties that need some attention (2). You should check whether the secure property is set in the cookie. This means that the cookie can only be sent over HTTPS connections. If you use your cookies for authentication to the backend only and your frontend does not need to know anything about the contents, turn httponly on. When this setting is on, cookies cannot be used in JavaScript, blocking analysis of the cookie by a malicious script.

Figure 1: Cookies from Gmail shown in Chrome

Information exposure

 To mitigate the chance of a malicious user analyzing your system, you should make sure that no superfluous information is exposed. An obvious example is when your service calls do not have proper error handling, resulting in a status code 500 and a stack trace or other debug information in the response body. This gives a malicious user insight into the structure of your application and is completely avoidable.

Sometimes information is exposed without you noticing. Some frameworks or web servers do this by adding headers to your HTTP calls. Examples of this would be headers with .NET versions or the IIS version. You want to prevent this from happening because certain versions of frameworks and web servers can have known vulnerabilities (3).

Figure 2: www.msn.com is apparently built in ASP.NET 5.2 and hosted in IIS 8.5

HTTP verb management

When designing HTTP calls, you will have certain HTTP verbs in mind. Especially when you create REST services, each HTTP verb has a specific function. There are also less known HTTP verbs that can have consequences for the security of your application when they are not turned off. Your design principle should be to accept only the verbs that you intended for your design (4).

Two verbs in particular should be avoided all together, namely TRACE and OPTIONS. The TRACE verb returns the HTTP request as received by the server. It is intended to be a debug call, but it can be exploited via Cross Site Tracing (5).

The OPTIONS verb echoes all the verbs that are possible on the endpoint. This exposes too much functionality of the system to people who are analyzing your system for vulnerabilities.

Prevent Cross Site Scripting (XSS)

Cross Site Scripting is a broad array of attacks that inject malicious scripts into a web application (6). This includes JavaScript and SQL injections. The best prevention method is to distrust user input in any form in your application, meaning that you need to check whether the input contains scripting and, if so, to block it. Checking for JavaScript or SQL injections in UI components or service calls should be part of your design.

Prevent Clickjacking

Clickjacking (7) is an attack where a user is tricked into clicking on a button or link by adding layers over the web application. The most common way to achieve this is by hosting the targeted web site in a frame that covers the entire screen. The owner of this site can put overlays over the frame, so that buttons and links are obscured by custom UI components. To prevent your site from being hosted in a frame, you can add the X-FRAME-OPTIONS header with the value DENY. If you do want your site to be hosted in frames by parties you trust, you can also use the values SAME-ORIGIN or ALLOW-FROM.

Prevent Cross Site Request Forgery (CSRF)

A CSRF (8) is an attack that uses the browser to send a request to the site using your credentials. This attack is possible when you are still logged on to a web application and thus the authentication cookie persists. This means that every request done via the browser will send the cookies of the site along with the requests to that site, whether the request was intentional or not. Unintentional requests could be triggered via XSS or sent via deceptive e-mails.

To prevent CSRF, you have to make sure that potential critical calls (often the state changing calls like POST, PUT and DELETE) can only be done from the sources you intend them to come from. If you have a form in your web application that on submitting sends a request, you want the server to only process this call if it comes from this form. There multiple ways to achieve this, but all solutions come down to that the client and the server share a secret with which the source and destination can be identified.

HTTPS

HTTPS certificates provide authentication of the visited website and protection of the privacy and integrity of the exchanged data. However, how do you know if your certificate is secure enough? SSL Labs comes with a great online tool, where you can check the certificate and server settings by submitting your URL (https://www.ssllabs.com/ssltest/). Your certificate will get a grade, and the tool shows you all known vulnerabilities of your settings. Getting a better grade often means that you have to turn off ciphers and protocol on the server. Always try to get at least an ’A’.

Conclusion

The list contains a lot of straight forward vulnerabilities that are relatively easy to solve. Checking all items off the list is by no means a guarantee that your web application is secure, but it is a good start and makes you aware of the vulnerabilities that the application can have.

For further reading, I will refer you to the Open Web Application Security Project (OWASP). This site contains many resources on security threats, mitigations and methods of testing for vulnerabilities. It also keeps track of the so-called OWASP top 10 (9), which is a list of the top 10 most critical web security problems. It is advisable to take this list into account for your own web application.

I hope this security check list is useful for you. I like to use it as a reference document for checking my own work and creating awareness for the potential vulnerabilities your web application may have.

References

  1. https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet.
  2. https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002).
  3. https://www.owasp.org/index.php/Testing_for_Web_Application_Fingerprint_(OWASP-IG-004).
  4. https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006).
  5. https://www.owasp.org/index.php/Cross_Site_Tracing.
  6. https://www.owasp.org/index.php/Cross-site_Scripting_(XSS).
  7. https://www.owasp.org/index.php/Clickjacking.
  8. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
  9. https://www.owasp.org/index.php/Top_10_2013-Top_10.

Ludo Verstraeten, Senior Consultant Engineer