There was a recent article about a GoDaddy vulnerability deemed Blind XSS. Now many of you may have heard of Blind SQL Injection, where an attacker can extract answers and data out of a database not by straight-forward SQL select statements, but instead essentially based on the website's response to true/false questions/queries. It can be a slow and painful process, sometimes extracting data one bit at a time, but none-the-less effective if you end up extracting the data you wanted.
Blind XSS, on the other hand, is nothing of the like. The term they're referring to here is essentially a ticking time bomb. They dump malicious XSS payloads anywhere and everywhere, hoping that somewhere, somehow, someday a website/application will open that payload in a browser from a vulnerable website. That might be difficult to make sense of at first, but I'll give some better examples below to illustrate what they mean. I have discussed this topic a little bit before in my prior blog XSS is worse than you think.
Now normally as an attacker you probably submit a simple test alert textbox XSS payload into a textbox, parameter, etc. and hope for immediate feedback. You either see reflected XSS returned in the HTTP response immediately, or you see your stored XSS show up on a different page when the website loads your content. But imagine another interesting method of attack. Why not just spam EVERY SINGLE input field like textboxes, query string parameters, etc. on a website with your desired payload (something that makes a callback and hooks a browser), then instead of checking for immediate feedback, just sit back and wait for the callback to occur. This callback could occur immediately, but it's also possible it takes hours, days, or even weeks for the callback to occur. Why?
What if you one of your payloads actually stuck. Perhaps it was a stored XSS vulnerability and it got stored into a database table. Here's a few examples I image this could apply
1.) What if your payload got saved into your Security Question / Answer field. The XSS payload does not work when you view your my account area because that public facing site was well-coded. But imagine you make a phone call to customer support, and the first thing customer support does it open your my account from their Internal, less secure Intranet website to validate your security question. This less secure Intranet site opens that same Security Question / Answer field and suddenly your payload is delivered to the customer support rep! And you see your callback come in and hook their browser. Blind XSS.
2.) What if your payload got saved into the product review comments on an ecommerce site like Amazon. Your payload does not work when the comment is displayed on the Amazon product page because that public portion is well-coded. But comments can go through an actual manual-review process by employees in order to validate your comment isn't spam, etc. Imagine the employee opens up your comment from their less secure Intranet website to approve or disapprove it. When they open up your comment in their less secure Intranet app that isn't checking for XSS, your malicious payload is delivered to that employee's browser. Hooked. Blind XSS.
It's a crap shoot. It's spray and pray. But it can be effective. It works for email spammers & phishers. They blast out their "payload", a malicious email, to thousands of email accounts knowing that a small handful will actually have their payload delivered and gain successful compromise of the victim. They weren't sure who the victim would but it doesn't matter, they're now the victim.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thank you for the update, very nice site.. Security Report
ReplyDelete