HomeTechNoteAdvanced XSS methods and how to prevent – part 1
Advanced XSS methods and how to prevent – part 1
August 18, 2014
“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
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’] =
– 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)
Often requires Parameter Tampering
Rather than stealing the user’s Session ID, we trick them into submitting requests on our behalf
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!