Apparently there’s nothing technical on this blog since last March. I really have nothing interesting to talk about, save for a weird XSS I found somewhere near September, and that is a bit more disappointing to me than it is to you.
Let’s get things started again, so to speak, by writing about that.
Imagine a simple online banking page: After logging in, this page allows you to perform certain transactions, and it allows you to write a short comment for each transaction (let’s assume it’s for convenience - maybe you want to keep a short note about what kind of transaction required you to transfer $500 today, or whatever). The length of each comment is limited to ~20 characters, or any arbitrary amount you can think of.
As long as you are logged on to the application, you can perform transactions, and after
each one you will be presented with a confirmation page which lists, among other things,
your supplied comment, as well as an informative page after the transaction is accepted,
which also lists the same information. As any conscious security person would do, you
would try to check for the obvious issue, a cross-site scripting issue, by supplying
appropriate input on the comment field. The result was correctly filtered and/or escaped
by the application server, and your attempts would be in vain, further affirming your
trust on your ${BANK}.
Try and log out, however, and you’re presented with the most curious thing: a short “history” of all transactions you’ve committed during the previous session, along with the short comment for each one, presented in a neat and tidy little HTML table. As the security-conscious people we are, we check the page source, and find out that this output is not escaped and/or filtered in the same manner as the previous pages!
We may have a problem.
I say “may”, because the usual PoC payloads for cross-site scripting issues don’t fit into the little comment space. Trying to supply contents past the limit shows us that the server truncates our input, thwarting our attempts at misbehaviour. But wait! Didn’t we just see that output on the log out page isn’t properly escaped? What does that mean? It means that the contents of each little comment are treated & presented as HTML, with apparently no discernible attempts at sanitization.
Are you pondering what I’m pondering?
Uh, I think so, but balancing a family and a career … ooh, it’s all too much for me.
Instead, let’s try to insert less-than signs (>) to close HTML tags and supply our XSS
PoC in multiple parts. Since all (actually, up to 5, which were more than enough)
transaction comments are presented in the page, we should have enough space to deliver our
“exploit”. The structure of it, in its parts, would look something like this (skipping the
special character encoding that was actually used as it’s not really relevant):
--><script>alert(<!--
-->document.cooki<!--
-->e);</script>What happens as a result of the way the logout page displays comments, is that all
sections of HTML between our supplied input is commented out (<!--, -->), allowing us
to execute valid Javascript in a very neat stored XSS.
The real issue wasn’t at all interesting, in terms of impact: the only one who can supply crafted Javascript inside the comments is the logged-in user themselves, and their history is not presented to anybody else. Additionally, after logging out, all cookies and other potentially sensitive information was cleared, and not accessible to an attacker.
Here’s to yet another curious technicality with no real world applicability! :-)
« Past Future »