Looking to get savvy on cybersecurity for your web app? The OWASP Top 10 is a good place to start. Founded in 2001, the Open Web Application Security Project (OWASP) serves as an open-source community where security experts from around the globe come together and pool their knowledge to create a resource for building a more secure web. They maintain a list of the top 10 most critical web application security risks to help anyone with a website or app guard against hackers. Let’s dive into the OWASP Top 10 and see how you can take that first critical step toward securing the future of your application’s digital assets.
1. Injection
Injection typically occurs when a malicious actor supplies untrusted data to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Sometimes injection can occur unintentionally, such as when a user inputs a name into a form that triggers a command.
The simplest example of injection may be the curious case of Christopher Null, a Wired reporter whose last name makes it impossible for him to input his name into some online forms. Unsurprisingly, there’s also a relevant xkcd comic:
SQL, LDAP, XPath, NoSQL, XML parsers, SMTP headers: There’s a style of injection for almost any language. Ubiquity, variety, and a large attack surface come together to make injection number one on the OWASP Top 10.
Prevention: As common as injection attacks are, they aren’t so difficult to prevent once you’re aware of them. Data should be sanitized whenever possible with input validation to ensure the end user can input only information you expect to receive in a given form or entry field, and not malicious commands.
Using an application interface (API) that avoids the use of the interpreter entirely or provides a parameterized interface is also recommended. You can also contextually escape user data with the escape syntax for a given interpreter.
2. Broken authentication
We’ve seen some major breaches in recent years, and if you were unlucky enough to be among those affected you hopefully received a prompt to change your password before any serious damage was done.
Ever wonder what happens to those old leaked user accounts and passwords? They end up in massive databases circulated throughout the dark web. The rise of credential stuffing (the act of randomly trying known username/password combinations) and the prevalence of poorly implemented authentication and session management have placed broken authentication firmly in the number-two spot.
Prevention: Enforcing strong passwords among users is always a good start. Properly implementing multifactor authentication is even better. You can harden credential recovery, registration, and API pathways against account enumeration attacks by using standardized messaging. User session IDs should always be invalidated while logging out or after extended periods of activity.
3. Sensitive data exposure
In July 2018, Chrome started marking all pages using HTTP as not secure in a push to convert the web to HTTPS. And for good reason. Data passed through HTTP is unencrypted, leaving usernames, passwords, credit card numbers, health records, and other sensitive data at risk.
Rather than directly attack encryption, hackers prefer to execute man-in-the-middle attacks, steal keys, or access clear-text data off the server or a client’s browser. Any data stored or transmitted without encryption is liable to attack. Even when crypto is employed, weak keys, improper key management, or rotation schemes can compromise security and expose sensitive data.
Prevention: Encryption is the best way to prevent sensitive data exposure. All data in transit should be protected with protocols such as TLS and SSL. Employ perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and security parameters. Protect data at rest by encrypting stored data when possible. Never store passwords as plain text; salt and encrypt them with hash functions such as Argon2 and script.
4. XML external entities (XXE)
Extensible Markup Language (XML) is a popular data format prized for its extensibility and flexibility. An XML External Entity (XXE) attack occurs when an XML parser is tricked into referencing a tampered external entity.
The attack can lead to compromised confidential data, denial-of-service (DoS) attacks, and server-side request forgeries (SSRIs), among other system impacts. The infamous billion laughs DoS attack is a prime example of an XXE attack.
Prevention: The simplest way to prevent an XXE attack is to disable external entities and DTD (document type definition) processing in all XML parsers in the application. It is also best practice to avoid serialization of sensitive data and use less complex data formats such as JSON. Keep all XML processors and libraries up-to-date and implement server-side input validation (e.g., whitelisting).
5. Broken access control
Access controls exist for a reason: They ensure everyone from admins to content creators to end users have access only to the appropriate permissions. Giving malicious third-party access to admin-level permissions could result in anything from non-paying users gaining access to premium content to a complete system takeover.
Ever access a web page you should have been able to browse only when logged in? That website is vulnerable to forced browsing. When you can bypass authentication entirely simply by knowing the URL, it’s possible to brute-force your way through different paths such as /admin or /settings. You can even perform actions on the behalf of users, such as deleting a credit card on someone else’s Twitter campaign.
Prevention: Secure access control starts on the server side. In addition to employing methods to prevent broken authentication (which leads to broken access control), you can rate-limit API and controller access to foil automated attacks, enforce record ownership on various levels of user access, and set access control for all objects, except public resources, to deny by default.
6. Security misconfiguration
One of the most commonly seen issues, security misconfiguration is generally the result of negligence. It encompasses failing to keep frameworks, operating systems, and other aspects of app infrastructure up-to-date; using the wrong settings; relying on default security configurations; opening cloud storage, and error messages that say a little too much.
Prevention: DevOps solves a lot of the problems that usually lead to inconsistencies in security configurations across multiple environments. Having a repeatable way to quickly deploy environments with identical configurations across development, QA, and operations with appropriate access permissions and credentials can prevent the kind of mistakes that lead to other vulnerabilities.
7. Cross-site scripting (XSS)
A cross-site scripting (XSS) attack is a type of injection that targets end users through the client side of a trusted website. XSS attacks can be used to steal cookies and user sessions as well as to redirect the end user to a malicious page. XSS attacks come in three main flavors:
- Reflected XSS often takes the form of a malicious script linked in a comment on an article or video. When an unwitting user clicks the link, the page is reflected at him or her through the trusted domain but with the custom script. Since the browser thinks the script came from the trusted web page, the script executes, compromising that user’s session.
- Stored XSS takes advantage of unsanitized user input to store a malicious script that can be viewed at a later time by another user or administrator.
- DOM XSS targets vulnerable client-side APIs and frameworks that dynamically generate HTML, such as in a single-page application (SPA).
Prevention: Data sanitization and input validation are central to preventing XSS attacks. APIs should properly escape user input as data so that the browser can’t mistakenly interpret it as code.
8. Insecure deserialization
Data serialization is the process of translating structured data into a format that is easy to store or share. The original data structure can be recovered through deserialization. But what happens if an API mistakenly deserializes an object from an untrusted source?
If there are classes available to the app that can change behavior during or after deserialization, a hacker could alter application logic, perform a remote code execution attack, or change access controls.
Prevention: Do not accept serialized objects from untrusted sources. You can also limit the app to serialization mediums that permit only primitive data types. Other preventative measures for handling serialized objects include integrity checks such as digital signatures; strict type constraints; code isolation; and extensive monitoring and logging of deserialization exceptions, failures, and connections.
9. Using components with known vulnerabilities
OWASP is using components in the broadest sense here; it isn’t talking just about third-party libraries and plug-ins but also operating systems, database management systems, and other elements that go into a technology stack. Each of these components could exhibit any of the vulnerabilities covered on this list.
Prevention: While components have brought huge gains in programmer productivity, they come with the added responsibility of looking beyond your code when staying up-to-date on the latest security best practices. Remove unnecessary dependencies and superfluous features. Version control systems such as Git and tools such as retire.js can help you keep your technologies on their latest versions.
10. Insufficient logging and monitoring
Every successful exploitation starts with a probe for vulnerabilities. The longer you allow a probe to continue, the more likely an attack will be successful. Seemingly benign things such as failed logins, high-value transactions, and persistent errors could tip you off to a potential attack, allowing you time to take action and harden security.
Prevention: It’s important to maintain auditable records and traceability of everything that happens with your system and data. Logs need to provide enough user context to identify suspicious accounts but not enough information to trigger another security vulnerability. Application performance management (APM) tools such as Stackify Retrace can help you monitor and manage all the logs from the components in your stack.
The road to cybersecurity
Now that you’re acquainted with the OWASP Top 10, what comes next? In a world where 60% of small businesses go out of business in the wake of a cyberattack, it pays to be proactive.
