business security

About the vulnerability:

injection
Business logic
information leakage

A04:2021 – Insecure Design

Online shooting range PortSwigger

1 Overview

1.1 Current status of business security

1.1.1 Business logic loopholes

In recent years, with the rapid development of information technology and the acceleration of global integration, computers and networks have become tools and media that are closely related to everyone, including personal work, life and entertainment, enterprise management, and even the country. development and reform are nowhere to be seen. Information and the Internet bring more than convenience and efficiency. A large amount of private, sensitive and high-value information data and assets have become the main targets of attacks and threats by malicious attackers. From the early golden age of hackers with geeks as the core, to Nowadays, in the huge black industry driven by the profit chain, network security has become an important issue that any individual, enterprise, organization and country must face. "Network security and informatization are major strategic issues related to national security, national development, and the work and life of the masses. Without network security, there will be no national security, and without informatization, there will be no modernization." With the development of Internet
+ , the economic form continues to evolve. Many traditional industries are gradually integrating into the Internet and using information and communication technology and Internet platforms to carry out frequent business activities. These platforms (such as banking, insurance, securities, e-commerce, P2P, O2O, games, social networking, recruitment, aviation, etc.) A large amount of important privacy data such as money, personal information, and transactions has become the primary target of hacker attacks, and because developers have weak security awareness (only focus on implementing functions and ignore the impact of personal behavior on the business of Wb applications during the use of users) The security impact of logical functions) and frequent iterations of development code have led to endless security risks at the business logic level of these platforms.

Business logic vulnerabilities are mainly defects in the business process design of developers, not limited to the network layer, system layer, code layer, etc. For example, bypassing login verification
, data tampering in transactions, and malicious calls to interfaces are all business logic vulnerabilities.

1.1.2 Targets of hacker attacks

On the one hand, with the development of society and technology, shopping, social networking, P2P, O2O, games, recruitment and other businesses have all equipped with online payment functions. For example, the e-commerce payment system saves the user's mobile phone number, name, home address, including payment bank card information, payment password information, etc. These are sensitive information that hackers are interested in. Attackers can take advantage of programmers' design flaws to tamper with transaction data, steal sensitive information, and steal assets. Today's hackers no longer aim to show off their skills, but mainly for financial gain. The purpose of attacks has gradually changed to profit-seeking.
On the other hand, today's business systems are becoming more and more mature for traditional security vulnerability protection technologies, equipment, and development frameworks, and it is becoming more and more difficult to intrude based on traditional vulnerabilities, which
increases the cost of hacker attacks. Business logic vulnerabilities can escape various security protections, and so far there is no good solution. This is also one of the reasons why hackers prefer to use business logic vulnerability attacks.

2. Business security testing

2.1 Business security testing process

2.1.1 Test preparation

The preparation phase mainly includes preliminary familiarity with the business system to understand the number, scale and scenarios of the business systems being tested.

For white-box testing, you can combine relevant development documents to become familiar with the business of the relevant system;
For black box testing, you can understand the business by restoring the business process through actual operations.

2.1.2 Business research

The business research phase mainly conducts interviews and surveys with relevant persons in charge of the business system to understand the overall situation of the business system, including deployment, functional modules, business processes, data flows, business logic, and existing security measures. Based on past test implementation experience, an interview questionnaire can be designed before business research. After the interview, the questionnaire may be continuously adjusted and updated as the specific situation of the customer's business system is understood more deeply (this step of black box testing can be ignored).

2.1.3 Business modeling

For business systems in different industries and different platforms, such as e-commerce, banking, finance, securities, insurance, games, social networking, recruitment and other business systems, identify high-risk business scenarios and model them.

Take the e-commerce system as an example:

2.1.4 Business Process Overview

After the modeling is completed, it is necessary to sort out the business processes of each business module of the important business scenario one by one, analyze it from four different dimensions, including the front desk and back desk, business and support system, and identify the business logic, business data flow and Function fields (parameter transfer points), etc.

The process combing of business modules mainly follows the following principles:

Distinguish between the main business process and the branch process. The business sorting work is analyzed around the main process, and the main process must be the core business process. The object of business process sorting should first be placed on the core main process, and the key business links must be sorted out;
Summarize business branch processes. Business branch processes often have common points. Branch processes with business similarities can be summarized into a certain type of business process without testing them separately;
Identify business process data information flow, especially the order and path of business data flow transmission between the two parties;
Identify the functional fields of the business data flow, identify the information of varying degrees of importance contained in the data flow, and understand the meaning of these fields to help analyze risk points in the next stage.

