OWASP Top 10 Most Critical Web Application Security Risks of 2017

Image

As organizations' IT environments become increasingly more complex, so too does the software they install on their systems. Software developers and managers have embraced microservices written in node.js and Spring Boot, for example. These new types of dynamic applications challenge organizations to establish appropriate trust chains and secure old code hosted on the web. Single-page applications, which are in part due to the emergence of JavaScript as the web's primary language, have also helped shift fundamental application technology and architecture. These changes are not without their drawbacks. Pushed out by ever-shortening software programs' lifecycles, some applications suffer from risks that undermine the digital security of financial, healthcare, retail, and other business sectors. It's important that developers and managers learn about these most common risks so that they can secure their applications. Towards that end, the Open Web Application Security Project (OWASP) releases the top 10 most critical web application security risks on a regular basis. It culls this information from more than 40 data submissions received from companies specializing in application security, with the data spanning vulnerabilities gathered from hundreds of organizations and over 100,000 deployed applications and APIs. OWASP rates each risk according to its exploitatability, weakness prevalence, weakness detectability, and technical impacts. These risks are ever-changing. For instance, 500 peer submissions from the community provided OWASP with two forward-looking risk categories to add to its list in 2017. The organization also added a new category from source code analysis security testing (SAST) data sets. There were additional changes. Two old categories that made OWASP's Top 10 in 2013, Insecure Direct Object References and Missing Function Level Access Control, merged together into a single category "Broken Access Control" for its 2017 list. Additionally, OWASP retired Cross-Site Request Forgery (CSRF) along with Unvalidated Redirects and Forwards based upon their comparative lack of prevalence in modern applications.

Here is OWASP's ranking of the Top 10 most critical web application security risks for 2017 along with an explanation of how to protect against each risk:

Image

OWASP Top 10 - 2017: The Ten Most Critical Web Application Security Risks page 4

1. Injection

Exploitability: 3 - Easy Weakness Prevalence: 2 - Common Weakness Detectability: 3 - Easy Technical Impacts: 3 - Severe Injection includes SQL, OS, LDAP, and other vulnerabilities through which an interpreter receives untrusted data as part of a query or command. An attacker can therefore abuse injection to trick the interpreter into executing unwanted (or malicious) code or unintentionally granting them access to sensitive data. Developers and managers can protect applications against injection by regularly conducting source code review. They can do so by including SAST and dynamic application test (DAST) tools into the continuous integration and continuous delivery (CI/CD) pipeline. They should also use a safe API, whitelist server-side input validation, and SQL controls.

2. Broken Authentication

Exploitability: 3 - Easy Weakness Prevalence: 2 - Common Weakness Detectability: 2 - Average Technical Impacts: 3 - Severe Authentication and session management functions aren't always implemented for applications correctly. When this occurs, a bad actor could compromise passwords, keys, or session tokens. They could also exploit the weaknesses to masquerade as authenticated users. Multi-factor authentication is one of the best ways to defend against broken authentication, as it can prevent such things as stolen credential reuse attacks. Developers and managers should also not ship or deploy admin credentials with applications. Finally, they should create features that check for weak passwords and limit the number of incorrect login attempts.

3. Sensitive Data Exposure

Exploitability: 2 - Average Weakness Prevalence: 3 - Widespread Weakness Detectability: 2 - Average Technical Impacts: 3 - Severe Some applications and APIs don't incorporate proper safeguards to protect sensitive information such as financial data or login credentials. With those vulnerable programs, a digital attacker could steal and subsequently abuse that information to commit identity theft or credit card fraud. The threat of sensitive data exposure cannot be mitigated until developers and managers have determined the protection needs of data in transit and at rest. From there, they should identify which data is sensitive and encrypt it using strong and up-to-date algorithms. At the same time, they should not unnecessarily store sensitive information but instead dispose of it securely.

4. XML External Entities (XXE)

Exploitability: 2 - Average Weakness Prevalence: 2 - Common Weakness Detectability: 3 - Easy Technical Impacts: 3 - Severe A processor of Extensible Markup Language (XML), which is a type of markup language that specifies the encoding guidelines for documents, is responsible for reaching XML documents and taking actions accordingly. Some XML processors aren't properly designed or poorly configured insofar as they might evaluate external entity references in XML documents. These entities, in turn, can allow attackers to expose internal file shares, conduct internal port scanning, and achieve remote code execution. Developers and managers can mitigate XXE flaws by not serializing sensitive data and using less complex data formats like JSON. They should also make sure to patch and upgrade all XML processors used by the application as well as disable XML external entity processing in all relevant XML parsers.

