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

Chapter 11 

■

Attacking Application Logic  371

70779c11.qxd:WileyRed  9/14/07  3:14 PM  Page 371

---

■■

When escaping user-supplied data before passing to a potentially vul-

nerable application component, always be sure to escape the escape

character itself, or the entire validation mechanism may be broken.

■■

Always use appropriate storage to maintain any data that relates to an

individual user — either in the session or in the user’s profile.

Chapter Summary

Attacking an application’s logic involves a mixture of systematic probing and

lateral thinking. As we have identified, there are various key checks that you

should always carry out to test the application’s behavior in response to unex-

pected input. These include removing parameters from requests, using forced

browsing to access functions out of sequence, and submitting parameters to

different locations within the application. Often, the way an application

responds to these actions will point towards some defective assumption that

you can violate, to malicious effect.

In addition to these basic tests, the most important challenge when probing

for logic flaws is to try to get inside the mind of the developer. You need to

understand what they were trying to achieve, what assumptions they proba-

bly made, what shortcuts they are likely to have taken, and what mistakes they

may have committed. Imagine that you were working to a tight deadline, wor-

rying primarily about functionality rather than security, trying to add a new

function to an existing code base, or using poorly documented APIs written by

someone else. In that situation, what would you get wrong, and how could it

be exploited?

Questions

Answers can be found at 

www.wiley.com/go/webhacker

.

1. What is forced browsing, and what kind of vulnerabilities can it be

used to identify?

2. An application applies various global filters on user input, designed to

prevent different categories of attack. To defend against SQL injection, it

doubles up any single quotation marks that appear in user input. To

prevent buffer overflow attacks against some native code components,

it truncates any overlong items to a reasonable limit.

What might go wrong with these filters?