The Open Web Application Security Project (OWASP) has been releasing its Top 10 list of common risks since 2003. The OWASP Top 10 2017 is the latest release in a long line of Top 10 lists.
This is part two in a two-part post. If you haven’t already, check out Part One first!
OWASP Top 10 2017 – 6: Security Misconfiguration
Security misconfiguration has been on the list for a while. It can be a tough nut to crack depending on how complex your application is.
How it works
Security misconfiguration comes in two flavors: configuration that opens a vulnerability, and configuration that doesn’t make full use of what’s available.
Configuration is a broad topic. So it’s tough to cover all possible scenarios here. However, there are certain patterns you can look for in your application.
Not patching your systems is a part of configuration and can leave your system open to attack. XXE is a good example. If you update your XML parsers, then you should be good. If not, you’re vulnerable.
The publicly available S3 buckets that disclose sensitive information are open due to misconfiguration.
On the other hand, sometimes there are ways of making your application more secure, but you may not use it or even be aware of it. This is where intimate knowledge of your chosen languages and frameworks is important.
I’ll give you a head start with some good options for good configuration.
How you can help
First, a simple list of what you can do to help fight misconfiguration:
- Don’t install anything you don’t need
- Use automation, such as Puppet and Chef, to create environments with known good configuration
- Use solid network segmentation so an attacker doesn’t have free reign if they do get in
- To the extent possible, automate tests that make sure your configuration is sound.
- Patch your software and dependencies
- Use the security features available to you
- Read the relevant documentation for your framework
- Heed any configuration notes and hints in autogenerated code (hint: check the comments)
Let’s cover some security features that will help to make your configuration rock solid.
First, serve your web applications over HTTPS. It doesn’t matter what content you have, serve it over HTTPS.
If a user requests it over HTTP, redirect the request to HTTPS. Every user deserves the privacy and integrity that HTTPS gives by default.
You can also use browser security headers.
Browser security headers give the client clear instructions on how to interact with your site. When used properly, security headers can protect against many risks.
HTTP Strict Transport Security (HSTS) tells the browser to only use HTTPS when connecting to your site. This is a great way to keep sensitive data safe. Be careful when using HSTS, however, because you could brick your site if it’s done incorrectly.
The X-FRAME-OPTIONS header prevents other sites from embedding yours using a frame. It’s an effective way to prevent clickjacking attacks.
Another key security header is Content Security Policy, or CSP. It’s great because you can tell the browser exactly where it is allowed to load your content from. CSP is another great way to prevent clickjacking and other attacks.
If you’re using Node.js, check out Helmet. It provides an easy way to include security headers into your application.
Security misconfiguration is a tough problem but not impossible to solve. Double your efforts and get this one off of the list.
OWASP Top 10 2017 – 7: Cross-Site Scripting (XSS)
XSS is another risk that has been around from the beginning. There is good news on this front. In 2013, XSS was number three on this list. Now, it has dropped to number seven. But more can be done to wipe XSS off of the Top 10.
How it works
XSS occurs when user-controlled data is treated as code by the browser. It comes in three flavors.
Reflected XSS is when unvalidated user input is included in the output of the page. If your page adds user-entered data to the DOM of the page in any way, you have a risk of reflected XSS.
Stored XSS occurs when user input is stored in a database and then rendered to the page in the future. For example, an attacker adds an XSS attack to a forum as a comment. When another person visits the page, the attacker’s code runs in the victim’s browser, perhaps sending the victim’s session to the attacker’s server without their knowledge.
DOM XSS is a newer version of XSS that occurs when user-controlled data is send to unsafe JavaScript APIs that dynamically update your page. Think templates used in frameworks like Angular and React JS. These can be used for attack.
How you can help
XSS is prevented by encoding content when it goes to the browser. This will force the browser to render any nasty code as text instead of executing it as code.
Many frameworks encode by default, including React JS and Angular. There are some limits as well as functions that are unsafe to place unvalidated data into. Check out the docs for information on what the limits are in XSS protection for these frameworks.
Understand where your data will go and how it travels through your application. Be on the lookout for data that goes into a database and then is used to render content to a page. That data needs validation and encoding that is appropriate to the context in which it’s used.
Using a Content Security Policy can also be a great way to control XSS because you’ll define where scripts and other resources can come from.
OWASP Top 10 2017 – 8: Insecure Deserialization
Serialization is the process used to transform code objects into a form that is easier to send over the network. The problem occurs when it reaches its destination and is turned back into an object.
How it works
Deserialization is a major issue that can lead to elevation of privilege attacks and remote code execution.
When the client serializes application data and sends it to the server, an attacker can see it. If that attacker notices the format of how you serialize objects, then you are in trouble.
Serialized data needs to tell the server what class it is. If the deserializer simply trusts this value, the attacker can force the application to build an object from any class and even execute methods on the object after its been reconstructed.
JSON can be used in these attacks as well. Check out this video for a cool attack that uses JSON deserialization against a .NET app to arbitrarily run code on a server.
How you can help
Insecure deserialization is another vulnerability that can be gone by the time the next Top 10 list comes out. Here are some concrete steps you can take to prevent it.
- Whitelist the classes that your application is allowed to deserialize
- If any classes come across that aren’t allowed, log it
- Use digital signatures on your serialized objects to prevent tampering and fake requests
- Make sure deserialization libraries you use are up-to-date
- For Python users: Don’t use Pickle
Interestingly, Oracle plans on ditching serialization in Java so maybe that will eliminate this vulnerability from the list (though it will still exist in other languages). Until then, the above steps will help you to keep your apps safely and hopefully kick this risk off the list for good.
OWASP Top 10 2017 – 9: Using Components With Known Vulnerabilities
I just need to say one word to introduce this risk: Equifax.
How it works
Our software is piled on top of frameworks and open source libraries in growing numbers. Unfortunately, this also adds to the risk to your application.
Your application is running on a bunch of code that you can’t control. If there is vulnerability in the software that you depend on, you’ll be vulnerable by attack through that software.
The Equifax breach started with a vulnerability in the Struts framework that they used. After that, the attackers got into the network and found the crown jewels. Don’t let that happen to you.
How you can help
You can’t really stop using other people’s code. The cost is too prohibitive. The best you can do is to only use what you need. Keep track of all of your dependencies. Create a solid patch management strategy so that the dependencies are up-to-date.
Use tools like Software Composition Analysis (SCA), which detects vulnerabilities not only in direct dependencies but also their dependencies - multiple levels deep.
OWASP Top 10 2017 – 10: Insufficient Logging and Monitoring
Finally, we have insufficient logging and monitoring. This is a newcomer to the list with a different flavor than the other risks.
How it works
When your logging and monitoring isn’t good enough, you won’t know when someone is attacking you. Unfortunately, the average amount of time it takes a company to know it is breached is 197 days.This is most likely because logs aren’t logging the right thing and the right people are not seeing the alarms that are being raised. This is not a good place to be.
How you can help
Make sure your logs are useful and someone is seeing what is happening. Here are some guidelines.
- Log all security-relevant information such as failed logins and access control failures.
- Send your logs to a centralized place so that they can be analyzed for anomalous activity.
- Use audit trails for high-value and high-risk functions within your application
Make sure you know when bad stuff is happening in your application. However, keep in mind that you shouldn’t use more tools than are necessary. You don’t want to greatly increase your attack surface unnecessarily.
Change the next list
Developers can influence the next OWASP Top 10 list. Learn these risks. Learn how to prevent them. Work to change the list that comes out in 2020.
If we change the list, that means there’s been positive changes. If we change the list, there’s been progress. So let’s change the next list.
Change it for your application. Change it for your company. Change it for your customers.
Reach out if you’re not sure how. We’ll be glad to help.
