Web Security : Seeking Design Flaws - Abusing Predictable Identifiers, Predicting Credentials, Finding Random Numbers in Your Application

10/16/2012 3:05:51 AM

1. Abusing Predictable Identifiers

1.1. Problem

Unique identification provides the means to look up user data. Yet if these unique identifiers are easily predictable, it may be possible for a malicious user to adjust his unique identifier to match another’s, thus enabling him to view another user’s personal information. This recipe shows you how to find and use predictable identifiers.

1.2. Solution

This next example has affected just about every major blog publishing platform as blog platforms have matured. For the time being, let’s pick on WordPress; they have long since fixed this particular problem.

WordPress allows multiple users to post to group-run blogs, but also allows those users to mark individual posts as private. These private posts should not be accessible by the public nor by other group members; they are essentially diary entries.

One particular page was used to craft posts and to re-edit posts once they had been saved. This page used the following navigational structure:

post.php?action=edit&post=[post ID]

Each post ID was sequential in nature. If you created a post and it was assigned ID 503, the next post would be assigned ID 504. These are easily predictable identifiers. By starting from 1 and iterating through each post ID, one could view and edit all posts in the order they were written, no matter which user originally crafted it. Unfortunately, this also let the user view private posts belonging to other users.

For instance, user Abe wrote a private post that was assigned the post ID 123. User Biff browses through all the available posts, eventually reaching post ID 123.






At this point, user Biff notices that the “Private” flag is marked for this post and savors the discovery of a secret. Ultimately unsatisfied, Biff uses the edit capabilities granted via browsing in this manner and changes the private entry to a public, published post. User Abe thus has his deepest secrets exposed to the Web—a confidentiality breach!

The solution in this case is not to randomly assign post IDs. In this case, predictability was not the problem. Instead, the problem was that the authorization and access controls were lacking. User Biff should not have been able to view or edit user Abe’s private posts, no matter how he arrived at the particular URL.

1.3. Discussion

This is a real issue that resurfaces occasionally with all sorts of document management software, of which blogs are only a small example. Private data stored on a publicly accessible service needs to be well-protected.

While blogging may appear a trivial example, it is common for systems to assign sequential IDs, yet not explicitly verify the permissions for a particular document or record. Often developers will assume that if no link is presented to a user, then the user cannot find a particular protected record. Finding these protected or confidential records can be as simple as incrementing IDs repeatedly. Private blog posts may seem low risk, but this vulnerability has led to leaked internal memos and other corporate information. Often, IDs will be encoded so that they might appear random. 

This WordPress example was a real bug. We are grateful to the folks at WordPress who see the benefit of publishing bugs to the public. You can check this bug report yourself at

This technique might seem trivial, too. Surely the expensive, professional, automated web testing software would check something like this, right? Again, the answer may surprise you. Straightforward testing like incrementing identifiers is trivial to do with a tool like cURL, but is not done routinely by the automated scanners. Adding it to your manual or automated tests will improve your security coverage, even if you routinely use a commercial security scanner.

2. Predicting Credentials

2.1. Problem

Many systems assign user credentials, such as usernames, passwords, or status, rather than allowing the user to specify their own. While this is often a security measure to ensure the strength of user credentials, it can backfire if those credentials are easily predictable. Learn how to avoid predictable credentials so that your software does not fall prey to the same trap.

2.2. Solution

This recipe only applies if your application automatically assigns initial passwords or contains batch scripts to do so during initial deployment.

Identify how usernames, passwords, or other credentials will be established. Will usernames be publicly displayed? If so, is it at the discretion of the user or via a directory?

If usernames are generally accessible, understand that they may be harvested via a script. An attacker will be able to attain a partial or complete list of users if the usernames are displayed at the user’s discretion or in a directory, respectively.

Are passwords assigned in bulk? How are they generated?

If passwords are assigned by incrementing a value or are generated using the username itself, there is a high chance that the password will be easily guessable. 

Table 1 shows credentials being issued in bulk. Each email address and password is generated and sent to the corresponding user.

Table 1. Default passwords based on email
Email addressGenerated password





Although Table 1 shows that distinct passwords are assigned to each user, anyone who has been issued a password can see the implicit pattern. If George could infer Alice’s email address and if he knew she had not changed her password yet, he could easily take over her account.

2.3. Discussion

While the example given seems rather basic, it is vitally important not to fall prey to this vulnerability. Predictable user IDs allow attackers to gain a foothold on your application. Even though the administrator’s account may not be at risk this way, gaining any legitimate account is often a very significant first step for an attacker.

Another important point is to consider how easily a person can request and receive multiple accounts. Many web applications require a distinct email address for each account. A user who owns her own domain, however, can typically have an infinite number of email addresses in her domain. Thus, she could request many different accounts and receive many different initial passwords, in order to infer the pattern.

One thing we’ve learned is that every time you assume a bug or vulnerability is just common sense or that nobody would make that mistake, it will pop up again. So while the above example might seem like a trivial test, be sure to double-check. For instance, a company we worked with was celebrating a successful merger. They modified a shopping cart system to allow each and every employee to select one of many free gifts. To ensure that each employee only signed up for one free gift, accounts were created and assigned in bulk. Every single account was created and mailed out with “password” as the password.

3. Finding Random Numbers in Your Application

3.1. Problem

Many aspects of an application’s security will depend on the fact that an adversary cannot reasonably guess certain values in the system. You probably depend on encryption keys, session IDs, and possibly nonces. In this recipe we just try to identify where random values are being used in your application.

3.2. Solution

If you have surveyed your application by spidering it , then you have a starting inventory of pages to look at. Rather than examine those pages one by one, you should also consider which actions in your application are most important to perform correctly (e.g., those involving money, data access, system integrity). Look at the parameters exposed in the body of the page, in the cookie, and in the URL. In particular, look at:

In the body of the page

  • Session state like ASP.NET’s __VIEWSTATE in hidden form fields (e.g.,<input type="hidden" name="__VIEWSTATE" value="AAA...">).

  • Unique identifiers, like customer IDs, guest IDs, etc., also in hidden form fields.

  • Checksum values in hidden form fields or in JavaScript variables.

  • JavaScript variables and functions that control behavior of the application, such as setUserID(215);.

In the cookie

  • Session IDs. They almost always have some variation or abbreviation of the word “session.”

  • Unique identifiers for the visitor, their account, or other resources.

  • Representations of things like roles, groups, or privileges (e.g., groupid=8).

  • Indicators of workflow. Things like status=5 or state=6 or next=225.

In the URL

  • Session IDs, as in the cookie.

  • Unique identifiers, also as you might find in the cookie.

  • Representations of things like resources (e.g., msgid=83342).

  • Indicators of workflow. Things like authorized=1.

Remember that many of these things will be encoded with Base 64, URL encoding, or both. 

3.3. Discussion

Many applications that use randomness don’t really rely on the unpredictability of that randomness. Most uses of randomness do not have the same impact as they might in an online poker game, for instance. If your online chat program randomly picks an avatar for participants, does it really matter that a certain avatar is chosen with a little more likelihood than another?

Once you have found the random numbers in your application, you need to ask questions to help you determine whether the randomness and unpredictability is vital to your application. You might ask:

  • How much damage could a user do if he knew how to predict this random number?

  • How upset would one user be if she found out that someone could predict the next outcome?

  • How bad would it be if two documents (users, resources, links, etc.) were assigned the same value?

In some cases, there won’t be a major security failure. In other cases, failure will be catastrophic. Confidential data will be leaked, users will see each other’s sessions, or resources might be modified in unexpected ways.

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8