Disclaimer: the following content only applies to those who put the card table and the return table in the same table!
Recently, we have started to rebuild the charging system of the VB. NET data center. Here we will talk about the vulnerabilities I found in the charging system of the data center.
In the IDC charging system, there is such a form-checkout. I personally think that the function of checkout is: the leader registers for the return card for the operator to settle the bill. Simply put, the leader collects the money. If you are an operator, recharge and return the card every day, you need to know how much you have made during this period.
The focus of today's discussion is the settlement of the card table! During the checkout, there is a purchase card and a return card. That is to say, for the same card, it needs to be checked out once after registration, and also needs to be checked out once after the card is returned.
Let's take a look at the card table design of my database:
Here, we should not worry about whether the card number is a primary key. The data type of each field is incorrect. Today, we mainly talk about things in the red box in the figure! If your registration and return are in a table, and your card table design does not have these four fields, I can tell you with certainty that your checkout has a vulnerability.
The following describes why there is a vulnerability without these four fields:
Generally, the design of the card table is like this. There is only one ischeck field and one handler field. In this way, if a card is in use or has not been checked out during the checkout, We can query it in the checkout-purchase card. Now let's check it out. The ischeck field of this record is changed to "checked out", and then we will perform the Back-to-card operation on this card! At this time, the return card is not checked out, but we cannot find it in the checkout-return card! Why? Now let's compare the SQL statements we use for queries:
Checkout-Card Purchase:
Select * From t_card where ischeck = 'uncheck' and [email protected]
Select * From t_card where regitsterischeck = 'unsettled 'and [email protected]
Checkout-return card:
Select * From t_card where status = 'do not use' and ischeck = 'uncheck' and [email protected]
Select * From t_card where status = 'do not use' and logoutischeck = 'uncheck' and [email protected]
By comparing these two SQL statements, we can know that, if you change the ischeck field to "checked" when you purchase a card, you cannot find this record when you check the card.
After the origin of the registerischeck and logoutischeck fields is completed, let's talk about the origins of registerhandler and logouthandler:
If there is only one handler field in our card table, if we buy a card at Operator 1 and return the card at operator 2, who should be the handler of the record at last?
Based on the above discussion, I believe you are very convinced of the origins of the four fields in the red box. If you have any questions, contact me to discuss them in private.
Data room billing system checkout Vulnerability
