Web Security : Seeking Design Flaws - Testing Random Numbers, Abusing Repeatability

10/25/2012 1:27:16 AM

1. Testing Random Numbers

1.1. Problem

You have found some indentifiers, session IDs, or other aspects of your application that you need to ensure are random. To do this, you’ll have to use software that can perform various statistical analyses.

1.2. Solution

You want to use the National Institute of Standards and Technology (NIST) Statistical test suite available from This software helps you evaluate the output of a random number generator to see if it complies with the randomness requirements in the Federal Information Processing Standards (FIPS) 140-1 document. Although the FIPS standards are intended to regulate U.S. government agencies, many non-government agencies adopt them, since they are clear, comprehensive, and endorsed by well-respected leaders in industry. To fully understand the mathematics behind how the tests work, you would read and understand the NIST documentation and operating instructions, since the NIST mathematicians created the tests. Fortunately, the Burp suite contains the FIPS tests in an easier-to-use format than the original source code. We’ll use that for our analysis.

The first step to analyzing the randomness of identifiers is to collect a lot of them. Burp has the ability to collect lots of identifiers from web pages (whether in the URL, the body of the page, or the cookie), as shown in Figure 1

Figure 1. Burp selecting a web form parameter

Many times the identifier you want to analyze will not be so accessible. Consider that you want to analyze the randomness of a document ID or a numeric user ID. You won’t want to create 10,000 users just to get 10,000 user IDs. And if your system doesn’t already have 10,000 documents in it, you won’t have 10,000 document IDs to analyze. This is a time when you’ll need to collaborate with the application developers. Get them to write a small demonstration program that invokes all the same APIs and methods, in the same order and with the same parameters. Save the output to a file, with one identifier per line.

When you have your manually gathered data, go to Burp and go to the Sequencer pane. Choose Manual Load and press the Load button. Locate the file with the random data on your hard disk, then click the Analyze Now button. 

1.3. Discussion

Very often, because of how mathematicians define and understand randomness, you will get a lot of handwaving and wishy-washy answers from experts about whether something is sufficiently random. You want a big green check mark saying “totally secure.” Burp is helpful in this regard because it will tell you when the data it analyzes are “poor,” “reasonable,” and “excellent.” Figure 2 shows one of the FIPS tests of the variable that was sampled in Figure 9-1. It overall passes the FIPS 140-1 secure randomness requirements, with one bit failing.

We have to understand what our attackers might possibly do and what attacks are feasible before we make claims about how impossible or improbable it is to attack our random numbers.

Figure 2. Burp showing FIPS test results

2. Abusing Repeatability

2.1. Problem

In many circumstances, allowing a malicious user to try the same attack repeatedly gives him a great advantage. He can attempt a variety of different combinations of input, eventually finding the one that breaks your application. Remember that the strength of identifiers and passwords depends on only allowing a limited number of guesses. Learn to recognize repeatable actions that should have limits via this recipe.

2.2. Solution

For any given feature, any action, any functionality that you’ve just performed, ask yourself—how can I do this again? If you can do it again, how many times can you do it? Lastly, what’s the impact if you do it that many times?

That is a very simple method of determining potential abuse of repeatability. Of course, with a complex web application, it would be tremendously time-consuming to attempt to repeat every action and every system state.

Instead, create a state transition diagram or perhaps control flow diagram of your application. These diagrams portray how users move through your application—what they can do, when, and where. You’ll want to investigate the areas where the diagram contains loops or cycles. If a user can take several actions to eventually get back to the starting point, you have a repeatable action.

Knowing the expected result of this repeatable action allows you to predict the effects of repeated action. If the repeated effect could degrade system performance, destroy data, or just annoy other users, you have a security issue.

Thus, existing test cases often make the best sources for testing repeatability, as you already have the state transitions, input, and expected result written. If you think a particular test case has the potential to do damage when repeated, go ahead and repeat it. Better yet, automate it to repeat for you.

2.3. Discussion

PayPal gives you money for signing up with a bank account. Admittedly, it is always less than 15 cents—the deposited amount is used to verify that you successfully received the money and that it really is your account. PayPal uses several methods to ensure that you can’t sign up for too many bank accounts. Imagine the consequences if one could write a script to open and cancel PayPal accounts several times a second, collecting 10–15 cents each time. Sound far-fetched? It happened. You can read about it at

Even if your application doesn’t handle money, much of authentication depends on not being able to guess at a password. The ability to guess repeatedly removes the strength of the password’s secrecy. At the same time, users expect to be able to try several passwords; it’s impossible to remember them all the time.

This makes guessing passwords the classic repeatable action. Most users’ passwords are not very strong. Even if you enforce password strength, such as requiring numbers or special characters, there will still be weak passwords that just barely cover these requirements. For instance, given additional requirements, the top password of all time (“password” itself) gets reborn as “p@ssw0rd.”

Guessing a single user’s password can be quite difficult, given that each request to the server will have some normal lag. This restricts the sheer volume of password attempts possible in a finite length of time. However, if any account is a potential target, probabilistically an attacker is much better off trying the ten most common passwords against a thousand users than trying the top thousand passwords against ten specific users. For example, if 1% of all your users have the password “password1,” then an attacker need only attempt that password on a few hundred accounts to be confident of success.

The standard defense against this sort of attack is to lock accounts after a certain number password attempts. Most implementations of this fail to adequately protect users; either it opens up new possibilities of attack or does not prevent password attempts against many different users.

When it comes down to it, almost any action that is repeatable and could affect other people should have a limit. You do not want one user to be able to submit a hundred thousand comments on your blog or sign up for every possible username. One should not be able to send five thousand help requests to the help desk via an online form. Yet actions with no major implications might not deserve limits; if a user wishes to change their own account password every day, there is little impact.

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