•  Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  •  London: +44 (0)203 5983740 
  •  New York: +1 646-781-7580 
  • Dubai: +971 (0)4 427 0429

An Overview of OWASP Top 10 2017

You are here

12

May

An Overview of OWASP Top 10 2017

The release candidate (RC1) version of OWASP (Open Web Application Security Project) Top Ten Web Vulnerabilities for 2017 has recently been published and it is currently undergoing a public comment period. OWASP Top 10 2017 has several changes and I deemed this a good chance to discuss the changes as well as reiterate some concepts.

Before we start discussing the changes, as a quick reminder, OWASP has been founded back in 2001 and since then it has grown significantly to become a well-recognised reference for web application security. OWASP in simple words is an accumulation of articles, methodologies, documentation and tools that aims to fill the gap between information security and software development. OWASP provides a road map to aid organisations' understanding of security issues. More importantly it lends credence to penetration testing reports allowing security consultants to promote security best practices.

The following image from OWASP shows the changes that took place in the new release of the OWASP Top 10. These are discussed in the following sections.

Web application vulnerabilities OWASP TOP 10 2013 vs 2017

Merge of Access Control Weaknesses Categories

"A4-Insecure Direct Object References" and "A7-Missing Function Level Access Control" categories from OWASP Top 10 2013 were merged into a single category "A4-Broken Access Control". Both of the previous categories related to different types of access control weaknesses. Successful exploitation of access control weaknesses results in exposure of sensitive information, for example client or business data. This could have reputational, legal and financial ramifications for organisations.

On a daily basis, we get to test various complicated web applications most of which are based on well-known frameworks or content management systems (CMS). The majority of these enforce various aspects of security during development either explicitly or implicitly. Unfortunately, we still identify access control weaknesses frequently, even in applications for which secure development guidelines and practises have been followed. The main reasons in my opinion are as follows.

Firstly, although many frameworks and CMSes have access controls built-in, often these are not properly used or enforced. Reviewing every functionality and resource to ensure only authorised people can access these is crucial. Frequently applications are developed in a way that rely on hiding or obscuring functionality. One of my colleagues was able to access a JavaScript based administrative area in a website the other day. This was done by using the browser developer tools to quickly analyse the JavaScript codebase and eventually invoke a method through the browser JavaScript console that displayed the hidden administrative functionality. Next intercepting the API generated requests led to access control weaknesses in the administrative API which could allow attackers to carry out administrative operations. Attackers usually have to work on a black-box approach and they have plenty of techniques in identifying hidden web pages, API endpoints and other information. Hence, relying on hiding or obscuring functionality is not a means of protection, instead access controls should be strictly enforced on the server-side.

Secondly, access control weaknesses can be introduced in several levels, such as the web server's configuration, the back-end code and other supporting services such as APIs. Depending on the complexity of the application this can become really challenging. A few months back, I discovered an access control scenario where an attacker belonging to a different organisation could "steal" employees from other organisations, in a sense of moving them under the context of their organisation, effectively compromising their personal account and data. This access control could be attributed to several reasons:

  • Unnecessary complexity was introduced by allowing employee transfers between organisations in an already complicated application.
  • Although access control was being enforced in most cases, multiple user roles further added on the complexity of enforcing access control for every scenario.
  • Usage of non-random sequential IDs to reference various objects in the web application made this exploitable.

 

Access control vulnerabilities can be one of the most complicated security issues to protect against. It requires organisations to fully understand their applications' stacks and meticulously ensure that only authorised actions can occur on the system. Testing for it requires experience as consultants need to be able to think out of the box looking for bizarre exploitation scenarios. As time progresses we may start seeing more and more access control weaknesses, mainly because as technology is evolving applications become more and more sophisticated and thus complicated. One could argue that A4 should be higher in OWASP Top 10; unfortunately we still see many applications that introduce "old-school" vulnerabilities such as SQL Injection (A1).

All in all, merging these two categories together eliminates any confusion that could arise because of the wording in the previous categories in OWASP Top 10 2013. This allows organisations and developers to focus on one key point which ensures that any type of user is only allowed to access resources (for example website functionality, pages and objects) that they are authorised to access.

