Business logic vulnerabilities in website application security

Tram Ho

# Overview Website security vulnerabilities such as SQL Injection, UnBroken Access Control, Unrestricted File Upload, XSS are probably not alien to many security people or programmers. Vulnerabilities occur when web application data is not processed on the server allowing hackers to exploit and steal sensitive data or interfere with data on the server. These vulnerabilities often come from programmers not following safe programming guidelines and handling unsafe data on the server. Vulnerabilities often come from the source code of web applications and can be addressed by updating the source code or using web application firewalls to prevent exploits. Unlike the above vulnerabilities, Business logic vulnerabilities come from unsafe functional design, application operation flow, or unsafe data handling. When developing the application, the operating and functional scenarios will be defined and developed according to those scenarios. When performing testing of applications, testers will also test under such scenarios. However, there are some circumstances that are out of scope or scenarios that we do not anticipate. For those reasons, hackers will take advantage of weaknesses in the way the application works to exploit the web application. As a result, user data will be exploited or resources in the system will be illegally exploited and stolen. # What is a Business Logic Vulnerability ![image.png]( ## Concept A Business Logic Vulnerability is a vulnerability in a business logic. design and implement an application that allows an attacker to cause unintended behavior. This could potentially allow attackers to manipulate legitimate functionality for malicious purposes. These errors are the result of not anticipating possible abnormal application states and, therefore, not handling them safely. Instead of following the correct sequence or operation of the website, the hacker will find a way to do it differently from the application’s business flow to discover security weaknesses that exist in the application. Logical errors are often not easy to detect for ordinary users because many are not exposed when using the application normally. However, attackers can exploit odd behaviors by interacting with the application in ways that the developers never intended. Let’s analyze some examples to better understand the vulnerability. ## Example **Example 1**: ***Purchase on the website*** After the user selects an item to be purchased on the website, an order includes the following information: Item code, quantity, unit price and total amount will be generated and sent to the next step and in this step the data will be sent to the server for processing in 2 streams including stream 1: processing the quantity in the database (checking the number of quantity, unit price, subtract quantity after successful to create order) and flow 2: payment to deduct money and user account. Suppose a user buys 5 bags for 50,000 VND/bag. At the payment step, the amount users will have to pay is 5 * 50,000 = 250,000 VND. Usually at this payment step, the web interface will not allow the user to change the quantity, unit price or amount data, so the developer thinks this data is correct and proceeds to process the data. in the database as well as pay that amount. However, by using some tools such as proxies, hackers can intercept the request and fix the amount to 1000 VND and send it. After that, the application received the request and issued an application with the amount of 5 bags (under thread 1) but only deducted 1000 VND (under stream 2) instead of 250,000 VND. This makes it possible for hackers to buy goods with much less money than they actually do **Example 2**: ***Application to transfer money between 2 banks A and B***. The operation flow does the following. Suppose user 1 has 10 million dong at bank A and user 2 has 20 million dong at bank B. User 1 transfers when transferring money from bank A to user 2 at bank B, The application will deduct the amount that user 1 transfers at bank A, and add that amount to user 2’s account at bank B. * **Normal case**: User 1 transfers 5,000 .000 vnd (5 million vnd) from bank A to user 2 at bank B B. After successful implementation, the amount of user 1 in bank A is 5,000,000 vnd, the amount of bank B is 25,000,000 VND. * **Unusual case**: User 1 transfers a negative amount of – 5,000,000 vnd from A -> B. Because there is no logic check for the amount when transferring in, after successful implementation, the amount in user 1 account in bank A is: 10,000,000 – (-5,000.0000 = 15,000,000 vnd. Meanwhile, the amount in user 2’s account in bank B is 20,000,000 + (-5,000). .000) = 15,000,000. So after implementation, the sender increases the amount, the receiver decreases the amount.Through the above 2 examples, we can have a rough idea of ​​how the business logic vulnerabilities are. In the next section we learn how to detect and exploit these vulnerabilities # Causes, exploits, and remedies ## Causes Business logic vulnerabilities often arise as a result of the design and Developers make false assumptions about how users will interact with the application. These bad assumptions can lead to incomplete validation of user input. usually assume that ng The user that will transfer can only transmit data through the web interface (input field) and the application can use this data. These data are easily bypassed by attackers using proxies. Finally, hackers can overcome special cases beyond design. Logic errors are especially common in complex, multi-business systems because even the development team itself does not fully understand or anticipate the possible scenarios. To avoid logical errors, developers need to understand the application as a whole. This includes being aware of how different functions can be combined in unexpected ways. ## Test target * Defines the data types that the web application accepts. * Make sure all the data needs to be processed on the server. * Try to break the format of expected data and analyze how the application is handling it. ## How to Test * Review project documentation and use exploratory testing to look for data entry points or differences between systems or software. * Once found, try to insert logically invalid data into the application/system. Specific testing methods: * Perform GUI front-end functionality validation on the application to ensure that unique “valid” values ​​are accepted. * Uses HTTP POST/GET observable blocking proxies looking for places where variables like cost and quality are passed. In particular, look for “interference points” between applications/systems that can be inserted or tampered with. * Once variables are found, begin interrogating the field with logically “invalid” data, such as a social security number or a unique identifier that does not exist or does not match karmic logic service. This test verifies that the server is working properly and does not accept logically invalid data. ## Remedy * Make sure developers and testers understand the app’s flow of action and its legitimate data * Try to make assumptions about special cases, data that isn’t valid and other scenarios that deviate from the normal flow of the application * Maintain clear data flow and design documents for all app development and workflow so it can be understood application changes and its flow. * Write code as clearly as possible, preferably well-written code that doesn’t need documentation to understand it. In cases of unavoidable complexity, creating clear documentation is crucial to ensure that developers and other testers know what assumptions are being made and exactly what behavior is expected. What is wait. # Mining demo {@embed:}

Share the news now

Source : Viblo