login

Burp Suite, the leading toolkit for web application security testing

PortSwigger Web Security Blog

Monday, 23 July 2007

Hacking without credentials

It is common to be faced with a web application where you have no credentials to log in. Very often, the application contains a wealth of functionality that can be accessed without authentication and which you can start working on to find a way in. Typically, the most promising initial targets are the more peripheral functions supporting the authentication logic, like user registration, password change and account recovery.

But occasionally you will face a narrower challenge. Suppose the web root of the server returns a simple login form, with no other functions and no links anywhere else. You can try to guess a username and password, but is that all?

Here are just a few of the things to think about in this restricted situation:

  • Looking for names, email addresses and other information in the HTML source.

  • Fingerprinting the web server software, application platform and any other identifiable technologies in use, and researching these for vulnerabilities.

  • Enumerating the content that is currently hidden, by brute forcing file and directory names, running Nikto, etc., and checking whether the content discovered is properly access controlled.

  • Checking search engines and Internet archives for references to the target.

  • Tampering with any hidden parameters and cookies in the login request that may affect server-side logic.

  • Checking for any disabled form elements that may still be processed if you re-enable them.

  • Adding common debug parameters (like test=true) to your request.

  • Inspecting the ASP.NET ViewState (if present).

  • Testing for username enumeration via informative failed login messages or other differences.

  • Testing susceptibility to brute force attacks.

  • If the application issues session tokens prior to login, testing these for predictability.

  • Testing all request parameters and headers for common code-level flaws like SQL injection, XSS, script inclusion, etc.

  • Probing for logic flaws within the login function, by omitting parameters, interfering with the request sequence if multi-stage, etc.

  • If the application is hosted in a shared environment, looking for co-hosted applications that you may be able to leverage to attack your target.

Any one of these attacks might give you a sufficient foot in the door to get past the login and into the protected functionality behind it. If they do not, then the login mechanism is a lot more robust than most are, and it is probably time to try to get hold of credentials, or move on to another target.

No comments:


User Forum

Get help from other users, at the Burp Suite User Forum:

Visit the forum ›

Copyright 2014 PortSwigger Ltd. All rights reserved.