So let’s jump right into it.
Sensitive Data Exposure
This vulnerability describes not properly storing sensitive data or allowing it to be intercepted or retrieved by an attacker.
As shown by the ratings for this vulnerability, it can be more difficult to detect and exploit, but the payoff for the attacker could be big enough to be worth the trouble.
This vulnerability is all about data. You should understand what data you need to store and which data is sensitive and needs to be protected. Think about health records, credit card data, and passwords.
Attackers are usually after data of some sort. Whether it’s data that will allow them to take over a system, such as privileged credentials, or PII data that can be sold or used for identity theft, data is extremely important to the attacker.
You can expect attackers to try to gain access to data stored in files and databases that may be exposed to the internet. SQL injection can be used to pull data out of a database through a web form.
Sometimes data can be left wide open out on the internet. Recently, hackers found MongoDB instances that were left wide open on the Internet with blank admin passwords. They took them over, encrypted the data and held it for ransom.
The bottom line is, your data is at the top of the list for hackers to grab. The more sensitive the data, the better. How do you protect it?
Protect your data. Begin by understanding what data you have. Then you can figure out what needs to be protected and how.
From a practical standpoint, here is what you can do for sensitive data.
First, don’t store it if it is not absolutely necessary. If it isn’t stored, it can’t be stolen. Some regulations require this, such as the PCI-DSS that prohibits certain data points from being stored.
My post on PCI-DSS describes this in more detail.
Second, if you need to store sensitive data, make sure it is encrypted with a strong encryption algorithm. Make sure to follow sound practices for key generation and management.
Third, passwords must be stored using algorithms specifically created for this purpose, such as PBKDF2 or bcrypt. I have more details on how to properly store passwords here.
Fourth, make sure encryption is happening both at rest and in transit. Sensitive data should always be transmitted over TLS.
Fifth, disable the autocomplete function on forms where sensitive data is entered and disable the browser cache for pages that contain sensitive data.
Insufficient Attack Protection
This one is new to the 2017 list and is quite interesting in my opinion. Here are the ratings:
When thinking about security, most developers think about how to prevent attacks from being successful. This is important, but OWASP points out here the importance of detecting attacks and protecting the application from them.
Attack protection within the application requires that the application itself can detect that an attack is in progress and work to stop it in real time.
This attack could be any attack that could be launched against a web application or API. The idea of this vulnerability is not the specific attack, but rather if the application is aware that an attack is happening.
Many applications and APIs on the web will allow a hacker to keep pounding on them indefinitely until something breaks and the attacker gets in.
This is dangerous because there are many automated tools available that will allow an attacker to pound the website with many attacks trying to find one that works. Attackers shouldn’t be allowed to indefinitely attack your site.
Also, if you wait too long to patch vulnerabilities that are found, this will expose you exploits. There should be a process and tools in place to fix critical vulnerabilities quickly.
The key to overcoming this vulnerability is to put tools into place to detect and shut down attacks that are in progress against your site. There are several options to accomplish this.
While fixing the actual code is always the desired outcome, virtual patching can help to prevent exploits from occurring.
Virtual patching is a technology used by Intrusion Prevention Systems (IPS) and web application firewalls (WAF) to prevent exploits in real time. You provide the signature of the vulnerability to these tools and if they see an attack in progress they can shut it down.
If your infrastructure does not allow for an immediate patch to production when a critical vulnerability if found, then virtual patches will certainly help you to protect your application if an attack occurs.
One of the most effective ways to detect and stop attacks is to give your application the ability to detect attacks in progress and stop them itself.
OWASP actually has a project call AppSensor that can help your application do just that.
OWASP AppSensor provides a framework that provides guidance on how to incorporate intrusion detection and automated response directly inside your application. Instead of a separate appliance responding to attacks, your application can.
AppSensor works by logging events at points in your code where security events are important, such as a login screen or POST to a form. This helps to detect suspicious behavior as it is happening.
Detect attacks using log files as well as behavior (i.e. more than three failed login attempts in five minutes). Possible actions range from raising alerts to completely shutting down misbehaving accounts. What you do depends on the application and requirements.
In the end, what is important is that you have a way to prevent exploits from happening and quickly patch critical vulnerabilities when they are discovered.
Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) is another perennial on the list and is back at number eight.
CSRF attacks are well-known and documented, so we won’t go into great detail here. The details of it could be a blog post on its own.
CSRF is an attack that forges a request to your site such that it appears to come from a legitimate and authorized user. It takes advantage of the fact that cookies are sent automatically by the browser when a request is made.
An example of an attack is when an attacker tricks a user into navigating to a malicious website. That site has the vulnerable site inside of an iframe so that when the user clicks a button a form is submitted that tries to cause the target website to perform an operation using the victim’s session cookie to “forge” the request.
If the user is logged in, the cookie is sent and the action is taken. For instance, the attacker may try to transfer money into a bank account under their control by attacking a vulnerable banking website.
A very nice explanation of CSRF attacks can be found here.
There are several ways to mitigate the threat of CSRF attacks. It is best to apply multiple to your website for a strong defense-in-depth strategy.
- Check the origin header – Two headers that are sent with a request are the origin and referrer headers. An option is to check these headers and make sure that they match a whitelist of allowed domains that can send requests to your site.
- CSRF tokens – CSRF tokens are a very common mitigation that is included in many web frameworks at this point. Two unique tokens are sent back via a cookie and a hidden form field. The attacker is unable to get this unique token. When a request is sent, the server checks to see if the token from the form field (in the body) matches the token value in the cookie. If they match, the operation is allowed.
- Samesite=strict cookie setting – The Samesite=strict cookie setting is a surefire CSRF beater that is built and implemented in the browser instead of by the application’s development team. It ensures that requests can only be made via the same domain, completely shutting down any cross-site activity. Not all browsers support it yet, but Chrome does and that is already 50% of market share. It is certainly worth it to implement the Samesite setting.
- Content Security Policy – A CSP is a great tool against client-side exploits like XSS. It can also be used to protect against CSRF attacks. A Content Security Policy tells the browser what content is allowed to load and from where it can load. The “frame-ancestors” directive being set to ‘none’ in a CSP means that no site can embed yours in an iframe. This will prevent the first attack described above.
Sites should use many of these mitigations to form a solid defense against CSRF. Most use options one and two together but expect to see more uses of options 3 and 4 as browser support improves and word gets out about the effectiveness of these headers.
Using Components with Known Vulnerabilities
Many organizations might not fully consider the possible risks of using open-source or third-party components in their software. That is what the ninth vulnerability on the list explains.
Notice that the prevalence is common. This is not surprising, since most if not all websites have some dependency on code not written by the developers of the site.
These components could have vulnerabilities that leave your site open to exploitation.
New vulnerabilities are found in components that are used by website all of the time. You can be sure that attackers are paying attention to vulnerabilities so that they can test your site to see if it is vulnerable.
You should beat them to the punch or it could cause problems for your site. When the Heartbleed vulnerability was discovered in OpenSSL, it effected a huge number of sites due to its widespread use. This is an extreme example, but lesser known vulnerabilities could crop up in any of your libraries and leave you exposed.
It is important to understand which components you use and what vulnerabilities they may have.
Watch lists such as the CVE for your components. Pay attention to news about your components that may include new vulnerabilities.
There are also tools that can help you understand your risks and exposure based on the components you use. For example, OWASP Dependency Checker (for Java and .NET) will help you keep track of your dependencies and any vulnerabilities that they may have.
If you find that a component has a vulnerability, manage the vulnerability like you would a vulnerability found in code that you have written.
You can add a virtual patch to detect an attack and stop it before it can exploit the vulnerability. Also, update the components when they fix the vulnerabilities.
Rounding out the Top 10 list is Underprotected APIs. Another new addition to the list that makes sense and is worth considering.
The attack in this instance could really be any of the attacks that we have discussed already. It is important to understand that APIs exposed over the Internet can be just as vulnerable to attack as a traditional web application.
This is important because so many applications are being built in a modular way using microservices that are called by clients such as phone apps and single page applications.
APIs should be thoroughly tested and examined for vulnerabilities using penetration testing tools. Vulnerabilities should be managed and fixed in the same way as in a web application.
My post on security concepts developers should understand has a section on complete mediation. Complete mediation is the concept that all code should go through an authorization module that cannot be bypassed.
This is important for APIs that are called from clients to ensure that you are not simply trying to obtain security through obscurity.
The bottom line here is to remember that even if there is no page with a form, an API can still be attacked with injection, XSS, or CSRF attacks just like any site.
Test your APIs thoroughly for the other vulnerabilities on this list and make sure that your are not underprotecting your APIs.
Protect Your Web Apps!
The OWASP Top 10 2017 is a must read for all web developers. It is your responsibility to make sure that your applications are safe from these and other common vulnerabilities in software.
Let’s all try to make the future of the web more secure for all of our users, putting their safety at the top of our list.