Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you the analysis and solution of database access control. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Database access control

Rule description

Database access control means that the program does not carry out proper access control and executes a SQL statement containing the user control primary key. Because the server has too much trust in the data operation request put forward by the client and ignores the judgment of the user's operation authority, it can have the functions of adding, deleting, querying and changing other accounts by modifying the relevant parameters. If in an application, the user can access the functions or resources that he does not have access to, it means that the application has access control defects and ultra vires vulnerabilities.

Vulnerability hazard

Database access control uses the parameters introduced by users to generate SQL statements in which the primary key is controlled by users, so that attackers can access the resources of users at the same level or those of higher-level users, which will lead to the disclosure of sensitive information of any user and the malicious modification or deletion of user information. Database access control is similar to database ultra vires. For example, sensitive information such as login name, login password, mobile phone number and ID card is returned in the server response of a certain page. If there is database access control, the sensitive information of all users can be viewed by traversing the user ID. This is also a disguised way out of the library, and it is difficult to be found by the firewall, because it is no different from normal access requests and does not contain special characters. Is full of secrecy.

Rectification and reform plan

Defect code

In the above sample code lines 31-56, the program takes the parameter id entered by the user, converts the incoming parameter to int type, and then creates a database query to query the list data in which uid is the incoming parameter id. Obviously, the incoming parameters are not checked and filtered in the program, and the user can get any user's list data at will.

The pollution source and data flow direction of the data can be analyzed from the tracking path, and the defect is reported in line 53 of the code line.

Fix the code:

In the above repair code, in line 34, the value of id is obtained directly from session to construct the query statement to obtain the list data of the current user, so as to prevent the user from manipulating the primary key value of the SQL statement.

Supplement the complete solution:

Two necessary conditions that make up this vulnerability occur:

1. Parameters from the user or the front end participate in the background operation of the database statement (the data enters the program from an untrusted data source).

2. This parameter is used as the primary key of the database table (this data is used to specify the value of the primary key in the SQL query. )

Three solutions:

Do not use parameters from the user or front end to do relevant SQL operations (for example: read the value in session to build SQL (usually use session to take user id to build user list, but if the id that produces vulnerabilities is not user id, for example: orgid,roleId, when store id fetches organization and store information, it also needs to ensure that the primary key comes from a trusted data source: backend or database, etc.)

This parameter is not used as the primary key for SQL-related operations. (use a secondary id that is inconsistent with the primary key)

Example: query SQL statement in figure 1

Figure 1

The org_id queried in figure 2 is not used as the primary key id, but as the secondary id.

Figure 2

And check the inconsistency of the primary and secondary id in figure 3.

Figure 3

3. Refer to the official solution of fortify.

A restriction has been attached to verify that the list belongs to the currently authenticated user.

...

UserName = ctx.getAuthenticatedUserName ()

Id = Integer.decode (request.getParameter ("invoiceID"))

String query =

"SELECT * FROM invoices WHERE id =? AND user =?"

PreparedStatement stmt = conn.prepareStatement (query)

Stmt.setInt (1, id)

Stmt.setString (2, userName)

ResultSet results = stmt.execute ()

...

As in the sample code above: add a query restriction for a user name (user id is not recommended) to match whether the user has ownership of the query.

The above three solutions:

Scenario 1: music-> limits the conditions that make up the vulnerability.

Scenario 2-> limits the conditions that make up the vulnerability 2

Scheme 3mura-> limits the possibility of ultra vires.

The above is the parsing and solution of database access control shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.