S 4.396 Protection against unauthorised automated use of web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

A web application is usually used by humans and does not require any automated use (e.g. by scripts). On the contrary, brute-force attacks (e.g. guessing access data) and enumeration attacks (e.g. automated determination of valid login names) are based on the automated control of a web application (automation). Within the framework of these attacks, the collection of confidential data is mostly attempted by repeating, slightly varying queries (e.g. changed user names).

In order to prevent automation and to see off concomitant attacks, the web application must be able to differentiate between automated and manual accesses. Automated accesses are characterised by a large number of access attempts within a short period significantly exceeding the usual amount.

Therefore, a tolerance threshold for repeatedly queried resources may make such attacks more difficult (tarpit). If thresholds against automated queries are specified, it must be observed that the limitation of functionality and operation of the web application for legitimate users is as low as possible. If thresholds for essential functions of the web application are too narrow, attackers may misuse this for denial-of-service attacks at a web application level. For example, if user accounts are blocked for a certain period after a defined number of unsuccessful login attempts, deliberately made erroneous input may cause many user accounts to be blocked for longer periods. Accordingly, legitimate users can no longer log in to the web application during this period.

Furthermore, the efficiency of automated attacks normally strongly depends on the level of detail of the information in the replies of the web application (see S 4.400 Restrictive disclosure of security-related information in web applications).

The following examples indicate possible protection mechanisms:

• Artificial delay between the input of access data during user authentication and the message regarding an unsuccessful login attempt may make brute-force attacks more difficult due to the increase time required. The efficiency of this method can be increased by a progressive increase of the delay after every unsuccessful attempt.
  If input is rejected, information regarding the reason should be generic. For example, an attacker must not be able to extrapolate a valid user account based on messages such as "Invalid password" instead of "Invalid access data" (see also S 4.395 Error handling by web applications).
• Attempted attacks are mostly characterised by a large number of unsuccessful attempts regarding the performance of an activity. Therefore, an active session should be terminated and re-login should be required when an unusually high number of failed attempts is identified.
• Automated attacks may be seen off by temporarily blocking the IP address if an attack is suspected. In this case, it should be taken into consideration that persons not involved may be affected by the block due to this measure (e.g. if several users use the same proxy).
• so-called CAPTCHAs (Completely Automated Public Turing Test To Tell Computers and Humans Apart) are often used to differentiate automated and manual accesses. In this case, the user of the web application must perform a task (e.g. the characters in a picture must be identified and entered or riddles must be solved), a computer program cannot perform readily. Depending on the technology used and the assignment, it may be possible that handicapped people can only use the web application to a limited extent. For example, the task should alternatively be provided acoustically as well in order to allow the web application to be used by visually impaired people. It must be noted that the use of CAPTCHAs is regulated and forbidden by law in many countries for discrimination reasons. In Germany, the Federal Administration is obliged to design its publicly accessible internet and intranet offers according to the German Ordinance on Barrier-Free Information Technology (Barrierefreie Informationstechnik-Verordnung - BITV).

Review questions:

• Does the web application recognise automated accesses and are suitable safeguards taken making automated use more difficult or preventing automated use?
• Does the definition of thresholds for web applications take into consideration possible effects (e.g. susceptibility to denial-of-service attacks)?
• Is a restrictive information policy implemented by the web application?
• Are the general legal conditions checked before using protection safeguards which possibly limit the use of the web application to certain groups of users and could thus be discriminatory (e.g. CAPTCHA)?