| meta name=”description” content=”<script>alert(1)</script>”> |
Test SSRF vulnerability by setting a redirection URL to
http://169.254.169.254/latest/meta-data/iam/security-credentials/
TestSSRF
Leave a reply
Author Archives: dingjiedanielyang@gmail.com
ssrf
Using HTML Entity Encode to mitigate XSS vulnerability, then double check it
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 <img src=x onerror=alert(1)> 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
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/
- CSRF : Login and Logout the victim
- IFrame : Frame the page to abtain useful information of the victim
- CSP absue : Keep part of the victim’s Session by using CSP rule
- 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
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.
In 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
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
Join EBAY Hall of Fame
Ebay add me in its hall of fame after I reporting a clickjacking related issue for them
http://pages.ebay.com/securitycenter/ResearchersAcknowledgement.html
Exploit XSS in <link rel=’canonical’> when characters < and > are filterred
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="<qss>' />
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
Exploit XSS in hidden input field
Burp team found a new way to exploit XSS in hidden input fields. The key point is to use accesskey attribute to trigger the onclick event!
<input type=”hidden” accesskey=”X” onclick=”alert(1)”>
Details could be found at http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.htm
How Open Redirection Threatens Your Web Applications
Open redirection is listed in the OWASP Top 10 for 2013 and 2010 (10th position in both lists) since it is still an active threat in modern web applications. Open redirection occurs when a vulnerable web page is redirected to an untrusted and malicious page that may compromise the user. Open redirection attacks usually come with a phishing attack because the modified vulnerable link is identical to the original site, which increases the likelihood of success for the phishing attack.
While open redirection is not exactly common, my research was able to uncover several open source applications that were vulnerable. In this article, I describe the results of my research, and some recommendations for avoiding open redirection vulnerabilities in your code.
Vulnerability Found and Fixed in Moodle
Six months ago when I was evaluating the popular open source learning management software Moodle, I discovered an open redirect vulnerability caused by a lack of constraints on the referer parameter. This vulnerability could redirect users to a non-local website and launch a phishing attack. It has been fixed (by adding code to replace the referer with a local URI when the referer value was used as a redirection vector), and the detail has been listed in CVE-2015-3175 and MSA-15-0019.
Proof of Concept
GET /moodle/mod/forum/post.php?forum=1 HTTP/1.1
Host: Yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.qualys.com
Connection: keep-alive
By make the request and clicking the “cancel” button in the response page, the user will be redirected to https://www.qualys.com. By taking advantage of this vulnerability, an attacker could launch a phishing attack there very easily.
Research Uncovered More Vulnerable Applications
After submitting this issue and getting it accepted by the Moodle developer team, I decided to commit some time to check whether open redirection is a popular and underlying threat that could damage modern web applications.
I conducted some pen tests against some popular web sites as well as some web applications in a bounty list.
After conducting research off-and-on for several months, the results are bittersweet. The good news is that most web applications are deployed with some input validation to block redirection to a different domain when there are users’ input requiring a URL value. However, some web applications do not implement the countermeasure correctly or they do not protect against open redirection at all, which leaves them vulnerable.
More details could be found at Qualys Community blog