Let's take run through the OWASP TOP 10 to remind ourselves of how we can better protect our applications, our businesses, and our customers from unlawful and damaging cyber attacks which could be prevented by implementing the correct procedures in the right places.

What is OWASP?

Source

The Open Web Application Security Project is a non-profit organization that was set up to help raise awareness around web application security and provides guidance on how to install preventative measures into your applications, infrastructure, and internal processes.

They have several projects, including an insecure JavaScript application used for security training, but the one that we’re interested in today is the OWASP Top 10.

Updated regularly, the OWASP Top 10 lists the main security threats that affect web applications today. Each point describes a threat, with an overview of the kinds of things you want to do to mitigate the threat as much as possible. At Auth0, we take steps to mitigate most of the issues outlined below, and so when you delegate your authentication needs to us, a lot of this is already taken care of for you.

Let’s run through the list, looking at the threats and what we could be doing to make sure our own applications are secure, and examine features of the Auth0 platform that help to mitigate or entirely remove such threats from your concern.

#1: Injection

Classic SQL injection is a well-known attack and has been around for a long time, particularly when it comes to legacy code. OWASP continues to recognize SQL injection as a common attack that is not only easy to exploit and to detect as a weakness in an application but can also have devastating effects if successfully exploited by an attacker.

In most cases, this type of attack is successful because:

• The application relies on user input which has not been sanitized directly in an SQL query
• The query itself is not parameterized

Assuming that all user input could potentially be malicious is a good mantra to have when validating and processing user input. Parameterizing your SQL queries would also help to protect your data store from malformed queries manipulating your data in undesirable and damaging ways.

As an example of what SQL query parameterization looks like, imagine a query that inserts a new user into a database:

sql = db.prepare "INSERT INTO users (name, email) VALUES ('#{name}', '#{email}')"
sql.execute

In the code snippet above, the values for name and email are inserted into the SQL string without any sanitization performed on the input values. If those input values were to come from form fields, then an attacker could potentially supply malicious values that malform the SQL string and perform an attack. The same query using parameterized values might look like the following:

sql = db.prepare "INSERT INTO users (name, email) VALUES (?, ?)"
sql.execute 'some_user', 'some_user@email.com'

In this case, the values can be escaped and sanitized by the database library, before they are included in the SQL statement. This way the SQL statement cannot be malformed in such a way that it can do damage or expose data.

In more recent times, NoSQL Injection has become a factor when using NoSQL databases such as Mongo. Although it doesn’t use SQL, it’s still potentially susceptible to attacks when user input has not been validated and sanitized, as the query itself can be manipulated. Validating your user input and rejecting values that do not conform to an expected format would be a good strategy.

SQL and NoSQL injection attacks are just a subset of a broad category of injection attacks, which also includes Command, Expression Language and LDAP.

#2: Broken Authentication

Close to our hearts here at Auth0 is broken authentication, which OWASP acknowledges as easily exploitable with extreme damage potential...

Broken Authentication covers many things to do with authenticating users with an application or service, including:

• Automated brute-force attacks using known password lists
• Permission of weak or well-known passwords
• Storage of plain-text or weakly-hashed passwords over strong hashes
• Usage of multi-factor authentication (MFA)
• Improper invalidation of session when logging out, or after a period of inactivity

Implementing MFA into your application will help prevent ‘credential stuffing’ and other brute force attacks, as the attacker will not be able to complete the MFA step in a timely, automated way. Regarding passwords, validate for weak or well-known passwords using a common password list, and hash the user’s password using a strong hashing algorithm (such as Bcrypt or PBKDF2). Never use a weak hash like MD5, and never store your passwords in plain text.

It’s also good practice to purposefully use vague login failure messages when your users enter an incorrect username or password. Otherwise, attackers may be able to identify valid accounts that they could use in order to instigate an attack.

When using Auth0 Universal Login, most of the issues around brute-force attacks, including cross-site scripting attacks (XXS) and strong password hashing are all handled for you. Additionally, we make it very easy to turn on and integrate MFA into your applications for that extra level of security.

3: Sensitive Data Exposure

This entry in the OWASP Top 10 deals with preventing sensitive data being exposed in the event that a successful attack is made, which can in turn help prevent other attacks. It’s about handling sensitive data securely, encrypting data at rest and being diligent about holding only as much data as you need only for as long as you need it. One of the reasons that the EU’s General Data Protection Regulation (GDPR) exists today is because of improper handling of sensitive personal data.

