Brutehttp//www.victim.com/private/index.html, an attacker can generate base 64 encoded strings with commonly used usernames and a password, generate HTTP requests, and look for a non-404 response:
| Attack Methods | Session Replay If a user's authentication tokens are captured or intercepted by an attacker, the session can be replayed by the attacker, making the concerned web application vulnerable to a replay attack. In a replay attack, an attacker openly uses the captured or intercepted authentication tokens such as a cookie to create or obtain service from the victim's account; thereby bypassing normal user authentication methods. |
A simple example is sniffing a URL with a session ID string and pasting it back into the attacker's web browser. The legitimate user may not necessarily need to be logged into the application at the time of the replay attack. While it is generally that username/password pairs are indeed authentication data and therefore sensitive, it is not generally understood that these generated authentication tokens are also just as sensitive. Many users who may have extremely hard-to-guess passwords are careless with the protection of cookies and session information that can be just as easily used to access their accounts in a replay attack. This is often considered forging "entity authentication" since most applications check the tokens stored in the browser or HTTP stream, and do not require user authentication after each web request.
By simply sniffing the HTTP request of an active session or capturing a desktop user's cookie files, a replay attack can be very easily performed. Exploitation can take the following general forms:
-
Visiting a pre-existing dynamically created URL that is assigned to a specific user's account which has been sniffed or captured from a proxy server log
-
Visiting a specific URL with a preloaded authentication token (cookie, HTTP header value, etc.) captured from a legitimate user
-
A combination of 1 and 2.
Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server. To prevent Session Hijacking and Brute Force attacks from occurring to an active session, the HTTP server can seamlessly expire and regenerate tokens to give an attacker a smaller window of time for replay exploitation of each legitimate token. Token expiration can be performed based on number of requests or time.
| Attack Methods | Session Forging/Brute-Forcing Detection and/or Lockout Many websites have prohibitions against unrestrained password guessing (e.g., it can temporarily lock the account or stop listening to the IP address). With regard to session token brute-force attacks, an attacker can probably try hundreds or thousands of session tokens embedded in a legitimate URL or cookie for example without a single complaint from the HTTP server. Many intrusion-detection systems do look for this type of attack; penetration tests also often overlook this weakness in web e-commerce systems. Designers can use "booby trapped" session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. Anomaly/misuse detection hooks can also be built in to detect if an authenticated user tries to manipulate their token to gain elevated privileges. |
| Attack Methods | Session Re-Authentication Critical user actions such as money transfer or significant purchase decisions should require the user to re-authenticate or be reissued another session token immediately prior to significant actions. Developers can also somewhat segment data and user actions to the extent where reauthentication is required upon crossing certain "boundaries" to prevent some types of cross-site scripting attacks that exploit user accounts. |
| Attack Methods | Session Token Transmission If a session token is captured in transit through network interception, a web application account is then prone to a replay or hijacking attack. Typical web encryption technologies include but are not limited to Secure Sockets Layer (SSLv2/v3) and Transport Layer Security (TLS v1) protocols in order to safeguard the state mechanism token. |
| Attack Methods | Session Tokens on Logout With the popularity of Internet Kiosks and shared computing environments on the rise, session tokens take on a new risk. A browser only destroys session cookies when the browser thread is torn down. Most Internet kiosks maintain the same browser thread. It is recommended to overwrite session cookies when the user logs out of the application. |
| Attack Methods | 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. |
-
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 (e.g. guest book, banner, etc,) and make it load automatically without requiring user intervention.
| Attack Methods | It is a fact that most web sites address security using SSL for authenticating their login sessions. Let us see how this process takes place. When the client connects to a web site two events take place to ensure security. |
-
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; s/he can be assured that the web site is what it claims to be.
Once the web site is authenticated by the user, he 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 self to the web site
The user provides his 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" - i.e. 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 opt 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 (which supersedes RFC 2109), 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 four individual cookies types.
-
Persistent and Secure
-
Persistent and Non-Secure
-
Non-Persistent and Secure
-
Non-Persistent and Non-Secure
0 Visitor Reactions & Comments:
Post a Comment