Author Archives: dingjiedanielyang@gmail.com

Trending Application Vulnerabilities not listed under OWASP TOP 10

Leave a reply

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.

Using HTML Entity Encode to mitigate XSS vulnerability, then double check it

Leave a reply

HTML Entity Encode (HTML Encoding) is a commonly deployed escaping/encoding method to mitigate XSS vulnerability as consciousness of XSS is growing.  A very big portion of web applications are using HTML Entity Encoding to handle untrusted data, and this method is robust enough to protect them from XSS attack for most of the time. However, under some situation, you might still expose your web applications under XSS attack even though HTML entity Encoding is implemented.  

A real world example

Following example is a mock up from one client website (the original web application is a single page application where JavaScript Code is heavily implemented), where HTML Entity Encode was deployed but failed to eliminate the XSS vulnerability. Supposed the vulnerable URL is http://www.example/test.jsp?query=userinput and injection point is the query parameter.  After sending a request to it under a modern web browser, the source code looks like,

htmlencode is a customized function on the server side to apply HTML encodings to specified string in order to combat  XSS vulnerability. The above snippet shows two piece of information a) The user input value is HTML encoded and reflected in the response under one <input> field, b) The html encode value was then assigned to innerHTML attribute of  an element when the page is loaded.

HTML Entity Encode is not sufficient here

At the first glance, it seems the mitigation method is robust enough because the user input is HTML encoded correctly and encapsulated under a double quote.   Whereas, it turns out this web application is still bearing XSS vulnerability with it.

When an attacking vector with malicious code http://www.example/test.jsp?query=<img src=x onerror=alert(1)> is requested in a web browser, malicious code <img src=x onerror=alert(1)> is still  parsed by the web browser  and the inherent JavaScript code is executed even though the user input value  is HTML encoded as &lt;img src=x onerror=alert(1)&gt; in the response page  .

What is behind this scenario?

In order to get a closer look to the problem, we might start to analyze the source code of the response from the request with attacking vector.

<body onload=”myFunction()”>

JavaScript code document.getElementById(“search_result”).innerHTML=document.getElementById(“query”).value; is the culprit that spoils the HTML Entity Encode method.  When HTML parser (HTML parse is one of the most complicated and important components of a web browser, it controls how your raw html source code is turned into web pages) runs and builds up the response page for the first time, the attribute value entity <img src=x onerror=alert(1)>in the input field will  be decoded when the html parsers is parsing the value attribute. Though it is decoded at this step, it is not intercepted as HTML content yet. Later, the decoded value is passed to the innerHTML and it will be intercepted as HTML content because the innerHTML indicated the HTML parser to parse it as HTML format content.  In short, the html encoding value in the input field is parsed twice. As a consequence, the injected malicious code will be executed in the web browser and leads to XSS attacks.

Same Flaws observed in some open source web applications

After conducting research on some open source web applications by using Qualys Web Application Scanner,  WAS detected similar XSS vulnerability in some open source web applications even though HTML Entity Encode is applied. The following pattern was observed among these vulnerability where HTML Entity Encode is used.

<input  onfocus=”JavaScriptCodehtmlencode(userinput)JavaSctiptCode” >

In the pattern, the user input is HTML Entity encoded and reflected in the event handler (onfocus is one of the event handlers).  Similar to the scenarios discussed at the beginning, the HTML Entity Encoding is defeated because web browser (actually it is the HTML parser) will HTML decode the value of the event handle before it is executed as JavaScript code.

Conclusion

This example is not a rare or special case. Especially, while building single pages applications is trendy and considered a modern web development practice, it is common to see HTML encoded user input value is reused in a single page.  For web developers and security engineers, it is important to bear in mind that HTML parsing is a very tricky work. When HTML Entity Encode method is used to handle untrusted data, you should not only check whether the encoded user input value is placed correctly in the response, but also pay attention on the whole context of the page.

How to turn Self-XSS into Good XSS

Leave a reply

I am participating in bug bounty programs in the past several years (Apparently my activity on the bug bounty slowed down in the past two years),  I was in fight with a lot of developers to convince  them that they should fix self-exploit XSS vulnerability because of the discrimination they have against self-cross-site scripting.

