Advanced XSS methods and how to prevent – part 1

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

Solution:

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!

Reference

http://en.wikipedia.org/wiki/Cross-site_scripting

http://itws2110.davidwatson.name/sites/default/files/lec20_security.pdf