2.1.5 Identification of business risk points

After completing the early business process sorting work from different dimensions, for the front-end business, we should focus on the possible logical risks and technical risks of each step of the user interface operation; for the back-end business, we should focus on the logs and audits of data security, data flow and processing.

The identification of business risk points should mainly focus on the following security risk content.

Security risks in business links. Security risks in business links refer to security risks in the business that are visible to business users, such as identity authentication links such as registration, login and password retrieval. Whether there is a complete verification code mechanism, data Whether the consistency verification mechanism, Session and Cookie verification mechanism, etc. can avoid vulnerabilities such as verification code bypass, brute force cracking, and SQL injection.

Support the security risks existing in the system, support the security risks existing in the system, such as whether the user access control mechanism is complete and whether there are horizontal or vertical ultra-private vulnerabilities. Whether the encrypted storage mechanism in the system is complete and whether business data is transmitted in clear text. Whether the business interface used by the system can be accessed or called without authorization, whether replay and traversal can be called, whether the interface call parameters can be tampered with, etc.

Security risks that exist between business links, such as whether the system business process is out of order, causing a certain business link to be bypassed or rolled back, or a certain business request to be replayed infinitely. Whether there is a consistency verification mechanism for data transmitted between business links, and whether there is a risk that the business data can be tampered with.

Support the security risks that exist between systems, support the security risks that exist between systems, such as whether the data transmission between systems is encrypted and whether the parameters transmitted between systems can be tampered with. Whether the filtering mechanism for input parameters between systems is complete and whether it may lead to SQL injection, XSS cross-site scripting and code execution vulnerabilities.

Security risks between business links and supporting systems, such as whether data transmission is encrypted, whether the encryption method is perfect, whether front-end encryption, simple MD5 encoding and other unsafe encryption methods are used. Whether the system's mechanism for handling multi-threaded concurrent requests is perfect, and whether there are timing issues in server-side logic and database reading and writing, leading to race condition vulnerabilities. Whether the filtering mechanism for input parameters between systems is complete.

2.1.6 Conduct testing

Carry out targeted testing on the risk points identified and sorted out in the early business processes.

2.1.7 Writing reports

Evaluate and make suggestions on the risk results found in the process of business security testing, comprehensively evaluate the degree of risk in the utilization scenario and the severity of the impact, and finally complete the preparation of the test report.

3. Classic business security scenarios

3.1 Business security data

3.1.1 Tampering with product payment amount

Typical Case:

Buy a refrigerator for 1 cent

E-commerce websites need to protect the integrity and consistency of business data throughout the business process, especially to ensure the consistency of data transmission between the user client, the server, and the business system interface. In the transaction process of this type, it is easy for the server to fail to perform mandatory verification of the business data submitted by the user and to over-trust the business data submitted by the client. Commodity amount tampering test, modify the transaction page and other fields in the business process by capturing packets, for example, capture the amount field of the commodity in the request on the payment page, modify it to any amount and submit it, and check whether it can be completed with the modified amount data Business Process.

This test is mainly aimed at business security risks caused by incomplete verification of the payment amount of goods in the process of order generation, which usually leads to business logic loopholes in which attackers order goods with an amount much lower than the amount paid for the order.

3.1.1.1 Environment setup

3.1.1.2 Process

Use bp's own browser to log in to the account given to us by the question and check the login traffic.

Return to home, click on the leather jacket link, and check the traffic

Add leather jacket to shopping cart to view traffic

Empty the shopping cart, add the leather jacket again, then turn on the proxy to intercept traffic and view the data packets

Modify the amount of captured data packets

Put the bag

Click to buy

3.1.2 Front-end JS restriction bypass

Typical Case:

Bypass JS restrictions and purchase multiple discounted products

When many products limit the purchase quantity of users, the web application only restricts it through JS scripts on the page, without verifying the quantity submitted by the user on the server side. It modifies the transaction data generated and processed by the JS side by grabbing the request package sent by the client, such as Change the quantity of goods in the request to a value greater than the maximum quantity limit and see if the business process can be completed with abnormal business transaction data.

