Testing for Session Fixation vulnerabilities The organisation is likely to suffer damage to their reputation and lose the trust of users who have had their accounts compromised by the attack. If administrator accounts are compromised using this vulnerability the attack could be used to make other attacks possible, such as altering the configuration of the application or extracting data from backend databases. In a more serious case, it could lead to the takeover of the victim’s account if the attacker is able to authenticate with the application using the stolen Session ID. At a minimum, a successfully exploited Session Fixation could lead to a loss of privacy allowing the attacker to obtain sensitive information entered into the application by the victim. The impact to the victim of the attack and the owners of the website will vary, depending on the type of application and the nature of the data stored within the compromised user session. It’s worth noting that there may even be no need for the user to actually log into the vulnerable application, as simply browsing through public areas on some websites may be enough to leak sensitive information to the attacker, such as shopping cart contents or credit card details filled in during the compromised session. This takes advantage of the fact that web browsers will send wildcard cookies to any subdomain of the site which set them. In a variation of the attack, the attacker could make use of subdomains under the target domain which they control, to allow them to set a wildcard cookie after tricking the user into accessing a malicious link. The attacker only needs to extract the Session ID from their own cookie before sending it to the user: Many developers think that simply using server-generated Session IDs is enough to prevent Session Fixation attacks however, the example in the following diagram shows that this is not the case. The attacker is then able to carry out actions in the application as if they were the victim by passing the compromised Session ID along with their requests. The server accepts the Session ID, and populates the session with information about the authenticated user. A typical scenario involves the attacker prompting their victim into clicking on a link which directs them to sign in, while also supplying a Session ID.
The attacker is able to fool the vulnerable application into treating their malicious requests as if they were being made by the legitimate owner of the session. In a Session Fixation attack, a victim is tricked into using a particular Session ID which is known to the attacker.
Data that’s held in sessions often includes sensitive items, such as: shopping cart contents, identity information and authorisation levels.
This is called the user’s ‘Session’.Įach Session consists of data held on the server which is associated with a Session ID of some kind, which is passed by the user’s browser with each HTTP request. The problem is that most web applications need to keep track of user’s actions across multiple requests, and remember certain information about the user while they are active. The HTTP protocol that is used by web-based applications is designed to be ‘stateless’, meaning that each request handled by the server is processed individually and is not treated as being related to previous requests. This attack differs from Session Hijacking, in the fact that the Session ID is previously known to the attacker and is forced onto the victim, as opposed to the attacker discovering the token through another vulnerability. When the victim makes use of the known Session ID in their requests to a vulnerable application, the attacker is able to exploit this vulnerability to make their own requests using the same Session ID – carrying out actions as if they were the legitimate owner of the Session. Session Fixation is a type of attack on web application users where an attacker is able to trick a victim into using a Session ID which is previously known to them.
0 kommentar(er)
