Common security vulnerabilities and defense in Financial Industry platforms (1)
I. Preface
Internet finance is an emerging term in the financial industry over the past two years and an important branch of the Internet industry. However, internet finance is not a simple combination of the Internet and the financial industry, instead, it is a new model and business created to meet new requirements after being familiar with and accepted by users in terms of security, mobile, and other network technologies, in addition to common online banking and third-party payments, many private financing and loan platforms have gradually emerged over the past two years, such as P2P online lending and crowdfunding. The more money-related business, the more sensitive it is. As we all know, in addition to the powerful capital chain, the platform's credibility is also critical, when security problems occur on some financial platforms, more and more such platforms are gradually aware of the importance of security.
We were invited to inspect some Internet Financial Transaction platforms on the Internet. During the detection, we found that some platforms had serious security problems, in this topic, we will summarize some common security problems we have found and propose corresponding solutions to improve the Code security capability of developers.
Ii. Security Vulnerability Analysis
2.1 statistics
We conducted a vulnerability statistics on several financial transaction platforms, except for some common Web vulnerabilities such as injection, cross-site, CSRF, and malicious uploads, some financial platforms have serious risks in terms of business functions, such as resetting passwords of arbitrary users and tampering of transaction parameters, which are different from common injections and malicious uploads, these business logic vulnerabilities do not directly affect the security of servers, but directly affect the security of users' funds and accounts. The risk level has never been met, if exploited or exposed by hackers, the credibility of the platform will be seriously affected.
We have made statistics on common vulnerabilities, and found that the proportion of unauthorized operations is the highest. Basically, we have found these vulnerabilities on the platforms we have tested, this includes arbitrary user information query and deletion. The most serious vulnerability occurs in account security, including resetting any user password and brute-force cracking of verification codes. Below we will introduce some common security problems and their solutions in an example.
2.2 unauthorized operations
Vulnerability description
Parallel unauthorized operations are a common security vulnerability, which is also mentioned in OWASP Top 10, which are insecure object reference and lack of function-level access control.
Insecure Object Reference refers to the lack of access control for parallel permissions. For example, the personal data of common users A and B on the same website is kept confidential, user A's personal data can be maliciously viewed by user B using the lack of program Access Control. Because user A and user B are accounts of the same level, access control with parallel permissions is missing. Lack of function-level access control refers to the lack of vertical access control. For example, account A is A normal account and Account B is an administrator account, the management page of Account B must be viewed only after logging on to the Administrator. However, account A can directly enter the management page URL to bypass the Administrator Logon restriction and view the management page, because the permissions of user A and user B are vertical, access control called vertical permissions is missing. This type is a security problem caused by business design defects. Therefore, Traditional scanners cannot discover this type. They can only perform inspection through manual penetration tests. The lack of parallel access control is common in financial platforms.
Case
On the financial transaction platform, this type of security vulnerability mainly occurs in account balance query, account personal data tampering, and other functions. Below are some simple cases to illustrate.
(1) Any modification to user information
Users of a transaction platform can modify their personal nicknames and portraits on the personal data modification page of the system.
Capture the data packets that send the modification request for analysis. We found that during the submission process, the request actually comes with a hidden parameter investor. loginName, in fact, investor. loginName is the mobile phone number (or user name) for logon, investor. name is the reset username. You can directly modify the parameter investor. loginName is a registered username or mobile phone number.
(2) Arbitrary query of user information
During the test of the financial transaction platform, we found that most platforms did not optimize the query function. the user's uid and other account flag parameters were used as the query keywords, the query range is not controlled, resulting in any information query security vulnerability. This type of vulnerability is common on mobile clients. For example, in a mobile marketplace on a transaction platform, you may find any security issue for querying other user information.
When you click the personal data modification area of the mall, the system submits the current user's phone_client_uuid to the server for query and calls out the personal data content.
However, because the system does not control access to this function, you can traverse the uuid to query the information of any user on the platform, and use a tool to crack the last five digits of phone_client_uuid, for example:
By filtering the returned value length, the user information corresponding to phone_client_uuid is found.
Code Protection
For the lack of access control for parallel permissions, we recommend that you use indirect object reference based on the user or session for protection. For example, an option contains six resources authorized to the current user, it can use a special number or string to indicate which value is selected by the user, rather than the database keyword of the resource. The generation of numbers and strings can be combined with account information, this makes it difficult for attackers to guess how the data is generated.
For the lack of access control for vertical permissions, we recommend that you use the default deny all access mechanisms. Then, you can explicitly grant access permissions to specific roles for each function access, when a user uses this function, the system should proofread the user's permissions and access control mechanism.