This test mainly targets some business logic problems caused by the imprecise and imperfect transaction restriction mechanism of the e-commerce platform. For example, if the quantity of goods purchased during a promotion is limited, but the quantity is not strictly verified on the front and back ends, it is often used by attackers to purchase multiple promotional goods, causing losses to the merchant.

3.1.3 Request replay test

Typical Case:

Buy once, receive multiple times

Request replay vulnerability is a common vulnerability in e-commerce platform business logic vulnerabilities caused by design flaws. Usually, the security issues caused are manifested when the product is successfully purchased for the first time and the request is made by referring to the normal process of ordering the product. Completely simulate the replay operation of the normal ordering business process, and can achieve results that violate normal business logic such as "one purchase, multiple receipts".

This test is mainly aimed at the business logic problem of the lack of an effective mechanism for judging the uniqueness of each transaction request in the ordering and exchange business process of the e-commerce platform. This test can verify whether the random number, timestamp and other generation mechanisms in the transaction process are normal. .

3.1.4 Business online testing

Typical Case:

Unlimited query of historical consumption records.

The business upper limit test is mainly aimed at some business logic loopholes caused by the server not strictly verifying the query range, order quantity, amount and other data submitted by the user during the business processing process of some e-commerce applications. Usually, in the business process, data higher or lower than expected is submitted to the server to verify whether the server performs strong verification on the submitted data as expected. Applications with such vulnerabilities usually manifest themselves as querying more information than expected, ordering or exchanging goods beyond the expected range, and so on.

This test mainly determines whether the application responds correctly to business requests outside the expected scope of the business.

3.1.5 Tampering with product order quantity

Typical Case:

damicms_5.4_Purchase any product in the online mall

The product quantity tampering test is to modify the ordered product quantity and other fields by capturing packets in the business process. For example, modify the product quantity in the request to any unexpected amount, negative number, etc. and submit it to see whether the business system can complete the modified quantity. Business Process.

This test is mainly aimed at the related business logic vulnerabilities caused by the lack of risk control mechanism for abnormal transaction data processing during the product ordering process. For example, the lack of judgment on the quantity, price, etc. in the ordering results in unexpected results, which are often exploited by attackers. .

3.1.5.1 Environment setup

Unzip the dami_5.4 compressed package and copy the contents to the www directory, visit dami_5.4

3.1.5.2 Process

Use bp's own browser to register and log in, registered user xj password 123456

Click on Rice to test the product, click on Buy Now to capture the package

Fill in the information, select on-site deduction, submit the order, and capture the package.

Change the quantity to -1 and put the package

Found that our balance changed from 0 to 6000

3.2 Password retrieval security

The user submits a request to change the password. If the attacker forges the request, he can try to change the password of others;
Account authentication: the server sends a unique ID (such as SMS verification code) where only the account owner can see it to complete the identity authentication;
Identity verification: the user submits a verification code to complete the identity verification;
Change password: User changes password.

3.2.1 Verification code client echo test

Typical scenario:

Any user login

Scenarios for using verification codes:

Man-machine verification: prevent machine operation and blast forms.
Unique credential: Unique judgment, any account login.

During the password retrieval test, pay attention to whether the verification code will be echoed in the response. Some website programs will choose to echo the verification code in the response to determine whether the verification code entered by the user is consistent with the verification code in the response. If so, will pass the verification.

3.2.2 Verification code brute force cracking

Typical Case:

There is no limit on the number of times the verification code can be used

The password retrieval function module usually sends user credentials (usually verification codes) to a collection number or mailbox that can only be seen by the user. As long as the user does not reveal his verification code, he will not be exploited by attackers. However, Some applications have weak verification code digits and complexity in the verification code sending function module, and do not limit the number of times the verification code can be used. As a result, the verification code can be violently enumerated and any user's password can be modified.

When testing whether the verification code can be violently enumerated, you can first send the verification code to your account multiple times and observe whether the verification code is regular. For example, the verification code received each time is a pure number and has 4 digits.

3.2.3 Response status value modification test

Response status value modification test, that isModify the response result of the requestTo achieve the purpose of password reset, websites or mobile apps with such vulnerabilities often lead to very dangerous password reset operations due to lax verification.

This kind of vulnerability is usually exploited after the server sends a credential request for password reset, and a specific response value appears, such as:

true
1
ok
success
200

After the website sees that the echo content is a specific value, it changes the password or logs in. Usually the echo value verification of this kind of vulnerability is performed on the client, so only the response packet of the server needs to be modified.

