blog-a-closer-look_-owasp-top-10-application-security-risks

A Closer Look: OWASP Top 10 2017 – Application Security Risks

Dec 03, 2017 By Arden Rubens

Open Web Application Security Project (OWASP) is an organization filled with security experts from around the world who provide information about applications and the risks posed, in the most direct, neutral, and practical way. Since 2003, OWASP has been releasing the OWASP Top 10 list every three/four years. The list consists of the top biggest Application Security Risks according to OWASP.

 

This list is considered an AppSec benchmark and is endorsed by the application security community. The list is compiled with the latest vulnerabilities, threats and attacks, as well as detection tactics and remediation. OWASP Top 10 project members create the list by analyzing the occurrence rates and the general severity of each threat facing our rapidly evolving application world.

 

Comparing the 2013 list to the newly released 2017 list

Comparing the 2013 list to the newly released 2017 list, source (PDF)

 

The 2017 OWASP Top 10 list has recently been re-released to the public after the initial version was received with some controversy. The new and revised list is based on over 40 data submissions from firms that specialize in application security and an industry survey that was completed by over 500 individuals. It contains three large-scale vulnerability updates and updated attack scenarios. Let’s take a closer look at the list as a whole and what key changes were made in OWASP Top 10 Application Security Risks 2017.

 

A1 – Injection

If your application is able to receive user input that goes into a back-end database, command, or call, your app is able to fall to the face of code injection attacks. Injection flaws are a set of security vulnerabilities which occur when suspicious data is inserted into an app as a command or query. Known injection attacks include SQL, OS, XXE, and LDAP.

 

The most common of the code injection attacks are SQL Injections, also known as SQLi. An SQLi attack is done when malformed code is sent to the database server, thus leading to the exposure of your data. And this attack style is so simple and easy, anyone with access to the internet can do it – SQLi scripts are available for download and can be acquired easily. As one of the most common vulnerabilities, we seem to know a lot about it and yet, new SQLi attacks are always popping up – just take a quick look at the SQLi Hall-of-Shame and see for yourself.

 

Continue your reading:

 

A2 – Broken Authentication

When an application’s functions are not implemented correctly, the attack surface is open for criminals to easily break in and compromise passwords, session IDs, and exploit other flaws using stolen credentials. Sessions should be unique to each individual user, and without some necessary session management, an attacker can sneak in, disguised as a user to steal tokens and passwords to gain the access it is after.

 

A3 – Sensitive Data Exposure

Sensitive data exposures may occur when security controls – such as HTTPS – are not implemented correctly, thus leaving a hole for attackers to steal sensitive information such as passwords, payment information, IDs, addresses, and anything else you may have stored which can be of value. Applications should ensure that access be authenticated and data be encrypted. A failure of such may lead to a major privacy violation.

 

A4 – XML External Entities (XXE) [NEW]

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

 

A5 – Broken Access Control

A flawed access control may be caused by unenforced user restrictions and this allows attackers to exploit and access unauthorized functionality or data. Access control is meant to control what “authorized” users are allowed and not allowed to do within an app, and to establish proper access control, the app must ensure that it is performing solid authorization checks and that proper authentication is in place to tell which users are privileged and which are in fact random internet users.

 

Broken access control may be due to that developers often fall to the difficulty of implementing a proper access control with all of the rules in place. And in various cases, access control rules are placed throughout the code and the collection of rules becomes scattered and nearly impossible to follow and understand.

 

A6 – Security Misconfiguration

According to OWASP, Security Misconfiguration is the most commonly seen issue. Strong security requires a good and secure configuration set and deployed for apps, frameworks, servers, database, and custom code, and all should be kept up to date. Otherwise, the flaws to come as a result can be exploited by attackers and will allow them to access privileged data. Proper configuration of an application’s entire environment needs to be defined, implemented, and regulated or it may lead to severe security holes.

 

A7 – Cross-Site Scripting (XSS)

Following a broad disagreement with the previous A7 (which was “Insufficient Attack Protection”), OWASP updated the list and placed Cross-Site Scripting as the updated A7. Cross-Site Scripting, commonly known as XSS, is a vulnerability that is often found in web apps. XSS allows attackers to inject client-side scripts into public facing web pages and, in many cases, can be used by attackers to work their way past access controls.

 

This is done by tricking a browser so that it accepts data from an untrusted source, and this typically happens when attackers use familiar code (such as JavaScript, for example) as developers don’t scrub out these characters.

 

Apps that allow user input without having full control over output may be highly at risk to XSS attacks. When an XSS attack is successful, attackers are able to cause serious damage to websites and have the ability to drag users on to other websites (often hosting more malicious code). Other known kinds of XSS attacks are Stored XSS, DOM Based XSS, and Reflected XSS.

 

Continue reading:

 

A8 – Insecure Deserialization [New]

According to OWASP, “Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process – taking data structured from some format, and rebuilding it into an object.”

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

 

A9 – Using Components with Known Vulnerabilities

Component, including libraries and frameworks, may be taken from the open source community and should be used with caution in case vulnerabilities are lurking. As a vulnerable component is exploited, attackers can leverage it and cause the app serious damage and a major loss of data that can undermine the app, and perhaps even the organization.

 

By taking using components with known vulnerabilities, attackers can take advantage of that are easily attempt an SQLi and an XSS (among other attack methods) to attempt to takeover an occupy the app.


A10 – Insufficient Logging & Monitoring

According to OWASP, insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

 

Click here to view the list as released by OWASP (PDF)

jumping 1

 

 

Learn more about our supported OWASP standards

The following two tabs change content below.

Arden Rubens

Social Media Manager & Content Writer at Checkmarx
Arden is the social media manager and a content writer at Checkmarx. Her blogs focus on cyber security trends and the latest developments in the world of AppSec. She aims to educate and inspire developers, security professionals, and organizations to find the best defense against online threats.

Stay Connected

Sign up today & never miss an update from the Checkmarx blog

Get a Checkmarx Free Demo Now

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.