The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

HACK STEPS (continued)

■

Using several high-spec machines, accessing the application from differ-

ent network locations, script an attack to perform the same action

repeatedly on behalf of several different users. Confirm whether each

action has the expected result.

■

Be prepared for a large volume of false positives. Depending on the scale

of the application’s supporting infrastructure, this activity may well

amount to a load test of the installation. Anomalies may be experienced

for reasons that have nothing to do with security.

Avoiding Logic Flaws

Just as there is no unique signature by which logic flaws in web applications

can be identified, there is also no silver bullet with which you can be protected.

For example, there is no equivalent to the straightforward advice of using a

safe alternative to a dangerous API. Nevertheless, there is a range of good

practice that can be applied to significantly reduce the risk of logical flaws

appearing within your applications:

■■

Ensure that every aspect of the application’s design is clearly docu-

mented in sufficient detail for an outsider to understand every assump-

tion made by the designer. All such assumptions should be explicitly

recorded within the design documentation.

■■

Mandate that all source code is clearly commented to include the fol-

lowing information throughout:

■■

The purpose and intended uses of each code component.

■■

The assumptions made by each component about anything that is

outside of its direct control.

■■

References to all client code which makes use of the component.

Clear documentation to this effect could have prevented the logic

flaw within the online registration functionality. (Note: “client” here

refers not to the user end of the client-server relationship but to

other code for which the component being considered is an immedi-

ate dependency.)

■■

During security-focused reviews of the application design, reflect upon

every assumption made within the design, and try to imagine circum-

stances in which each assumption might be violated. Focus particularly

on any assumed conditions that could conceivably be within the control

of application users.