Some things that you can do to help prevent sensitive data being stolen from your application include:

• Making sure that web traffic is encrypted and transmitted over HTTPS using a valid SSL certificate, and that insecure connections are upgraded where possible (HSTS). Let’s Encrypt issue free SSL certificates, making it very easy to make sure your web traffic is secure
• Encrypting and signing any browser cookies that contain sensitive information
• Removing any sensitive data that is no longer needed
• Hashing passwords using a strong hashing algorithm such as Bcrypt or PBKDF2
• Encrypting sensitive data at rest

Note that using automatic database encryption technology could still leave you exposed if an SQL injection attack is successful, as the data has to be read and decrypted at the database level. Doing the encryption and decryption step as part of your core application logic would help prevent this.

#4: XML External Entities (XXE)

An XXE attack is designed to expose a vulnerability in poorly-configured XML parsers. Such attacks can be used to expose sensitive data (such as reading system password files) or invoke a Denial of Service attack (DoS) on a resource.

Preventing this type of attack mostly comes down to developer education and properly-configured XML parsers. Unless there are specific requirements of the parser, they should be configured to not validate and process the Document Type Declaration (DTD) or to ignore the resolution and processing of external entities within the DTD.

If at all possible, use another, simpler data format such as JSON that is not susceptible to XXE.

#5: Broken Access Control

If your application has the capability to distinguish users based on privileges or permissions, then it could be open to broken access control vulnerabilities where attackers are able to elevate their permissions to those that they should not have. Some examples of this are:

• Failing to prevent access to ‘members only’ pages when the user is not logged in or does not have the right permissions to view the page
• Not validating URL parameters that could be changed by the user (e.g. swapping one user ID out for another)
• Trusting that cookie values have not been altered where the value can be used to determine the user’s role. Again, making sure your cookies are both encrypted and signed will give you confidence that their values have not been changed

Taking care to validate user permissions is key. Do not trust any input that could be modified by the user when it comes to working out what that user can do.

#6: Security Misconfiguration

This entry in the Top 10 list has been identified by OWASP as something that is easy to exploit, easy to discover, and extremely common. It concerns themes such as:

• Out of date security patches on the host system
• Application framework security feature not turned on or improperly configured
• Default accounts, passwords and secure keys left enabled and unchanged
• Unused or default ports and services enabled on the host system
• Verbose error pages or directory listing turned on

It is important to make sure that the host system running your applications is updated with the latest security patches, and that your application frameworks have all of the appropriate security features turned on.

Another serious concern in this area is making sure that any secret keys for third-party platforms (such as Auth0) are not committed and uploaded to your source control provider along with the rest of your code, particularly if your application is open source. These can be scanned by attackers using automation tools. Better to store these keys securely separate from your source code.

#7: Cross-Site Scripting (XXS)

XXS is one of those terms that has been around for a long time and most software developers have heard of, yet continues to feature as an attack vector that is very common and easily exploitable.

This type of attack mostly involves the injection of unsanitized input that causes the user to unwittingly interact with a malicious site or file, but does come in a few different flavors:

• Reflected XXS: A website is discovered that does not properly sanitize input through the URL. An attacker crafts a link (containing the attack) to the website and distributes it — usually via email — in the hope that an unsuspecting recipient will click on the link. If they do, the attack is executed and could download further scripts that steal user sessions and cookies, sending them to the attacker.
• Stored XXS: Unvalidated user input (such as files) are uploaded and stored, where they could later be opened by a user or administrator. This could also extend to comments provided by a user on a forum or social media, where their input has not been properly sanitized
• DOM XSS: The DOM is manipulated as a result of a call to a JavaScript API that could contain malicious content, and injected at runtime

A lot of XXS issues can be mitigated by making sure that any data retrieved from third-party sources is properly encoded according to the context. Also, using frameworks that contain built-in mechanisms for sanitizing user input (such as Ruby on Rails or Play Framework) would go a long way to protecting your applications from these types of attacks.

Source

#8: Insecure Deserialization