Removal of Open URL Redirects Category

Category "A10-Unvalidated Redirects and Forwards" is being now removed from the OWASP Top 10 list as OWASP statistical data showed that it is not as prevalent as expected. The category covered URL redirection vulnerabilities which stem from using untrusted user input to redirect the user to another page.

Although existence of this vulnerability in the OWASP Top 10 2013 was another way of stressing the importance of never blindly trusting any kind of user input, in the majority of the times we identify open URL redirects, they pose a minimal risk to organisations. Actual exploitation of such vulnerabilities would usually require a significant amount of social engineering, up to the point where it would be easier for an attacker to craft their own phishing website in order to harvest sensitive information. However, there has been several cases where a seemingly harmless Open URL redirection vulnerability was chained along with other web vulnerabilities to open the possibility of compromising client data. Exploitation of such a vulnerability in a social media network, for example, would yield a high success rate and lead to huge data exposure. The following article provides a great example of how Open URL redirection vulnerabilities could combined with other vulnerabilities to cause severe damage:

https://sites.google.com/site/bughunteruniversity/best-reports/openredirectsthatmatter

It should be stressed that this issue being removed from OWASP Top 10 does not by any means imply that this should be ignored by developers or cannot pose a big risk to organisations.

Underprotected APIs Category

Category "A10-Underprotected APIs" has been added in the OWASP Top 10 2017. APIs of any kind, such as REST/JSON and SOAP/XML based, are becoming an indispensable element of every modern application and technology. Essentially they constitute an invisible web application that lacks UI but has special properties, for example the protocol in use to transfer data back-and-forth from the server or the way authentication and authorisation is implemented. APIs are being consumed by programs and therefore user interaction with these is not obvious as communication of the website with these happens transparently.

Since they constitute a web application, attackers can look for well-known web vulnerabilities, mainly the ones listed in OWASP Top 10, by sending direct requests to these services. This can be achieved by intercepting and analysing the website's traffic, accessing publicly available web service description documents (WSDL), reading the client-side available JavaScript, reverse engineering a mobile application in order to retrieve the code that generates API requests and so on. Next an attacker would have to get familiar with the API and manage to craft successful requests to API by, for example, discovering what kind of data each parameter requires. This is mainly done through trial and error techniques or by reading web service description documents if they are publicly accessible. At this point they would be able to start injecting payloads in order to identify vulnerabilities. As a side note, white-box testing for APIs in the sense of providing the API documentation to testers is recommended, since attackers are assumed to have unlimited time for targeting an application.

The past months we have identified plenty of XML External Entity (XXE) vulnerabilities in applications using SOAP/XML based APIs. XXE is a fairly complicated attack that allows attackers to read sensitive files stored on the server by crafting user input in such a way to exploit misconfigured XML parsers. Therefore APIs further widen the attack surface for common web application vulnerabilities.

OWASP's intention with this category is about raising awareness in terms of API security and this is a good move because:

  • It stresses the importance of paying the same attention to securing such services as with the main application. These may be overlooked or be considered less important because it is not directly obvious how the client-side communicates with them since they lack the UI. In some other cases, securing APIs from specific attacks is not straightforward. For example, CAPTCHA software cannot mitigate brute-force or denial-of-service attacks against APIs due to their nature. Instead other security controls can be put in place, for example, limiting the number of requests to the API a host can generate, however these are not as straightforward to implement as a CAPTCHA software.
  • APIs will start being targeted more often as they become more popular. As APIs are being consumed more and more by various rich-clients, new techniques, methodologies and tools will be coming out to decrease the complexity, the technical skill and the time required for exploiting such services. As such the likelihood of such services being exploited successfully will be increasing.

 

Essentially, this category can be directly related to all the rest of the OWASP Top 10 vulnerabilities. As such, in my opinion, this category emphasises one single point:

Any kind of client data that arrives and is used for some sort of processing on the server-side should be treated as untrusted.

The following links provide further information on protecting APIs.

 

