Developing secure software: how to implement the OWASP top 10 Proactive Controls
2020年11月5日
0 分で読めますRecently, I was thinking back at a great opening session of DevSecCon community we had last year, featuring no other than Jim Manico.
In this session, Jim walked us through the list of OWASP Top 10 proactive controls and how to incorporate them into our web applications. The proactive controls document, written by Manico himself, along with Katy Anton and Jim Bird, provides a security overview for developers wanting to jump into web security, understand the different layers of security risks, and how to protect against them.
If you find this interesting, then keep reading as we dive into the OWASP top 10 Proactive Controls, one by one!
OWASP top 10 Proactive Controls 2020
Define Security Requirements
Leverage Security Frameworks and Libraries
Secure Database Access
Encode and Escape Data
Validate All Inputs
Implement Digital Identity
Enforce Access Controls
Protect Data Everywhere
Implement Security Logging and Monitoring
Handle All Errors and Exceptions
OWASP Proactive Control 1 — define security requirements
Building a secure product begins with defining what are the security requirements we need to take into account. Just as business requirements help us shape the product, security requirements help us take into account security from the get-go.
A prominent OWASP project named Application Security Verification Standard—often referred to as OWASP ASVS for short—provides over two-hundred different requirements for building secure web application software.
It lists security requirements such as authentication protocols, session management, and cryptographic security standards. Most importantly, the ASVS provides a phased approach to gradually implement security requirements as you are making your first steps.
Source: GitHub
OWASP Proactive Control 2 — leverage security frameworks and libraries
What tools do you need to help you build secure software?
The list goes on from injection attacks protection to authentication, secure cryptographic APIs, storing sensitive data, and so on. To address these concerns, use purposely-designed security libraries.
Make sure you track the use of open source libraries and maintain an inventory of versions, their licenses and vulnerabilities such as OWASP's top 10 vulnerabilities using tools like OWASP’s Dependency Check or Snyk.
OWASP Proactive Control 3 — securing database access
Databases are often key components for building rich web applications as the need for state and persistency arises.
Database security expands to numerous areas including
protection from SQL injections with techniques such as parameter binding. It is also of great importance to monitor for vulnerabilities in ORM and SQL libraries that you make use of as we’ve seen with the recent incident of Sequelize ORM npm library found vulnerable to SQL Injection attacks.
secure and strong database authentication and overall configuration.
secure communication between the database and its client.
Interested in reading more about SQL injection attacks and why it is a security risk? Jim gave some tips on bobby-tables.com.
OWASP Proactive Control 4 — encode and escape data
Always treat data as untrusted, since it can originate from different sources which you may not always have insights into.
Cross-site Scripting (XSS) vulnerabilities are an excellent example of how data may flow through the system and end up employing malicious code in a browser context, such as JavaScript, that get evaluated and compromises the browser.
Other examples that require escaping data are operating system (OS) command injection, where a component may execute system commands that originate from user input, and hence carry the risk of malicious commands being executed.
I am pulling data from the database. Should I escape it? The secure developer definitely does. It is impractical to track and tag whether a string in a database was tainted or not. Instead, you build proper controls in the presentation layer, such as the browser, to escape any data provided to it.
An extreme exception to that rule is when you have decided to build a web page DOM element, or more, from the database input, in which case, you are sailing dangerous waters and should think carefully on your model and what controls help you to mitigate dangers that come along with it.
Here are some libraries to help you with data sanitization:
DOMPurify for JavaScript
Important to note that the OWASP ESAPI project is behind on active maintenance and you’d better seek out other solutions.
Finally, we wrote about command injection: how it works, what are the risks and how to prevent it which I highly recommend as a follow-up read.
OWASP Proactive Control 5 — validate all inputs
Just as you’d often leverage the typing system, like TypeScript, to ensure expected and valid variables are passed around your code, you should also be validating the input you received matches your expectations or models of that data.
General guidelines:
Do not rely on validation as a countermeasure for data escaping, as they are not exchangeable security controls.
When validating data input,s strive to apply size limits for all types of inputs.
OWASP Proactive Control 6 — implement digital identity
How do you identify a user’s identity? The answer is with security controls such as authentication, identity proofing, session management, and so on.
For any of these decisions, you have the ability to roll your own–managing your own registration of users and keeping track of their passwords or means of authentication. As an alternative, you can choose to managed services and benefit from the cloud’s Serverless architecture of services like Auth0.
This topic is broad and when in need to verify and confirm a digital identity layer is handled in a secure manner, refer to NIST 800-63-3B for digital identity guidelines. The NIST document helps with defining how to address password security.
OWASP Proactive Control 7 — enforce access control
It’s highly likely that access control requirements take shape throughout many layers of your application. For example, when pulling data from the database in a multi-tenant SaaS application, where you need to ensure that data isn’t accidentally exposed for different users. Another example is the question of who is authorized to hit APIs that your web application provides.
One tip from Jim here is to avoid referring to roles related data access through code, which leads to hard-coding the policy access. As an example for that, think about checks in code, such as if (user.role === 'admin'). Instead, a capability-like approach such as permissions based access control doesn’t enforce the actual policy. An example for that is if (user.canDelete(blogPostId).
OWASP Proactive Control 8 — protect data everywhere
In the Snyk app, as we deal with data of our users and our own, it is crucial that we treat our application with the out-most care in terms of its security and privacy, protecting it everywhere needed.
Consider the following action items when handling data:
Protect data over the transport, by employing HTTPS in a properly configured manner / up to date security protocols, such as TLS 1.3 and strong cryptographic ciphers.
Make use of secure HTTP headers that leverage the browser’s security capabilities, such as HTTP Strict Transport Security (HSTS) and establishing a Content Security Policy (CSP) for data trust.
When performing cryptography-related tasks always leverage well-known libraries and do not roll your own implementations of these.
OWASP Proactive Control 9 — implement security logging and monitoring
As application developers, we are used to logging data that helps us debug and trace issues concerning wrong business flows or exceptions thrown. Security-focused logging is another type of data logs that we should strive to maintain in order to create an audit trail that later helps track down security breaches and other security issues.
Here are some suggestions for security logging:
all input validation failures
all authentication events, good and bad passwords, logins, or session-related data
all access control failures such as attempts for privilege escalation
OWASP Proactive Control 10 — handle all errors and exceptions
Properly handling errors and exceptions from web applications is not only good for an applications’ health but also ensures that no sensitive data is leaked.
Follow these guidelines:
Manage any exceptions in a centralized manner.
Ensure that unhandled behavior is caught and handled correctly using a standardized methodology throughout.
Ensure that all data being captured avoids sensitive information such as stack traces, or cryptographic error codes.
Join the DevSecCon community
I invite you to join the DevSecCon community and learn more through our webinars and online Snyk User Community that help developers get into security and write secure code!