• BLOG

  • OWASP Top Ten RC1 2017 (rejected) what's new, what's old, what's different ? (EN)

    mar. 19 septembre 2017 Dan Lousqui

    Share on: Twitter - Facebook - Google+

    OWhat ?

    The OWASP Top 10 is a reference for web security flaws tendencies. It is not a standard, nor a classification, but more an awareness document, enabling people to have a large view of what kind of security flaws may exist in the Web Application ecosystem.

    Up until now, the last version of this Top 10 was a version from 2013, that included:

    • A1 - Injection
    • A2 - Broken Authentication and Session Management
    • A3 - Cross-Site Scripting (XSS)
    • A4 - Insecure Direct Object References
    • A5 - Security Misconfiguration
    • A6 - Sensitive Data Exposure
    • A7 - Missing Function Level Access Control
    • A8 - Cross-Site Request Forgery (CSRF)
    • A9 - Using Components with Known Vulnerabilities
    • A10 - Unvalidated Redirects and Forwards

    More recently,, the Release Candidate version 1 of the OWASP TOP 10 2017 was published. It included the following categories of vulnerability:

    • A1 - Injection
    • A2 - Broken Authentication and Session Management
    • A3 - Cross-Site Scripting (XSS)
    • A4 - Broken Access Control
    • A5 - Security Misconfiguration
    • A6 - Sensitive Data Exposure
    • A7 - Insufficient Attack Protection
    • A8 - Cross-Site Request Forgery (CSRF)
    • A9 - Using Components with Known Vulnerabilities
    • A10 - Underprotected APIs

    However... This Release Candidate 1 was been rejected by security professionals. A release candidate 2 version is supposed to be published in November 2017 (source)

    Anyway, let's have a look at this version:

    owasp-diff

    Unchanged items

    Let's begin with what was supposed to stay on the Top 10. First, we can see that 70% of the Top 10 is unchanged. That is not surprising as since 2013, even though many technologies changed (with Rest API, NoSQL, Cloud Hosting, new wave of modern languages...), the "Web Concepts" remained the same: we still use HTTP, we still protect applications communication with HTTPS, we still use HTML within browsers.

    So let's take a look at those good old flaws.

    a. Injection

    Injection is the S-Star of vulnerabilities. When sites face data-leakage (both personal information and passwords), most of the time, it's caused by a SQL injection flaw. There are many other kind of injection: XML, LDAP, commands, etc. This flaw is caused when the source code of an application build manually a structure (or a query) and let unescaped input within.

    b. Broken Authentication and Session Management

    According to the OWASP Documentation:

    • Broken Authentication is when credentials do not have enough protection (weak password, or bad hash protection);
    • Broken Session Management is when session id are not protected (guessable, unprotected cookie, vulnerable to session fixation attacks, present in URL, ...).

    Regarding the Broken Authentication, I partially agree with this category and its description. However, I would not rank it as number 2 of the OWASP; The use of weak passwords is the responsibility of the user (even though you implemented a strong password policy on your website: January17!), and the use of a weak hash algorithm is a real problem if you have been victim of data leakage (Do not misunderstand, I do not recommend MD5!). In my opinion, this category is not as serious as a Cross-Site Scripting or a Local File Inclusion vulnerability.

    And the Broken Session Management... I think this one deserves to get off the Top 10. As of today, not a lot of developers create their own session mechanism, as strong ones are included in the mose used technologies/frameworks. It surely does not deserve the second place of this Top 10.

    c. Cross-Site Scripting (XSS)

    Cross-Site Scripting (or XSS) is also one of the most famous web application security flaw. This vulnerability is present when the HTTP response of a web application contains unsanitzed inputs controlled by a request.

    Generally, it enables an attacker to inject HTML/JS code within a victim browsers. It looks a lot like Injections, the difference being that the malicious code is executed on the victim's browser, and not on the application's server.

    There are mainly two kinds of XSS:

    • Volatile XSS is when the malicious code is contained within the request. In that case, the attacker will target the attack on one victim, and will try to make him perform a malicious request;
    • Stored XSS is when the malicious code is not send by the victim but is stored somewhere one the application (database, attachment ...). In that case, the attacker will target any user that will open the page containing the malicious code.

    When vulnerable to a Cross-Site Scripting vulnerability, besides making a popup with alert('XSS'), an attacker can execute any JavaScript code, enabling him to:

    • Change the website behavior (including man-in-the-middle);
    • Steal session information;
    • Use this website to bounce to other websites using Cross-Origin Requests.

    d. Security Misconfiguration

    This flaw is kind of a tote / medley of any vulnerability that you don't know where to put. According to the OWASP Wiki, it includes:

    • If you have out-of-date component (wait... isn't it the purpose of A9 - Using Components with Known Vulnerabilities ?);
    • Unnecessary features enabled or installed;
    • Default account with default password (wait... isn't it one of the purpose of Broken Authentication ?);
    • Verbose message within errors or stacktrace.

    Well, yes, security misconfiguration is a security flaw... but this category should be called "Other" and should be in the last place...

    e. Sensitive Data Exposure

    This one is exactly the contrary. I totally agree with the title, but not with the content.

    According to the OWASP Wiki, this flaw includes:

    • Data stored in clear text (unencrypted);
    • Data transmitted in clear text (unencrypted);
    • Use of weak cryptographic settings.

    This three point are clearly Security Misconfiguration or Insufficient Attack Protection. In my mind, Sensitive Data Exposure should be (but not limited to):

    • Remote or Local File Inclusions (LFI/RFI) (By the way... where those are supposed to be ?);
    • Backup files accessible directly from the web application (you know, backup.tar.gz ?);
    • Versioning Control System files directly from the web application (you know, Index of /.git/ ?).

    And from this point of view, it could even be in the second position, between Injections and Cross-Site Scripting (XSS).

    f. Cross-Site Request Forgery (CSRF)

    This vulnerability is a real pain in the *** for developer.

    It happens when requests having a "write" behavior (sending a message, register ...) can have all their parameters predicted by an attacker.

    I already wrote an article about it: Legitimate Cross-Site Request... a CORS and CSRF story, and I don't have much more to say about it.

    g. Using Components with Known Vulnerabilities

    And finally, this flaw happens when you use components with known vulnerability.

    It's quite complicated to sort this one out, because the severity of this flaw will depends of the severity of the known vulnerability.

    The best example for this is the heartbleed vulnerability, extremely critical for anyone using OpenSSL 1.0.1 through 1.0.1f.

    Dropping the old "unvalidated redirects"

    The A10 - Unvalidated Redirects and Forwards from OWASP Top Ten 2013 has been removed for OWASP Top Ten 2017.

    I couldn't agree more. Even though if it's a vulnerability, the severity was quite low.

    This vulnerability is when a website have a redirection feature that can be tricked to redirect someone elsewhere.

    For instance, imagine you have a website that links all external with this kind of url: https://super_website.com/redirect?http://external_website.com.

    An attacker could trick (with phishing for instance) someone to click on a https://super_website.com/redirect?http://malicious_website.com.

    In my humble opinion, it's not very critical and deserved to be removed.

    Regrouping of ACL issues

    The OWASP Top Ten 2013 had two items for access control mechanism:

    • A4 - Insecure Direct Object References is when a user is able to access objects that he is not supposed to have access (for instance, when you have an URL like http://website/getInvoice.html?id=18 and if you try http://website/getInvoice.html?id=19, you get access to someone else invoice);
    • A7 - Missing Function Level Access Control is when a user is able to perform operations that he is not supposed to be able to do (for instance, when you have an URL like http://website/getInvoice.html?id=18 and if you try http://website/deleteInvoice.html?id=18, you delete the invoice).

    I like to call this two vulnerability "horizontal access control" (see what other users like you have) and "vertical access control" (do what users with higher privilege than you can do).

    For OWASP Top Ten 2017, they merged those two items in one: A4 - Broken Access Control. I think it is a good idea as the remediation for this two issue is the same: check user privilege before delivering the service.

    Adding something for protection

    This new A7 - Insufficient Attack Protection is quite interesting, because it is not issued by a vulnerability.

    I kind of like it because it promote a in-depth vision, that mean that even though you don't have any vulnerability on your web application, you still should implement some defense mechanism, such as:

    • Anti bruteforce mechanism;
    • Intrusion Prevention/Detection System;
    • Web Application Firewall.

    Adding the "API" buzzword

    Since a few year, the API trend has been quite stable. Now some standards have been used, and many best practices regarding how to handle security within API are used.

    It is a good idea to add this in the top ten, the following flaws can be categorized:

    • Weak authentication mechanism on API (API Key management, JWT Token, OAuth, ...);
    • No throttle mechanism (in order to prevent DDoS);
    • Private API open on the Internet, with full documentation, leading to data leakage, ...

    However, even though API is mature in the startup ecosystem, there are still a lot of "Big Corporate Project" that want to play with startup concepts, and quite often reinvent the wheel,... with many security flaw.

    Conclusion

    Even though this version of OWASP Top Ten 2017 has been rejected, the tendency in this document seems quite in line with what security experts can see in their web application security assessment.

    When I look into suggestions for the RC2 (OWASP Survey / Github Issues), I think the RC2 will a lot looks like the RC1... Response in November 2017 :-)

  • Comments