Insufficient Anti-automation

Insufficient Anti-automation occurs when a web application permits an attacker to automate a process that was originally designed to be performed only in a manual fashion, i.e. by a human web user.

Web application functionality that is often a target for automation attacks may include:

Application login forms – attackers may automate brute force login requests in an attempt to guess user credentials

Service registration forms – attackers may automatically create thousands of new accounts

Email forms – attackers may exploit email forms as spam relays or for flooding a certain user’s mailbox

Account maintenance – attackers may perform mass DoS against an application, by flooding it with numerous requests to disable or delete user accounts

Account information forms – attackers may perform mass attempts to harvest user personal information from a web application

Comment forms / Content Submission forms – these may be used for spamming blogs, web forums and web bulletin boards by automatically submitting contents such as spam or even web-based malware

Forms tied to SQL database queries - these may be exploited in order to perform a denial of service attack against the application. The attack is performed by sending numerous heavy SQL queries in a short period of time, hence denying real users from service.

eShopping / eCommerce - eShopping and eCommerce applications that do not enforce human-only buyers, can be exploited in order to buy preferred items in large amounts, such as sporting events tickets. These are later sold by scalpers for higher prices.

Online polls - polls and other types of online voting systems can be automatically subverted in favor of a certain choice.

Web-based SMS message sending - attackers may exploit SMS message sending systems in order to spam mobile phone users

Example

A simple example of Insufficient Anti-automation, is an application that allows users to view their account details, by directly accessing a URL similar to the following:

http://www.some.site/app/accountDetails.aspx?UserID=XYZ

Where XYZ denotes an Account ID number.

If the application issues predictable (or enumerable) Account ID numbers, and also does not employ anti-automation mechanisms, an attacker could write an automated script, which would submit massive amounts of HTTP requests, each with a different Account ID number, and then harvest user account information from the response page.

In this example, the application suffered from several vulnerabilities, all of which contributed to the success of the attack -

Insufficient Anti-automation: web users were allowed to submit a large amount of service requests, without any mechanism to limit them. For example, After 3 invalid attempts, the IP address should have been blocked for a "chilling period", or should require that the user will contact the service provider over the phone
Insufficient Authentication: unauthenticated web users were allowed to access sensitive application functionality

CAPTCHA

A common practice for protecting against automation attacks is the implementation of CAPTCHA mechanisms in web applications. CAPTCHA stands for "Completely Automated Public Turing test to Tell Computers and Humans Apart".

Common CAPTCHA mechanisms may include:

Distorted text inside images, where the user has to type the text
Simple math questions such as: "How much is 2+2?"
Audio CAPTCHA, where the user has to type the word that is played
Common sense questions such as: "What is the capital city of Australia?"

It is worth noting, the some common CAPTCHA implementations have been proven to be insecure and/or breakable, for example:

Insecure design and/or implementation of CAPTCHA mechanisms (replay attacks, reverse engineering, etc.)
Solving image-based CAPTCHA using OCR techniques
Solving audio-based CAPTCHA using sound analysis