This article is provided by special arrangement with the Open Web Application Security Project (OWASP). This article is covered by the Creative Commons
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Share-Alike Attribution 2.5 license. You can find the latest version of this article and more free and open application security tools and documentation at http://www.owasp.org.
Denial of Service Attacks
Objective
To ensure that the application is robust as possible in the face of denial of service attacks.
Platforms Affected
All.
Relevant COBIT Topics
DS5.20 – Firewall architecture and connection with public networks
Description
Denial of Service (DoS) attacks has been primarily targeted against known software, with vulnerabilities that would allow the DoS attack to succeed.
Excessive CPU consumption
Modern MVC style applications are significant code bases in their own right. Many of the non-trivial business requests, such as report generation and statistical analys can consume quite large chunks of CPU time. When the CPU is asked to perform too many tasks at once, performance can suffer.
How to determine if you are vulnerable
Stress test your application to understand where the bottlenecks are.
How to protect yourself
- Only allow authenticated and authorized users to consume significant CPU requests.
- Carefully meter access to these bottlenecks and potentially re-code or change parameters to prevent the basic default requests from consuming so much CPU time.
Excessive disk I/O consumption
Database searches, large images, and huge cheap disks lead to unending requests for more disk I/Os. However, the best I/O's are the I/O's not taken. These might be serviced from RAM or simply not performed at all. Once a disk is required to search say a 50 MB index for each and every request, even the most grunty server will fail with even a moderate user load.
How to determine if you are vulnerable
Stress test your application to understand where the bottlenecks are.
How to protect yourself
- Only allow authenticated and authorized users to consume significant disk I/O requests.
- Carefully meter access to these bottlenecks and potentially re-code or change parameters to prevent the basic default requests from consuming so much disk time or space.
Excessive network I/O consumption
How to determine if you are vulnerable
- Profile your application with a network optimization tool.
- Any page or resource which gives out over a 20x input ratio (ie one kb request returning a 20 kb page and images) is a huge DoS amplifier and will quickly bring your site to its knees if a Slashdot post or attacker hits.
How to protect yourself
- Only allow authenticated and authorized users to consume significant network requests.
- Minimize the total size of any unauthenticated pages and resources.
- Use a DoS shield or similar to help protect against some forms of DoS attack, however, be warned these devices cannot help if the upstream infrastructure has been overwhelmed.
User Account Lockout
A common denial of service attack against operating systems is to lockout user accounts if an account lockout policy is in place.
How to determine if you are vulnerable
Using an automated script, an attacker would try to enumerate various user accounts and lock them out.
How to protect yourself
- Allow users to select their own account names. They are remarkably good at this.
- Do not use predictable account numbers or easily guessed account names, like "A1234" "A1235", etc.
- Record user lockout requests. If more than one account is locked out by the same IP address in a short time (say 30 seconds), prevent access from that source IP address.
- Automatically unlock accounts after 15 minutes.
Further reading
http://www.corsaire.com/white-papers/040405-application-level-dos-attacks.pdf