Thursday, July 15, 2010
roberto.jpgRoberto's talk covered application-level vulnerabilities, and gave some ideas on how to plan for them, how to react when they happen, and how to recover from them.

Most denial of service attacks have traditionally covered the layer 3 or 4 (i.e. the transport or network stack), but Roberto has seen attacks against applications and web service layers.

Can lead to increased use of resources like CPU, network

Root causes:

- bug
- application logic open to abuse
- session level attacks


PHP: Can create an unbounded size object in code

Failure to release resource: DB exception doesn't close connection. Attacker can cause app to open up lots of DB connections and deny service.

Sesion related: storing lots of session objects that consume resources, so attacker can target this to exhaust server resources.

User input as a loop counter: If the user can control how many times an expensive operation is performed, it can cause the app to do lots of demanding work.

=> Put in some limits, don't allow the user to set in their code.

Regular expressions: Certain input may cause lots of passes through a regular expression, causing lots of CPU to be used.

Other web problems can amplify DOS effects (XSS, XSRF, SQL injection, large file input)


- Input strict validation and filtering
- Handle exceptions and properly release resources
- Set limits for:
  - Session related objects
  - Token expiration
  - Object allocation
  - Loop counters
  - User registration - captcha
  - Concurrent session tokens per IP address

- Testing your web app
  - Test Regex, database queries
  - DoS and stress testing
  - Security testing

XML attacks:

There are lots of attacks against XML or web services.

Recommendations: don't use customised XML parser, input validation, use an XML firewall, limit the sizes of input messages, disable external DTDs.

Webserver attacks:

Attacks to use up all the threads on a webserver, or slow down the processing so the server can't process other requests.

Recommendations: Apache and IS have modules or configuration settings. Make sure you test the changes.

Database attacks:

Make the DB do more work than they should. E.g. cause a slow scan over a whole table, or avoid caching layers.

Recommendations: Input validation, captcha or user limits, only let authenticated users perform slow queries, use caching layers.

If you are under attack:

Be prepared, have a plan, simulate it often.

When under attack:

Is it real? What is the target? Is the target critical?


Several methods: slow down the attack, deflect it, drop connections, escalate to authorities or other nefarious ways to stop botnets.


Meet up to debrief as soon as possible afterwards. What lessons were learnt? Update incident plan.

What was the root cause? What if it happens again? Provide all data to law enforcement.


No generic solution to DOS.

If offered a DOS solution product, look carefully before committing.

Start networking with people that can help you.

Comments are closed.