8 Ways Your Website Could Be Leaking Login IDs

Thursday, July 21st, 2011

A leaky faucetHackers frequently gain access to computers and applications using compromised usernames and passwords. While phishing attacks account for a large percentage of compromised accounts, there are other techniques employed by attackers to identify valid login IDs for use in password guessing attacks. Here are eight ways that your website could be leaking login IDs…

  1. File  metadata – Files created by desktop applications often include metadata that describes the file and the environment in which it was created. The metadata can include usernames, network paths, software versions, and more. Using a metadata extraction utility, an attacker can build a list of usernames from the files stored on your website. For more information, check out our recent blog post on metadata extraction - Metadata Extraction – Is Your Website Leaking Information?
  2. User home directories – Many web servers, such as Apache, can be configured to allow personal web pages within user home directories. To access a user’s personal web page, you would enter the corresponding username preceded by a tilde (for example, http://www.domain.com/~asmith/ for the username asmith). When requesting a home directory, the web server will likely respond in one of four ways: 1) with the user’s personal page, 2) with a directory listing containing the contents of the user’s home/web directory, 3) with an HTTP 403 Forbidden, or 4) with an HTTP 404 Not Found. The presence of a personal web page, directory listing, or HTTP 403 Forbidden response indicates a valid username.
  3. Email addresses – Spammers use automated applications known as spambots to scour websites for email addresses. An attacker can use this same technique to identify possible usernames. This is especially true when the email addresses contain network login IDs. Even when they do not contain login IDs, it may be possible for an attacker to guess the username format given a list of first names, last names, and/or initials.
  4. Employee directories – Like email addresses, employee contact directories provide ample information for an attacker to begin building a list of usernames. The process is further simplified when the directory contains email addresses that begin with network login IDs.
  5. Authentication status messages – Attackers often use authentication status messages to enumerate login IDs. Consider the following example – when entering a non-existent username, an application responds with the message “Invalid username”. When entering a valid username with an incorrect password, the application responds with the message “Invalid password”. Using a brute force utility, an attacker could identify valid accounts by submitting possible usernames and examining the contents of the web server responses. Even a difference of a single byte in a web server response is enough for an attacker to distinguish between valid and invalid login IDs.
  6. Password reset pages – Web applications often include password reset pages that allow users to reset a forgotten password. These pages commonly ask for a username and then prompt the user with a list of challenge questions. An attacker can identify valid usernames by looking for web server responses containing challenge questions.
  7. Application error messages – Web and application servers sometimes return error messages containing server-side file paths. On Unix/Linux-based systems, the file paths can contain user home directories. Most often, the name of the home directory corresponds with a username on the web server.
  8. SQL injection – In a SQL injection attack, an intruder inserts malicious strings into web application input fields in an attempt to manipulate the SQL queries performed by the application. The ultimate goal of such an attack is to gain access to information stored in a backend database. When the malicious input is not removed (or escaped) prior to use, it may be possible for an attacker to retrieve usernames and passwords from the database.

Bear in mind that this is not an exhaustive list, and always be on the lookout for sources of information leakage on your website.

Categories: Information Leakage, Website Security