However, in the past two years,  several researchers demonstrate how to turn slef-xss vulnerability into Good XSS vulnerability and exploit them.  These demonstrations give a bunch of insight for search research on how to exploit self-xss vulnerability by leveraging some trivial security issues.  These for sure would help some developer to understand they should treat slef-exploit xss vulnerability more seriously.

By referring to a list of POCs for exploiting self-xss vulnerability

https://whitton.io/articles/uber-turning-self-xss-into-good-xss/

https://medium.com/@bugbsurveys/self-xss-and-vol2-1b5049e59ae6

http://ashishpathaksec.blogspot.com/2015/06/how-i-convert-self-xss-into-stored-xss.html

http://www.ninoishere.com/airbnb-bug-bounty-turning-self-xss-into-good-xss-2/

  1.  CSRF             :    Login and Logout the victim
  2.  IFrame         :    Frame the page to abtain useful information of the victim
  3.  CSP absue   : Keep part of the victim’s Session by using CSP rule
  4. X-Frame-Options: Abuse same-origin policy. Top window has access to the iframe information, which allows an attacker to get the useful inforamtion, such as CSRF tokens.

To summarize if up,  here is the steps to exploit self-xss vulnerability

Step 1:   Attacker Login and plant XSS codes 

Step 2:  Vitcm to loign to attacker’s acount via CSRF

Step 3:  Victim execute the XSS codes

Step 4:  XSS codes got performed in the Iframe.   This steps could be tricky it all depends of how the authentication process is implemented.  The steps will involve how to switch the victim to Login to their own accounts by using iframe.s

 

 

 

 

Handling Cross-Site Scripting As Attacks Get More Sophisticated

Leave a reply

Adopting third-party libraries to encode user input in the development phase and using a web application firewall in the deployment phase could fool web security managers into thinking their web applications are completely safe from Cross-Site Scripting (XSS) attacks. While it’s a good idea to employ these techniques, the illusion of safety could prove costly. These protection methods do not guarantee that your web applications are 100% free of XSS vulnerabilities, and XSS attacks that use more sophisticated techniques still occur, so care should still be taken.

Webappsec imageIn the past several months, Yahoo and Facebook patched two critical XSS vulnerabilities.  These clearly show XSS vulnerabilities continue to occur in modern and mature web applications, even for Internet companies. The XSS vulnerability in Yahoo email was straightforward: the input validation was not robust enough to escape malicious code, and the attacker was able to break input validation. The one patched by Facebook was a little trickier because it exploited a bug in the file upload function to upload malicious JavaScript code and then invoked the code by calling it from a different application. Just this week as I was finishing this blog post, an insufficient input validation XSS vulnerability was disclosed in the popular WordPress pluginNinjaForm.

As I have observed from my work experience and as a bug bounty hunter, XSS vulnerabilities are definitely not going away — and many attacks are getting more sophisticated. The golden age of penetration testing, when pen testers could discover XSS vulnerabilities simply by inputting malicious code into a search box, is over. It often takes more skill and effort for webmasters to discover the XSS vulnerabilities they need to protect against.

XSS Hidden by Web Application Firewalls

Web application firewalls (WAFs) are commonly used to protect web applications. They are indeed effective in blocking a large number of web attacks. Some pen testers give up immediately when they determine the web application is deployed behind a web application firewall. However, a WAF is just like a cast that by itself does not fix the broken limb. And like a cast, a WAF is best used as a temporary protection until the underlying issue, in this case a coding error, is fixed and redeployed.

Instead of fixing the issue, WAFs just hide XSS vulnerabilities and makes it harder for attackers to exploit them, which is their purpose; but WAFs also makes it more difficult for penetration testers or automatic scanners to discover these vulnerabilities. According to the research, over 70% of existing WAF rulesets can be bypassed through XSS obfuscation techniques. As a rule-based tool, WAFs trap the main cases for which rules are defined, but not all of the corner cases — the development effort spent to make the perfect ruleset would be better spent fixing the underlying coding error.

Recommendation: When running a security audit, e.g. via automated tools or penetration tests, always disable your WAF so that the XSS vulnerabilities can be discovered to the greatest extent. You want to make it easy on yourself to find XSS vulnerabilities, so you can fix them in your code.

In my work, I have seen many examples where customers claimed that Qualys Web Application Scanning (WAS) had generated false positives, when in fact they were true positives but the customer didn’t see the exploit because they were protected by a WAF. In these cases, I could often exploit the XSS anyway by coding exploits that bypassed the WAF protection.

