3 Security Case Studies: Demystifying The Logical Flaws

How do you translate an abstract business idea in machine language? How can you process overlapping theories without making the machines bleed? Actually, you cannot.

Machines, unlike human brains, work on simplified binary logics. They respond to conditions that must lead to a simple ‘YES’ or ‘NO’, and absolutely nothing between it.

However, that is not how people running businesses think. They take decisions. Often quickly, frequently, and making the out most of available information. While security is certainly on their mind, there is not enough time to study implications in detail. This is exactly what leads to business logic or domain logic flaw.

A business logic flaw is an application vulnerability, which arises by circumstantial security weakness. As one-of-a-kind problem, it does not have universal solution and cannot be detected by automated web application scanning either. Here is a simple way to understand this.

“Only those who understand your business will be able to detect your business logic flaws.”

In theory, business logic vulnerability might seem a very vague, abstract idea; it poses serious threat to security, which we will help you understand with following examples.

Case Study 1- Stock Broking Firm

A renowned stock broking firm wanted its customers to trade online. Their dummy online trading platform focused on increasing participation and making transactions faster in a two-step process.

Step 1: Users could pick stocks of their choice, number of shares, and click on ‘BUY’. The application then calculated the total value of the transaction and asked users to ‘PLACE ORDER’.

Step 2: After Step 1, users can choose to either proceed with the order or cancel the transaction.

Million Dollar Problem

The web application scanning session showed that the application was clean of any OWASP or WASC vulnerability, but problems existed. An attacker could actually take informed decisions and make huge profits without administrators knowing about it. The attacker had to select stock at current price and freeze the process at confirmation dialog box. If the next day, prices for that particular stock shoot up, he could confirm the frozen trade and get the stocks at older value.

Case Study 2- Online Auction House

An online auction house valued website security above everything else. The owners understood that many hackers would try to use brute force for forcibly getting into competitor accounts. Hence, they started using limited time account suspension for three wrong login attempts. In simpler words, the associated account ID would be locked if wrong password were used for three consecutive times.

Increasing Odds

Imagine that there are only two users who want item X on auction. They both are placing bids, topping each other, and now just one hour remains for the online auction. One of the users knows about the account suspension policy, so he uses the account ID of the other bidder and enters wrong password for three times to lock his account. This way, only one bidder remains in the auction.

Case Study 3- E-commerce Website

An ecommerce website allowed users to view product and its price, select that product, purchase summary, and then proceed to the checkout. The process was designed to be executed in this particular order only and the administrator did not set rules for something different.

Custom Pricing

An attacker discovered that he could go back to the shopping cart after inject custom price in the URL. Website’s server executed it and allowed the attacker to pay for the revised pricing.

The Logic behind Logical Flaws

In days when hacking fetches much greater rewards, crooks are always looking for ways to get around your database, or whatever they can get their hands on, which should alarm you. When complex business ideas overlap each other, chances of discovering loopholes increase far beyond what we have explained in examples above.

In fact, in recent times, more and more hackers are looking for ways that go undetected by automated scanning, the ways that exploit business logic paradoxes.

Security analysts believe that web applications were and are being exploited with business logic vulnerabilities. Unfortunately, most companies do not even know about them unless there is a monetary leakage. Following are some of the rules that need assessment.

  • Money-Related Application Logics- These logics command online monetary transactions, deals, discounts, refunds, shipping fee and so on.
  • Time-Related Application Logics- These logics define how web applications handle sessions and timeouts for users.
  • Process-Related Application Logics- It is also possible to exploit internal-facing applications for human resources management, procurement, warehousing and other processes.

Counterbidding Hackers with Proactive Detection

How do you patch business logic vulnerabilities before the hackers could find them? You find them first.

Business logic vulnerability is essentially a human task that requires expertise, trained to identify flaws, much like hackers do. Managed web application scanning is a better way to detect all kinds of vulnerabilities within the application. While automated scanning looks for top OWASP threats, security experts will understand your business functions and their subsequent effects on web applications.

Once detected, you can either patch the vulnerability in each application or shield them with managed web application firewall. A managed web application firewall’s value goes beyond virtual patching and time to fix benefits of patching vulnerabilities. The main benefit are

a) Providing visibility of an attempted attack

b) Providing more insights about attackers, which can help in taking more proactive detect and protect steps to track and block them.

Eventually, it helps in improving the Total Application Security postures consistently and not as a point in time improvement.