5. Broken Access Control

Exploitability: 2 - Average Weakness Prevalence: 2 - Common Weakness Detectability: 2 - Average Technical Impacts: 3 - Severe Authenticated users should only be allowed to do so much when interacting with an application. However, some applications don't strictly enforce those restricts. Attackers can then abuse those oversights to access other users' accounts and expose sensitive files. To address the risk of broken access control, developers and managers should implement access control mechanisms that, among other things, deny by default. They should also log access control failures and alert admins when necessary. Each of these controls should be created server-side so that an attacker can't modify the control check or metadata.

6. Security Misconfiguration

Exploitability: 3 - Easy Weakness Prevalence: 3 - Widespread Weakness Detectability: 3 - Easy Technical Impacts: 2 - Moderate Security misconfigurations are one of the most common application security risks out there. They result from instances of open cloud storage, misconfigured HTTP headers, error messages containing sensitive information, and other vulnerabilities. Attackers can exploit those configurations to log into admin accounts using default passwords, discover access control flaws, and steal sensitive information. Developers and managers can mitigate the risk of security configuration by designing a minimal platform for an application that's free of unnecessary features and components. They should also consider implementing a segmented application architecture as well as using an automated process to verify the effectiveness of configurations in the application environment.

7. Cross-Site Scripting (XSS)

Exploitability: 3 - Easy Weakness Prevalence: 3 - Widespread Weakness Detectability: 3 - Easy Technical Impacts: 2 - Moderate Sometimes an application includes untrusted data in a new web page without proper validation or escaping. That's one example of a cross-site scripting (XSS) flaw. Attackers can abuse those weaknesses to execute scripts in a victim's browser and thereby hijack user sessions or redirect visitors to malicious websites. Fortunately for developers and managers, there are frameworks such as Ruby on Rails and React JS that automatically escape XSS by design. These individuals can incorporate techniques to escape untrusted HTTP request data based on the context of the HTML output into their applications. Finally, they can implement a content security policy (CSP) to further mitigate potential XSS vulnerabilities.

8. Insecure Deserialization

Exploitability: 1 - Difficult Weakness Prevalence: 2 - Common Weakness Detectability: 2 - Average Technical Impacts: 3 - Severe The biggest concern with insecure deserialization is remote code execution. Even if these types of flaws don't lead to RCE, however, attackers can still leverage those weaknesses to perform replay attacks, privilege escalation attacks, and other types of digital offenses. Integrity checks such as digital signatures on any serialized objects can help protect against insecure deserialization. Developers and managers should also isolate and run code that deserializes in low privilege environments as well as monitor deserialization with the purpose of issuing a notification if a user deserializes constantly.

9. Using Components with Known Vulnerabilities

Exploitability: 2 - Average Weakness Prevalence: 3 - Widespread Weakness Detectability: 2 - Average Technical Impacts: 2 - Moderate Many of today's applications come with libraries and frameworks. These components may or may not run with the same level of privileges as the application. By extension, if a digital attacker locates a vulnerable component and exploits it, they could steal sensitive data or compromise a critical server. Some components aren't necessary for an application. With that in mind, organizations should make the removal of unnecessary features a crucial part of their application security program. Developers and managers should also obtain components from only official sources and monitor all components for newly discovered vulnerabilities.

10. Insufficient Logging & Monitoring

Exploitability: 2 - Average Weakness Prevalence: 3 - Widespread Weakness Detectability: 1 - Difficult Technical Impacts: 2 - Average Logging and monitoring provide crucial insight into an organization's IT environment. Without sufficient investment into these two security measures, however, an attacker could more easily infiltrate systems, move laterally on the network, and steal data. Developers and managers can protect organizations against these types of threats by ensuring all login, access control failures, and server-side input validation failures can be logged with sufficient user context. They should also ensure that all logs are generated in a format that can be easily consumed by a centralized log management solution.

Just a Starting Point…

All organizations and software development teams have their own unique culture and technology that shape what kind of application security program they can develop. OWASP's Top 10 can help those entities create a program that works for them. Developers and managers shouldn't stop with that list, however. They should remember that hundreds of issues could affect the security of a web application. Towards that end, they should establish strong application security controls and focus on creating a dynamic security culture among their team or organization. You can learn more about Tripwire and the critical security controls, here.