Cross Site Scripting - II



Cross Site Scripting - II

Persistent XSS Attack

In case of persistent attack, the code injected by the attacker will be stored in a secondary storage device (mostly on a database). The damage caused by Persistent attack is more than the non- persistent attack. Here we will see how to hijack other user‘s session by performing XSS.

Session

HTTP protocol is a stateless protocol, which means, it won‘t maintain any state with regard to
the request and response. All request and response are independent of each other. But most of the web application don‘t need this. Once the user has authenticated himself, the web server should not ask the username/password for the next request from the user. To do this, they need to maintain some kind of states between the web-browser and web-server which is done through the
―Sessions‖.



When the user login for the first time, a session ID will be created by the web server and it will be sent to the web-browser as ―cookie‖. All the sub-sequent request to the web server, will be based on the ―session id‖ in the cookie.

Examples for Persistent XSS Attack


This sample web application we‘ve given below that demonstrates the persistent XSS attack does
the following:

•     There are two types of users: ―Admin‖ and ―Normal‖ user.
•     When ―Admin‖ log-in, he can see the list of usernames. When ―Normal‖ users log-in, they can only update their display name.




0 comments:

Post a Comment