Is your website resilient enough to withstand a
buffer overflow attack? A buffer overflow attack is actually one of the simpler attacks a malicious user may attempt. Imagine the following scenario. You have a public facing web page that allows unauthorized users to submit data. A malicious user probes your site to see if you have exposed this vulnerability. If your site is at risk, it may only take minutes for the user to bring your site down if they employ a
botnet attack.
The Attack
- The simplest attack method is for malicious users to throw overloading (2GB - 8GB) amounts of data in a text field in hopes of crashing the server due to out of memory errors.
The Prevention
- Bounds checking on the server-side is the most effective solution for preventing buffer overflows. For example, if you are using Spring's annotation-based validation this is all you would need:
/**
*
* Spring's annotation reference documentation
* Configuration setup example
*/
public class Student {
@NotBlank
@Length(max = 50)
private String firstName;
@Length(min = 1, max = 50)
private String lastName;
}
HTML's maxlength attribute is NOT sufficient:<input type="text" name="firstName" maxlength="50" />
This is not secure because there are tools that will enable users to bypass this HTML tier of validation. You must perform max length validation on the server-side as in the example above. - Leverage the bulkhead stability pattern to decouple your authenticated business critical applications from your publicly exposed (more vulnerable) applications. The goal of this pattern is to preserve the stability for a particular group of customers. Most software attacks are targeted at publicly available web sites. You should leverage this pattern if you want to help preserve the stability of your authenticated users during an attack on your publicly available sites.
- Prefer to keep public data out of session. This simple solution will help preserve memory if a user attempts a buffer overflow attack.
