How Can Application Developers Build Secure and Reliable Code? OWASP Top 10 Proactive Controls - Part 2Tuesday, May 1, 2018
What application developers should know about secure coding and proactive security? Improve the security of your applications from the start with these 10 controls!
In the first part of this series we talked about the first five controls from the OWASP Top 10 Proactive Controls Project and how they can help developers to write secure code without having an in-depth knowledge of all the security vulnerabilities that each control protects them from.
Today we are going to discuss about the last five controls and understand how they can be applied to protect your applications from frequent attacks. If you haven’t read the first part part of this article, now is the time to go back and read it so that you can have a better understanding of what we are talking about. Here we are going discuss only about these last five controls:
- C6 - Implement Appropriate Access Controls
- C7 - Protect Data
- C8 - Implement Logging and Intrusion Detection
- C9 - Leverage Security Frameworks and Libraries
- C10 - Error and Exception Handling
C6 - Implement Appropriate Access Controls
Although this control seems to be similar from our last one C5 - Implement Identity and Authentication Controls, it’s not the same thing. Remember the difference between authentication and authorization, right? While authentication is process of proving that the user is who he says he really is, authorization is the process of verifying if the user, even though he is authenticated, is authorized to access that file or function on the system.
Ok, now when we cleared that out, make sure you use positive access controls on your applications. That means that user or role has to be explicitly authorized to access that functionality, otherwise he is denied. Very similar to the concepts of whitelisting, ok?
Here are few other principles that can be used to properly create access controls on your software:
- Make sure that all requests are verified for access controls - although that is easier said than done, using a centralized mechanism will help you enforce that and make sure that all requests are filtered and checked before executed.
- Deny by default - another application of the positive access control principle, it means that when a new feature is created, all access to that feature is denied, unless explicitly authorized.
- Least Privilege Principle - one of the most well-known principles in Information Security, and sometimes one of the most forgotten. This principle states that any user or application should only have the minimum required principles to execute their tasks, anything more than that can be dangerous and unnecessary.
C7 - Protect Data
This control sounds very simple right? But it’s actually not. Protecting data means not only encrypting data in transit, but at rest as well. For protecting data in transit we are already very familiar with SSL/TLS protocols. It is the most used protocol to protect web applications nowadays. In fact, despite the attacks of Heartbleed and POODLE, using the latest version of TLS (currently 1.2) is still the best option to secure your data and communications in transit.
Protecting data at rest is even trickier because it is very hard to manage all the keys and passwords, what is going to be encrypted and when to encrypt it. So, make sure you plan that ahead before building a new application and use well-known frameworks and libraries such as Google KeyCzar project or Bouncy Castle instead of trying to create your own crypto functions.
C8 - Implement Logging and Intrusion Detection
A lot of SMBs still disregard the power of logs and event correlation, only using it for troubleshooting. This control should attract more attention after the release of the new OWASP Top 10 2017, which included Insufficient Logging & Monitoring as one of the Top 10 risks of web applications.
Logging shouldn’t be done just for negative actions such as incorrect password at login. Properly logging positive and negative actions on your systems allows you to correlate those logs and create patterns that can be used to detect if an attack is being executed or it is just a system malfunction. A lot of security tools are using log correlation and machine learning to determine the behavior of a user or a system and alert them they start behaving differently. For example, if your sysadmin never logs in on his account on a Sunday, the tool detects that anomalous behavior and can either block or just alert.
C9 - Leverage Security Frameworks and Libraries
We’ve already talked a bit about this on the article about DevSecOps when I mention that nowadays it is very rare for a developer to write code from scratch. They use a lot of frameworks and libraries so that they can focus on the business part of their applications. Then why not have them use well-known and well-tested security frameworks that they can just import and use it, instead of creating those mechanisms from scratch? Well, that’s what this control talks about!
There are many web application security frameworks that can be used on your application to protect it faster and efficiently such as Spring Security, Apache Shiro, Django Security, Flask Security and also OWASP ESAPI. Also make sure that you keep all those frameworks and libraries up to date and have protections in the event of vulnerabilities being detected.
C10 - Error and Exception Handling
The last of the Proactive Controls is the one that deals with one most common problems on web applications: sensitive information exposure due to errors. Have you ever saw a stack trace of a web application when an error occurred while using it? Well, that’s one of the problems that this control tries to prevent.
There are two problems when you don’t apply the correct error and exception handling controls:
- Leak of sensitive information - like the stack trace that I mentioned before.
- Errors happening undetected - affecting the integrity of your application and your data without you even knowing.
To fix that you should perform the correct exception handling of problems that might happen on your application and also go through the appropriate testing to make sure nothing critical missed.
Well, that was it for our Part 2 of the OWASP Proactive Controls. I hope you enjoyed these two articles and if you have any questions or comments, send them in our comment section below. If you need a more detailed list of requirements and controls to guide your developers please check the OWASP ASVS Project. Don’t forget to check out our free Application Discovery service and stay tuned for our next posts.