Session fixation vulnerabilities occur when:
A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.
Summary :-
When an application does not renew its session cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).
Anatomy of a Session Fixation Attack :-
Step I :- Here is the request to the banking application
Step II :- The response from the application sets a cookie in the browser
Step III :- Modify the Session Id value in the Set-Cookie function. This will cause all of the subsequent requests from the browser to contain the modified Session Id.
Step IV :- Now when the same modified Session Id is sent in the request when the user tries to log into the application.
Step V :- Login successful with user supplied Session Id
The vulnerability has been reported to the bank, hope their response is quick.
A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.
Summary :-
When an application does not renew its session cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).
Anatomy of a Session Fixation Attack :-
Step I :- Here is the request to the banking application
Step II :- The response from the application sets a cookie in the browser
Step III :- Modify the Session Id value in the Set-Cookie function. This will cause all of the subsequent requests from the browser to contain the modified Session Id.
Step IV :- Now when the same modified Session Id is sent in the request when the user tries to log into the application.
Step V :- Login successful with user supplied Session Id
The vulnerability has been reported to the bank, hope their response is quick.
No comments:
Post a Comment