Application Self Protection – A New Addition to the OWASP Top 10

OWASP has just released their release candidate of the Top 10 most critical web application security risks. While no major changes were included, i.e. Injection is still number one in the list, they added two new ones:

1. A7 – Insufficient Attack Protection
2. A10 – Under protected APIs

This blog discusses the first.

A7 – Insufficient Attack Protection

OWASP stated the reason for the addition as being:

For years, we’ve considered adding insufficient defenses against automated attacks. Based on the data call, we see that the majority of applications and APIs lack basic capabilities to detect, prevent, and respond to both manual and automated attacks. Application and API owners also need to be able to deploy patches quickly to protect against attacks.

An application must protect itself against attacks not just from invalid input, but also involved detecting and blocking attempts to exploit the security vulnerabilities. The application must try to detect and prevent them, log these attempts and respond to them.

What are some examples of attacks that should be handled?

• Brute force attacks to guess user credentials
• Flooding user’s email accounts using email forms in the application
• Attempting to determined valid credit card numbers from stolen cards
• Denial of service by flooding the application with many requests
• XSS or SQL Injection attacks by automated tools

A more complete list can here found here but the ways in which they are handled are all very similar.

Prevention

The first step is to prevent these types of attacks.

Consider using some built-in steps for preventing attacks to the application. This includes:

• Remove or limit the values of the data accessed using the application; can it be changed, masked or removed?
• Create use (abuse) cases that simulate automated web attacks.
• Identify and restrict automated attacks by identifying automation techniques to determine is the requests are being made by a human or by an automated tool.
• Make sure the user is authenticated and authorized to use the application.
• Consider using CAPTCHA when high value functions are being performed.
• Set limits on how many transaction can be performed over a specified time; consider doing this by user or groups of users, devices or IP address.
• Consider the use of web application firewalls that detect these types of attacks. Another alternative is using OWASP AppSensor or similar; it is built into the application to detect these types of attacks.
• Build conditions into your terms and conditions; require the user not to use automated tools when using the application.

Other items to consider to use include:

• Networks firewalls
• Load balancers
• Anti-DDoS systems
• Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
• Data Loss Prevention

Detection

An application must determine if activity is an attack or just suspicious.  The response must be appropriate based on which of these is true.

• Could the user have made a mistake when entering the data?
• Is the process being followed for the application or is the user trying to jump past steps in the process?
• Does the user need a special tool or knowledge?

If any two of the above items are true, then it is most likely an attack and not suspicious activity.

Is it possible that the requests are coming in at a very high rate? A typical user may make one request every couple of seconds, whereas a tool such as Burp Suite Pro or WebInspect may make many more requests per second. The application should also detect these types of attack or attempts to find vulnerabilities in the application.

Response

The application can handle detected attacks or even the suspicion of attacks in a variety of ways.

The first should be a warning to the user. This will deter a normal user that their activities are being monitored. It would also warn a malicious user that certain events are being monitored, though it will probably not deter the latter person.

The application could, based on further activity after the warning, either logout the user or lockout the user. If a logout is performed, automated tools can be programed to automatically re-authenticate the user. If lockout is chosen, then all activity will stop.

In any of the above cases, a legitimate user may end up calling the help desk, so the application must log this type of activity and notify the application’s administrators. The log must be reviewed to determine if the response was appropriate.

Choosing which action to perform would depend on the sensitivity of the data within the application. A public website must be more forgiving to prevent overreaction to suspicious activities; whereas an application with highly sensitive data must respond quickly to suspicious activity.

Conclusion

The OWASP Top 10 2017 A7 – Insufficient Attack Protection requires the application to prevent, detect, and respond to attacks. This could affect other regulations such as PCI, which base their standards on the OWASP Top 10.

References

• OWASP Top 10 2017:  https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
• Insufficient Anti-automation: https://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation
• OWASP Automated Threats to Web Applications: https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications
• OWASP AppSensor Project: https://www.owasp.org/index.php/OWASP_AppSensor_Project
• OWASP Automated Threat Handbook: https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf

Steve Kerns