While insecure deserialization attacks are difficult to exploit and not as common as the other vectors in the Top 10, OWASP points out that they have been included as result of an industry survey. Nevertheless, if an attacker was to successfully execute an attack of this nature, it could potentially lead to a remote code execution attack, which is potentially very serious.

If your application deserializes objects from untrusted sources, you could be open to this kind of attack. The only safe way to prevent these from happening is to not accept serialized objects from untrusted locations. If that’s not possible, OWASP recommends using digital signatures to verify integrity, enforcing strict primitive type checking, and performing deserialization logic inside a low-privilege environment.

#9: Using Components with Known Vulnerabilities

Software these days tends to make use of many third-party components, and so being diligent about which version of these components you are using and keeping them up to date is paramount in protecting your application from attacks that stem from vulnerable dependencies.

Unfortunately, the number of dependencies that a given application uses — directly or indirectly — can sometimes make identifying and triaging vulnerable components difficult; usually meaning that the task doesn’t get done and developers are completely unaware as to their existence.

OWASP recommends a few tools that can help to identify and upgrade components that present a security risk, including their own OWASP Dependency Check. Node.js applications using NPM version 5.10.0 or 6 and above can make use of the audit command in the terminal, which can identify and automatically upgrade dependencies that have been identified as vulnerable.

Another popular tool (and one that we use ourselves here at Auth0) for the checking of vulnerabilities in dependencies is Snyk. Snyk can be set up to evaluate your projects directly in GitHub, or can be used as a command-line tool to act directly on your project code.

#10: Insufficient Logging and Monitoring

Being able to discover breaches, attack patterns, and user activity is a key property of a secure system. Without sufficient logging and application monitoring, it will be difficult to ascertain how a system was breached, where the breach came from, and where the holes lie in your application security strategy. If you don’t know where the holes are, you can’t fill them in!

OWASP recommends that application activity — particularly around authentication and permission activities — are logged in a common format that can be easily processed by a centralized logging system. As much detail about user context should be logged and retained as possible without compromising their personal data, which not only includes personally-identifiable information (PII) but also secure keys, access tokens, and session tokens. If detailed information that could be used to identify a person must be recorded for forensics purposes, use a secure data warehouse coupled with tight access controls available only to trusted individuals.

Mitigating Security Issues with Auth0

The Auth0 platform has many features which help protect your application and your users from security attacks. For starters, simply by using our Universal Login offering, you are effectively delegating all the work of making your login pages secure and resilient to attacks to us.

Additionally, Multi-factor Authentication (MFA) can easily be enabled on any application to provide an extra layer of security when your users log in and decreases the likelihood of unauthorized access. Options for completing the MFA step include receiving push notifications and codes via mobile authenticator apps.

Auth0’s Anomaly Detection includes options for protecting against brute-force attacks, blocking repeated attempts to log in and notifying designated recipients of such unauthorized attempts. Furthermore, enabling our Breached Password Detection feature means that your users will be notified if we detect that their credentials were part of a published security breach.

Comprehensive logging is a feature of the Auth0 platform, which can be interrogated for events, such as:

• Failed login attempts
• Failed password changes
• Failed access token exchanges
• Too many failures

and many more. Logs can also be shipped to other providers, such as Logstash, Papertrail, and Splunk via the respective extensions.

As added protection against bucket brigade attacks, also known as man-in-the-middle (MITM) attacks, we also enforce HTTPS connections to our services, meaning that any non-HTTPS connections are upgraded according to the HSTS specification.

Finally, to protect against XXE attacks through SAML, we use our own fork of XML parsing library 'XMLDOM', which does not allow DOCTYPE entity parsing at all—a key component of XXE attacks.

Avoid Security Distaster

Some of these solutions are easy to implement and take only a short amount of time, while others require a bit more thought and planning to do properly. However, anything that can be done to improve the security of your products — especially where personal information and other sensitive data is concerned — can only be beneficial, and could be a key factor in preventing a data disaster should an attack be attempted.

In this article, we’ve had a brief run through the OWASP Top 10 and examined the main threats to web application security that exist today. We considered some of the possible mitigations against such threats, and how we can all do better to help protect our businesses and our users from problems arising as a result of poor and insecure implementation.

We've also looked at several key features of the Auth0 platform that bolster the security of web applications and APIs, from relieving you of a lot of these issues through Universal Login, to rich audit trails through comprehensive logging. To start taking advantage, sign up for a free account today.