Advanced XSS methods and how to prevent – part 1

“Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypassaccess controls such as the same origin policy”.

XSS now as the most popular method to attacking websites by now. Why XSS so dangerous, how they did and how to prevent this? I will show you now.

In this article, i will show you some common methods of XSS to attack a website like: Parameter Tampering, Cross-Site Request Forgery (CSRF)

Parameter Tampering-Change parameters in a request

– Examine how the request is constructed
– Change the query string accordingly

Example: Bank Account Transfers

  • transfer.php?to_id=81&from_id=12&amt=10
  • transfer.php?to_id=12&from_id=1&amt=5000

This should look familiar so far…
– We went over how to prevent this in lab -Using $_SESSION variables, we can make sure the user really has permission to do this user really has permission to do this

– …but we can do this using POST, too!
– Create a form locally, set action to the target sit

– Use Web Developer to edit the form in place


Call session_start() on login…
-$_SESSION[‘user_id’] = 12

-$_SESSION[‘username’] = foo

On each page the user needs to be logged in…

On each page the user needs to be logged in…
-Make sure these $_SESSION vars are set

-Make sure they match the user in question

-If not, refuse the request

Example: Bank Transfer, Revisited
-Attacker’s $_SESSION[‘user_id’] =

– transfer.php?to_id=12&from_id=

– from_id does not match $_SESSION[‘user_id’]

– Attacker is logged out

Call session_destroy() to clear session data whenever a user logs out!

Works the same for GET and POST requests

Cross-Site Request Forgery (CSRF)

  • Pronounced “Sea-Surf”
  • Often requires Parameter Tampering
  • Rather than stealing the user’s Session ID, we trick them into submitting requests on our behalf
  • Consider the bank transfer example again…
  • Example: Bank Transfer, Revisited (Again)
    – Attacker’s user_id = 12
    – Victim’s user_id = 42
  • Attacker tricks the user into following this link:
    – transfer.php?to_id=12&from_id=42&amt=5000
    – Victim’s user_id matches match the from_id, so it’s works
    – The software has no way of telling that the  user didn’t mean to transfer the money!
  • Solution: Generate a random “token” (string) at each page, and expect the user to reply with the same token
  • We use our session to remember which token we’re expecting next, before sending it out
  • Because this is pseudo-random, the attacker will have to guess what the token is when providing a link for the victim to click
  • transfer.php
    – If $_GET[‘t’] != $_SESSION[‘token’], forged request
    – $_SESSION[‘token’] = md5(rand(1,100000000));
    – Add “&t=<?php echo $_SESSION[‘token’]?>” to the end of all links
  • This way, the user will always know which token to send next, but the attacker will have to guess!



Add a Comment

Scroll Up