Insufficient Attack Protection Category

The most notable change in OWASP Top 10 2017 was the addition of category "A7-Insufficient Attack Protection". This is about the web application having Web Application Firewall (WAF) or RASP (Runtime Application Self-Protection) technologies in place to further enhance security. Both of these technologies are designed to detect and deter attacks before final processing of malicious user input occurs, in other words before exploitation. WAFs are placed in front of the web application evaluating each request being sent to it in order to decide whether that contains malicious input that could exploit the application and effectively block it. In contrast, RASPs are part of the web application's stack and monitor all the function calls that take place on the runtime in order to attempt to detect any suspicious actions and block them. Comparing these technologies is out of the scope of this post, however the following paper from SANS provides excellent information on their differences.

https://www.sans.org/reading-room/whitepapers/analyst/protection-inside-application-security-methodologies-compared-35917

After the RC version of OWASP Top 10 2017 was released, there has been a lot of noise in the information security community regarding this addition. Below, I am listing some arguments against this category being part of OWASP Top 10 2017.

  • Not having a WAF or RASP in place is not an actual vulnerability, it is a lack of an extra security layer.
  • Security consultants are generally ambivalent about these technologies because as time progresses they become susceptible to bypasses effectively allowing attackers to exploit well-known web application vulnerabilities.
  • This could encourage developers to not follow all secure development guidelines as they may think that the WAF or RASP will stop such attacks.
  • Encouraging these solutions may promote a false sense of security as organisations might believe that a WAF or RASP is the absolute solution.
  • Using cloud-based WAF technologies means that sensitive data is processed on servers outside of each organisation's control.

 

On the other hand, one could argue the following advantages of this being part of the new list:

  • Well configured and reputable WAF or RASP technologies can deter untargeted automated attacks or deter script kiddies from targeting the application and make them look for another target. Stopping automated fuzzing attacks would further increase the difficulty in discovering a complicated vulnerability.
  • This category stresses the importance of ensuring that such commercial security products are configured properly. We keep seeing more and more of our clients resorting to such solutions to further enhance the security of their applications, and it is very often the case that they are misconfigured. This category being part of OWASP Top 10 2017 could help ensure that such solutions are well configured.
  • Vendors offering such technologies have improved a lot in the past years making it more difficult for attackers to avoid being detected when sending malicious payloads to the applications.

 

As security consultants we need to be really careful on how we advise and educate our clients on this. WAF or RASP technologies add an additional security control in the web application. Having multiple layers of security controls in place is well-known tactic, often referred to as "Defense in Depth", which improves the overall security of the application. However, priority of the various layers matters and resolving the vulnerabilities in the actual code of the web applications is crucial. Solely relying on a WAF or RASP product for security could leave applications vulnerable for a period of time whenever bypasses for them are made publicly available. It is therefore our responsibility to guide organisations objectively and accurately in deciding the defensive approach they need to follow and setting priorities in order to ensure the applications are secure.

Organisations using WAF or RASP solutions should have change control procedures in place to ensure that these are configured properly and tested on staging environments to ensure they can be deployed on production systems without affecting the current functionality. In Dionach, we tend to look and report for WAF misconfigurations and bypasses to ensure organisations get the most out of such security products and improve their overall security.

Final Thoughts

Maintaining a list of the top ten web application vulnerabilities is not an easy task in the current rapidly evolving security universe and threat landscape. It is very difficult to include every major risk area from every viewpoint (large or small organisations, defensive or offensive) in such a short list and therefore OWASP is there to raise security awareness, promote the concept of secure development and improve the organisations' security posture. I can’t stress this enough but it is important for organisations to realise that any security issues not falling under the OWASP Top 10 list should not be ignored.

To sum up, OWASP is a standard that provides a common language between security consultants, developers and managers, something which is a necessity nowadays. It also serves its educational purposes well as it promotes strong concepts of secure development.

Finally, bear in mind that this is only a draft version and we may be seeing further changes taking places after the public comment period ends, on June 30th 2017.

Posted by Nick

Leave a comment