There are numerous ways to exploit authentication vulnerabilities in web apps. Some examples include:

  • Cracking credentials: Many of the password cracking techniques and tools you've encountered can also apply to web apps. Apps that fail to enforce strong password policies will make it easier for you to conduct brute force cracking. Some web app environments will also include default credentials for users like the administrator. The app developers might forget to change these default credentials, enabling you to sign in without conducting an intensive brute force cracking campaign. In some cases, you may also be able to dump the database with users' hashed credentials, enabling you to perform offline cracking using wordlists or lookup tables.
  • Session hijacking: Users are assigned session identifiers through web cookies so that they can be authenticated to the web app and so that the app can validate their privileges. If you manage to steal a user's session identifier, you may be able to take over that session and assume the user's privileges by sending the identifier to the server from your attack machine. You could steal the (unencrypted) cookie by sniffing it over a network, using cross-site scripting to expose the identifier, etc.
  • Redirecting: Standard redirect attacks involve exploiting poor input validation by appending a URL request to the legitimate website, e.g., http://site.example/login?url=http://malice.example. This is commonly used in phishing attempts, where the user recognizes and trusts the legitimate site but does not realize that the link will redirect them to your malicious site. So, on your malicious site, you could set up a login page that looks similar to the real thing, and the user might start inputting their credentials.

A more advanced redirect attack involves exploiting the returnUrl parameter in Microsoft's ASP.NET web app framework. This parameter is used in instances where a user tries to access a legitimate page requiring authentication, but their authentication cookie has either expired or needs to be generated. The user is directed to the legitimate site's default login page, and if they successfully log in, they are then sent back to the page they were originally trying to access—the page supplied in the returnUrl parameter.

Example Attack Process

An example attack process that leverages this feature is as follows:

  1. You send a phishing email to a user with this HTML markup: <a href="http://mybank.example/login?returnUrl=http://my.bank.example/login">Click here to sign in.</a>

Note that http://mybank.example is the legitimate site, and http://my.bank.example is the pharming site that you own and have made to look like the real thing.

  1. The user clicks the link and is taken to the legitimate http://mybank.example.
  2. The user enters their credentials and is authenticated with the legitimate site.
  3. The legitimate site redirects the user to http://my.bank.example/login, and this is all that is displayed in the URL bar in the user's browser.
  4. The malicious page has been set up to look identical to the same legitimate login page where the user just was. This page, however, tells the user that their login was unsuccessful and that they need to try again.
  5. The user inputs their credentials, unaware they are on the malicious page.
  6. The malicious page steals the user's credentials, then sends the user to the legitimate http://mybank.example/dashboard page.
  7. The legitimate site has already authenticated the user, so the user can access this page and do their banking as if nothing happened.