Advertisment

Business Logic Attacks: What Every Web Developer Needs to Know

author-image
PCQ Bureau
New Update

Today, when the whole security industry is concentrating itself on major and well known web applications attacks, malicious hackers are finding out constructively new ways to exploit web applications. They are now leaving tracks of traditional ones like SQL injection, XSS attacks, CSRF and HTTP related attacks and are increasingly focusing on exploiting the logic behind web applications. Such attacks are commonly termed as business logic attacks.

Advertisment

Snapshot



Applies To: Web developers, security specialists
USP: Understand the newest threat to the web landscape and how to counter it

Primary Link: Tech to Hack-Proof Web Apps: http://bit.ly/hleFL3

Search Engine Keywords:Business logic attacks






A majority of business logic attacks have got an upper hand on automated security tools such as scanners, web application firewalls (WAFs), intrusion detection/prevention systems (IDS/IPS). That's because such automated security is designed mostly to test what software should do and not what they can be made to do. Moreover, all HTTP requests that are made for business logic attacks appear completely normal and hence WAFs fail to recognize them. Here, we focus on such business logic attacks, how hackers exploit them, and finally, how to defeat them with effective security.

Why Business Logic?

Advertisment

The first and most obvious question is why is this new category of attacks termed this way and what does it really mean.

Wikipedia defines business logic as a non-technical term generally used to describe the functional algorithms which handle information exchange between a database and a user interface. It is distinguished from input/output data validation and product logic. Business logic models real life business objects such as accounts, loans, itineraries, and inventories. It also prescribes how business objects interact with one another.

Advertisment

Application or business logic refers to the behavior that is defined directly by the developer, ie it is not the general functionality that is provided as a part of the application server platform such as authentication, but rather the application-specific operations that define the application functionality such as item pricing rules, usage flows, presentation layout, etc. Henceforth, application logic attacks are characterized by the exploitation of a function or a feature that is specific to the application. They are different from one incident to another, based on the way they exploit the application.

You might have noticed a resulted unexpected behavior when two buttons are clicked simultaneously, a password change page disclosing detailed errors, elevation of privileges accidently or other sensitive information disclosure. A case of a malicious user exploiting the way discounts are designed in an online retail store by discovering a flaw that allows for discounts to be applied multiple times to the same item and reduce its price. All these and more such attacks exploit the logic behind the web applications making them doing what they can do but, are not supposed to do.

Advertisment

Unlike SQL injection and XSS attacks, which are relevant to any system that takes user input and has a relational database backend, each business logic attack is idiosyncratic to its application. This means, to find business logic vulnerability in a web application, a hacker (in most cases) has to spend time and brain learning its behind-the-scenes functionality.

Categorized below are some of the major business logic attacks.

Information leakage/disclosure

Advertisment

This particular attack accounts for about 40% of all attacks practised on web applications. Information leakage occurs when a web application reveals sensitive data which may aid an attacker in exploiting the system. It does not necessarily represent a security breach, but it provides the attacker, information that may be useful for future exploitation. For example, the HTML code below:

Here, as you can see in the comment left by the developer, which indicates that if image files are missing, restart 'ZBEAST'. Here, an attacker can easily deduce that the name of the server is 'ZBEAST'. Such a disclosure of information can be highly dangerous.

Advertisment

Not just this, parts of JavaScript code which particularly deals with data validation can also reveal lot of information about application business rules and what validations and checks are made on the data. If you are using automated tools which are used in creating web pages, they often comment out important and crucial directory paths. Verbose error messages which display web server's version number, running port, OS information are also very helpful for attackers.

From security perspective, programmers need to be more aware about whether they are unintentionally providing any crucial information. Regular checks should be made on JavaScript codes and custom error messages which are sent directly from web server. If possible, custom error messages should be modified to provide as little information as possible. Checks should also be made on accidently providing any debug and path information.

Advertisment

Abuse of functionality

Abuse of functionality is an attack technique that exploits an application's own functionality or logic to do attacks against it or others. It can be understood as abusing what an application is intended to perform, to result in unexpected and undesired output. Now, since the functionality varies from application to application, this class of business logic attack varies in difficulty level to exploit that functionality. For example, a particular application has money transfer functionality to transfer from one account to other and uses the following logic:

account_A = A — (10000)

account_B = B + (10000)

This example shows that A transfers money from his account to B's account. But, here an attacker can exploit this functionality by entering money in negative (-), which makes the logic to say:

account_A = A — (-10000)

account_B = B + (-10000)

Such an abuse would result in reverse flow of money i.e from B's account to A's account.

Another example of functionality abuse can be seen in online voting websites, which announces the winner as the person with highest likes to dislikes vote ratio. In most websites where such functionality is used, an attacker can abuse it by introducing his favorite person and voting for him/her just a few seconds before voting ends. This would result in only one likes and zero dislikes, hence resulting in highest likes to dislikes ratio, and thus attacker wins the competition.

Now, as is clear from the above example, such an abuse can be very hard to detect and also can vary from application to application. From security perspective, abuse of functionality can be stopped and solved by carefully testing the logic in different cases. Now, such attacks cannot be detected with automated means, hence it is best to test it manually.

Session related attacks

This category of business logic flaws is gaining popularity within the attacking community. Attacks like session hijacking, session fixation, credential/session prediction and insufficient /prolonged session expiration are in top priority in attack list. FOSS tools are easily available in the wild which makes session hijacking even very easy for a newbie. Insufficient session ID length resulting in easy brute force attacks, transmission of session IDs in an unsecured network, weak session cryptographic algorithms and insecure server session storage are making it all easy for the attackers.

From security perspective, programmers need to be extra careful regarding the above vulnerabilities. It should be ensured that cookies transmitted over an unsecure connection have the 'secure' attribute set. Moreover, if possible, make the application or system log attempts to connect with invalid or expired session tokens, along with the IP address of the client. In most cases, clients will access Web applications through corporate, ISP, or other proxies, or protocol-aware gateways (like firewalls). In such cases, whenever a session ID is passed, it is cached/stored at the intermediaries, and even in local caches.

These intermediaries can be a good target for attackers, to search for active session credentials, hence an extra care should be taken while encrypting session information.

Predictable resource location

Even if the web developer is very careful in designing the application logic, still business logic attacks can be done, if the server administrator is not that careful about security. This category of attack (also known as forced browsing) is used to unhide hidden website content and functionality. The attacker here discovers those directories and files on the web server which are not intended for public viewing. Such an attack is usually successful because file and paths often have common naming conventions and reside in standard locations. These usually include temporary files, backup files, logs, administrative site sections, configuration files. All these can include confidential and sensitive information about web application internals. Popular file locations like www.example.com/wp_admin, /system/, /password/, /logs/, /admin/, /test/ are most searched for confidential files. Performing brute force attacks and guessing directory paths including all the above and more such locations are in the priority list of attackers.

The business logic attacks discussed above are not limited to these only and may come out in more different types. Thus, to prevent such attacks it is advisable that the security department should have detailed and thorough analysis of the source code, functionalities, and server's easily guessable directory paths. Also, security experts should not rely on the automated security methods and scanners, after all its time to dive deep into the functionality itself.

Advertisment