I have relatively little practical experience, but I have participated in many CTF (Capture the Flag) competitions 🐶, which made me realize that my understanding of vulnerabilities is not deep enough. Therefore, I am preparing to start summarizing logical vulnerabilities first.
Referring to the experiences of experts, I have briefly summarized the mind map of logical vulnerabilities.
Analysis of Common Logical Vulnerabilities#
Arbitrary Password Recovery/Arbitrary Phone Number Modification#
Classic process:
Verify old phone number/old password -> Provide new phone number/password -> Submit modification
In the first step, if it is possible to modify the response package returned after verifying the original phone number or password, then this step can be bypassed. If the third step does not verify the success of the first step authentication, it is possible to bind any phone number or modify any password.
Concurrent Lottery/Check-in#
Concurrency issues in lottery and check-in processes can be exploited by replaying multiple times to accumulate login days and obtain multiple lottery tickets, etc.
The general solution is to use Compare and Swap (CAS) operations, which include three parameters:
- Memory location V
- Expected original value A
- New value B
CAS first checks if the current value in V matches A. If it matches, it updates it to B; otherwise, it does not perform any operation. The entire operation is atomic, ensuring synchronization.
Front-end JS#
By examining front-end JS, many points can be found, such as:
- Hidden interfaces
- JS source map files
Refer to this article for more information:
[https://xz.aliyun.com/t/9453]
Leakage of Login Status#
In some H5 and mini-program scenarios, many developers take shortcuts because the design of the login status is too complex, resulting in direct verification through openid and other methods.
There are many such cases, especially in the WeChat ecosystem.
Error Pages#
Error pages can also provide a lot of information. The most common use is template injection in CTF competitions.
In practical scenarios, error pages may leak a lot of sensitive information, such as login status 🐶 (I have actually encountered this).
Google Hacking Extension#
Now that we know so many logical vulnerabilities, how do we test them?
Using Google hacking syntax, we can find many websites and test them one by one. For example, if we are looking for payment functions, we can search like this:
inurl:m intitle:订单详情 inurl:id=
我的订单 订单详情
inurl:order 订单详情
inurl:wap intitle:订单详情
inurl:m intitle:订单详情
inurl:php intitle:订单详情
title:订单详情 手机号
site:.com title:订单详情
title:订单详情 身份证
By using this approach, we can find many actual payment websites and test them one by one.
If the vulnerability is more generic, we can write a POC and integrate it into Xray or other passive scanning tools.
I plan to share the exploration of these websites in the next article 🤔, but let's finish this one first.