Example: Methods to bypass WAF could be found on the Internet: Using escape sequences (%00onload%00=%00) instead of regular text; or an alternative XSS method, such as, payload document.body.outerHTML=maliciouscodes could be used to break some WAFs.

More Sophisticated XSS Attacks

Three types of sophisticated XSS attacks are difficult for pen testers and tools to discover. It is not easy to propose new techniques to combat these, except enhancing security implementation during web development and employing a DAST (dynamic application security testing) tool for regular security audits to make sure you catch any that were inadvertently included in your code.

DOM-Based XSS

Attacks against DOM-Based (Direct Object Model) XSS vulnerabilities modify the client side DOM tree in the victim’s browsers and run malicious code; as opposed to a traditional XSS vulnerability which exploits the server side code. DOM-based XSS vulnerabilities are harder to detect than the traditional XSS vulnerability because they resides in the script code from the website and the injection payloads are not reflected directly in the response. It has been estimated that 30% of XSS attacks on live websites are XSS inside JavaScript code and cannot be blocked by a WAF. Due to the difficulty of discovering them, DOM-based XSS vulnerabilities become a blind spot for many scanning tools and penetration tests.

Example: Here is the normal format of a DOM-based XSS attack vector

http://www.some.site/page.html#name=<Malicious-JavaScript-Code>

Multiple Step XSS

Multiple Step XSS vulnerabilities require the user to perform several actions on the applications to execute the attack vector/injected malicious JavaScript code. The main characteristics of multiple step XSS vulnerabilities are that the attack vector is injected in one page and then echoed in another page or application later. Due to this factor, it creates a challenge for penetration tests or ordinary DAST tools to identify this kind of vulnerability.

Example: Qualys WAS reported a XSS vulnerability in a customer’s application. The customer’s security team claimed they could not find the injection point and wanted to flag it as a false positive. After investigation, we found the injection point was from a different subdomain and the malicious code was invoked by making a search with a keyword matching with the malicious code injected in the response.

Path-Based XSS

Targets for Path-Based XSS attacks are applications where the request URLs are rendered directly in the response body without proper encoding or input validation. The following source code snippet is a model demonstrating how path-based XSS vulnerabilities reside in your web applications.

<a href=" <?php echo $_SERVER['REQUEST_URI'];?>">Click Here</a>

Example: Path-Based XSS vulnerabilities are a special breed but it is not rare. I have discovered path based XSS vulnerability in PHPBB3 and some other open source web applications. Meanwhile, multiple path-based XSS vulnerabilities were flagged in our clients’ web applications. The attack vector looks like:https://example.com/public/<Malicious JavaScript Code>/directory1

Conclusion

While WAFs are a great protection measure against attacks on vulnerabilities resulting from coding errors that you have not yet fixed and deployed, you should always disable WAFs for internal testing. This helps ensure you don’t inadvertently overlook any simple XSS vulnerabilities in your code. It’s always safer to fix the underlying vulnerability than to rely on a WAF for long-term protection.

In addition, developers should take care in their coding to look for the more subtle XSS vulnerabilities, since we are regularly finding attacks that try to exploit these.

How Ignoring Low-Level Security Risks Can Open the Door to Major Attacks

Leave a reply

With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.

Three low level issues discovered in MyBB

In a recent audit of MyBB, I found three low-level security issues which, if exploited in aggregate, could allow a hacker to gain total control of this open source application which people use to create discussion forums. The issue has been partially addressed in its latest version — MyBB 1.8.7 – so users are no longer vulnerable to the danger described here.

Continue Reading at Qualys Community Blog

Exploit XSS in <link rel=’canonical’> when characters < and > are filterred

Leave a reply

In one of our customer’s website, the injection point is in <link rel=’canonical’ href=”> tag and it looks like something like

 <link rel=’cannoical’ href=’http://example.com/test.php?pid=<?php echo $_SERVER[‘QUERY_STRING’];>’>

The server will encode <, > and “, if you try http://example.com/test.php?pid=”<qss>, the response will be

<link rel="canonical" href='http://example.com/test.php?pid=&quot;&lt;qss&gt;' />

Under this case, using the following payload, you could exploit this XSS under IE7  and IE 8.

http://example.com/test.php?pid=’style=’x:expression(alert(document.cookie))’ t