OWASP TOP 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Auditors often view an organization’s failure to address the OWASP Top 10 as an indication that it may be falling short with regards to compliance standards or best security practise.
In general, OWASP TOP 10 outlines the most recurring application security weakness in the application security domain. However, it seems that some trending application security weakness are not listed under current TOP 10 categories after managing two bug bounty programs in the past two years and working as bug hunter in my free time. SSRF ,Cache Poisoning and subdomain takeover are some of these trending vulnerabilities not included in the latest OWASP TOP 10. I believe these vulnerability should get some attentions from security engineers as they could lead to severe security incident.
Sever Side Request Forgery (SSRF)
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain (behind the WAF or internal domain) of the attacker’s choosing.
How SSRF vulnerability could be introduced in your application?
Most likely, SSRF could be introduce when a public facing application allows an end use to add a URL as a parameter. For example, an application allows a user to pull the content, metadata from another web page by inputting the URL of a web page. Or an application allows its users to define a web hook (URL) and the application will send a request to the web hook URL.
What is the impact of SSRF vulnerability?
The severity of impact of successfully exploiting a SSRF could vary a lot depending on how the application is configured or implemented. Sometimes, the SSRF could only be used to scan open ports or IPs of the internal hosts to fingerprint the intranet of an organization. However, sometimes, SSRF could lead to the leakage of sensitive tokens or credentials of your application if your application is powered by AWS, Google Cloud or Azure. The root cause of the recent Capital One data breach was AWS credentials leakage through an SSRF exploitation.
How could you prevent SSRF vulnerability?
Multiple countermeasures could be employed to combat against SSRF by considering the use case of the applications. For example, URL whitelisting or Network segregation are two popular methods to use. URL blacklisting should not be your first preference when remediating the SSRF vulnerability. In a private bug bounty program I joined, the application is using blacklist, like, localhost, 127.0.0.1 to prevent a request to the localhost. However, I was able to bypass it by using http://[::] and http://0.0.0.0/ to bypass the blacklisting. In most of the case, I think network segregation could be a good option if that is affordable for your application.
Web Cache Poisoning
Web cache poisoning is an advanced attacking technology where an attacker exploits the behavior of a web server by modifying web cache with some malicious data and harmful HTTP response containing these malicious cached data is served to other legitimate users.
Why your application could be victim of the web cache poisoning attack?
Some modern application are heavily using CDN web cache method to serve as many client requests as possible without having to retrieve the original content each time. Having a cache layer will significantly reduce the server load of the application. for CDN or web server, it is relying on using cache keys to look up whether a request is cached or not. If the application directly reflects the value of a certain unkeyed header in the response, it could be a good indicator that this application is vulnerable to cache poisoning. Because the header is unkeyed, its value is not part of the cache key and plays no part in deciding about cache hits. If the attacker sends a request where only this header is maliciously modified, the response to this request will be cached. Users subsequently requesting content that matches the same cache key will receive the malicious data injected by the attacker.
What is the impact of Cache Poisoning vulnerability?
The impact of web cache poisoning attack depends on what data could be cached with a crafted request from an attacker and the amount of the traffic on the affected page. Portswigger has a good explanation on the potential impact. If the home page of an organization is vulnerable to web cache poisoning attack, that will be a huge problem to the company as legitimate user will be not able to access the page normally.
How could you remediate web cache poisoning vulnerability?
There is no silver bullet to remove web cache poisoning issue as most applications using web cache has the requirement to use it to ensure a great user experience. One good method would be restrict the cache content to be something purely static.
Subdomain takeover
Subdomain takeover is another trending security issues prevailing in applications. According to portswigger, security researchers have discovered more than 400,000 subdomains with misconfigured CNAME records, leaving many at risk of malicious takeover as a result. The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.
How could subdomain takeover happen?
The subdomain takeover issue is always introduced by a human error or mistake. For example, you set up and add a DNS entry blog.example.com and CNAME to a 3rd Party domain, company1.bloghost.com. However, you forget to claim the ownership of the CNAME domain company1.bloghost.com, then an adversary claimed the CNAME domain company1.bloghost.com and hosting some malicious content. Another case would be, you are using AWS to power your application and you create a DNS entry blog.example.com and resolve it to an IP address AWS owned IP address 52.47.73.72 . However, you forget to reserve the IP. Then an attacker claim the ownership of that IP and host some malicious content. As a consequence, all the legitimate user visiting blog.example.com will get the malicious code executed in their browsers.
What is the impact of subdomain takeover?
The impact of subdomain takeover could be very severe. Attackers can then serve malicious content to visitors to the exploited subdomain, and potentially intercept internal emails, mount clickjacking attacks , hijack users’ sessions by abusing OAuth whitelisting, and abuse cross-origin resource sharing (CORS) to harvest sensitive information from authenticated users.
How could you prevent subdomain takeover?
Preventing subdomain takeovers is a matter of order of operations in lifecycle management for virtual hosts and DNS. Depending on the size of the organization, this may require communication and coordination across multiple departments, which can only increase the likelihood for a vulnerable misconfiguration.
Conclusion
With more and more applications are shifting to micro services and serverless platforms. SSRF, Web Cache Poisoning and Subdomain taken over will draw more attention and probably get more spotlights in the cyber security domains. That could explain why SSRF is highly proposed to be added in upcoming OWASP TOP 10 2021.