3.2.4 Session coverage

Session ID is also called session ID. The server uniquely identifies the browser client user identity.

During the password retrieval logic vulnerability test, we will also encounter situations where the parameters are uncontrollable. For example, the user name to be modified or the bound mobile phone number cannot be modified when submitting the parameters. The server determines that the password needs to be modified by reading the current session. account, in this case can the content in the session be modified to achieve the purpose of arbitrary password reset?

In the password retrieval function on a website, the business logic is: the user uses a mobile phone to reset the password, and then the server sends a verification code text message to the mobile phone. After the user enters the verification code and submits it, the user enters the password reset page.

The test of Session coverage in the website is as follows:

Open the browser, visit the password reset page, and submit your mobile phone number (133), and the browser receives the Session ID;
Use your own account (mobile phone number, 133) to receive the voucher (SMS verification code);
After the certificate verification is successful, enter the password reset page;
Reopen the password retrieval page in a new tab of the browser, enter the target mobile phone number (177), and the server will reissue the Session ID;
At this time, the current Session ID has been overwritten by the Session ID of 177 from the original Session ID of 133. Return to the reset password page opened in the third step to reset the password of the target mobile phone number.

Reason for the vulnerability:

After the verification code is verified, the Session ID is not updated in a timely manner, or the server-side SESSION information is not updated in a timely manner. SessionID must be bound not only to the mobile phone number, but also to the verification code.

3.2.5 Weak Token design defect testing

In the password retrieval function, many websites will send a link to the password retrieval page to the user's email address. Users only need to enter their mailbox and open the link in the password retrieval email to enter the password reset page. The link to retrieve the password usually adds a verification parameter to confirm the validity of the link, and judges whether the current link to retrieve the password is valid by checking whether the value of the parameter is consistent with the value generated by the database.

http://www.xxx.com/findpwd?uid=ajest&token=ajest-2021-1026-1324

3.2.6 Password retrieval process bypass test

The password recovery function of many websites generally has the following steps:

The user enters the account number to retrieve the password;
Verify credentials: Send a SMS verification code or a password retrieval link to the user, and the user fills in the verification code or clicks the link to enter the password reset page, thus proving that the current operating user is the account owner;
If the verification is successful, enter the reset password page (interface).

In the password recovery logic, the second step of verifying credentials is the most important. The account owner cannot receive the verification certificate. Is there any way to bypass the second step of the certificate verification and go directly to the third step to reset the password?

To change the password, the user needs to send a password change request to the server. After the server passes the request, the corresponding password in the database will be modified. Therefore, in the test, we first need to collect the three-step request interface, and the focus is to collect the interface for resetting the password in the last step. In this way, we can directly skip the credential verification interface and try to reset the password directly.

3.2.7 Interface parameter account modification

Typical Case:

metinfo_4.0 Any account password reset

In the logic of the password retrieval function, there are often parameters that pass the user account in the parameters submitted by the user to change the password. As a controllable variable, the user account parameter can be tampered with, resulting in the modification of the credentials or password of the account password. There is a deviation in the target account, which ultimately leads to the vulnerability of changing the password of any account.

Usually in the password retrieval logic, the server will ask the user to provide the account to be modified, and then send the account a certificate that only the account owner can see. For example, sending a verification code or a password retrieval link to the email address or mobile phone number bound to the account owner can ensure that only the account owner can see these credentials. However, if the server's control logic for the account is improper, it will cause the original account to be tampered with another account, and the server will send the voucher to the email or mobile phone of the tampered account, ultimately causing a vulnerability that can use the voucher to reset the password of any account.

The interface parameter account modification process test is to intercept the front-end request, modify the account ID, name or email, mobile phone number and other parameters in the request, and send the modified data to the server for deception to achieve the purpose of password reset.

Browser A (administrator) accesses metInfo4.0, and browser B (attacker) accesses metInfo4.0.

Browser A accesses the backend of metInfo4.0 and logs in as an administrator. Browser B accesses metInfo4.0 and registers as an ordinary user.

The attacker clicks to modify the basic information and changes the password to 654321, and uses bp packet capture to view the traffic.

The attacker sends the password-modifying data packet (POST packet) to the resender, changes the username to admin and clicks Send

Use browser A to log in to admin again, 654321

Landed successfully