1. Shooting range construction
Download tool: phpstudy
Pikachu target drone download address:
https://github.com/zhuifengshaonianhanlu/pikachu
After downloading, unzip it and put it into the following folder (website root directory)
It is recommended to change the file name to pikachu
Modify configuration file (mysql username: root password: root save)
Let me emphasize: the database password defaults to root. If you change the database password, you need to change it here.
After modification, save and install the initialization interface.
Click Install/Initialize. When the following interface is displayed, the installation is completed.
2. Customs clearance tutorial
Module 1: Brute force cracking
"Brute force cracking" is an attack tool. In web attacks, this method is generally used to obtain the authentication information of the application system. The process is to use a large amount of authentication information to try to log in on the authentication interface until the correct result is obtained. In order to improve efficiency, brute force cracking generally uses tools with dictionaries to automate operations.
Form-based brute force cracking
First try to use burp brute force cracking
Open burp and enable proxy interception. It is recommended to use the Firefox browser plug-in, or set up the network in the browser.
After turning it on, just enter the account and password to capture the packet. After capturing the packet, right-click to send it to the intruder module.
Clear all variables, and then add variables for the account number and password.
Then add the dictionary, add two load sets, and import the account and password dictionaries respectively.
Then start the attack. After the attack is completed, the correct account number and password can be obtained based on the length returned.
Source code analysis
You can see that it is directly determined whether the account and password match those in the database. There are no other control measures, so it can be cracked through brute force.
Verification code bypass (on server)
Compared with the previous level, a verification code has been added. Here I would like to share with you the role of adding a verification code
1. Prevent login brute force cracking
2. Prevent malicious registration of machines
Approximate authentication process of verification code:
The client requests the login page, and the verification code is generated in the background:
1. The background uses an algorithm to generate pictures and responds to the client;
2. At the same time, globally assign the value generated by the algorithm and save it in SESSION;
Verification verification code:
1. The client will combine the authentication information and verification code together. Submit;
2. The background compares the submitted verification code with the one in SESSION;
The client refreshes the page and generates a new verification code again: a>
The verification code algorithm generally contains a random function, so it will change every time it is refreshed;
Next, we enter the verification code and account password to continue capturing packets.
Play the package a few more times to check the results. It turns out that only the account password error was reported and no verification code error was reported, which means that the verification code has not expired. We can continue the method of the first level and continue the brute force cracking. The steps are the same as above and will not be demonstrated again. .
Source code analysis
It can be seen that the session'vcode' is not destroyed after the verification is completed, so the verification code can be reused.
Verification code bypass (on client)
It can be observed that no http request is sent, and the verification code is verified on the js front end.
Note that the verification code is not verified on the server side, and is directly blasted as in the previous level.
Is the token explosion-proof?
Added token authentication in this level
Let’s first understand token
The process of token-based authentication is as follows:
1. The user sends a request via username and password.
2. Server-side program verification.
3. The server-side program returns a signed token to the client.
4. The client stores the token and carries the token to the server every time it accesses the API.
5. The server verifies the token. If the verification is successful, the request data will be returned. If the verification fails, an error code will be returned.
Sending a token in the request instead of a cookie can prevent CSRF (cross-site request forgery). Even if a cookie is used to store tokens on the client, the cookie is only a storage mechanism and not used for authentication. Not storing information in Session allows us to operate less sessions.
The token is time-limited and the user needs to re-verify after a period of time.
Because the token is random, the token also needs to be cracked when cracking.
First capture the packet and you can see that there is a token
After clearing the variables, apply variables to the password and token
The next steps are similar to
General approach:
1. Output the token in the form in the form of "type='hidden''";
2. Submit it together with the authentication and verify it in the background;
However, because its token value is output in the front-end source code, it is easy to obtain, so it loses its defense. The meaning of brute force cracking. Generally, Token has a better effect in preventing CSRF. The details will be explained in the CSRF vulnerability chapter.
Module 2: XSS (cross-site scripting)
Module 3: CSRF (cross-site request forgery)
Module 4: Sql Inject (SQL injection)
In the top 10 rankings released by owasp, injection vulnerabilities have always been the number one vulnerability. Among them, the first one to bear the brunt of injection vulnerabilities is database injection vulnerabilities.
A serious SQL injection vulnerability may directly lead to the bankruptcy of a company!
The main reason for the SQL injection vulnerability is that during data interaction, when the front-end data is passed to the background for processing, strict judgment is not made, resulting in the incoming "data" being spliced into SQL statements. After that, it is executed as part of the SQL statement. This results in the database being damaged (being stripped, deleted, or even the entire server's permissions compromised).When building code, the following strategies are generally adopted to prevent SQL injection vulnerabilities:
1. Filter the variables passed into the SQL statement to prevent danger. Characters are passed in;
2. Use parameterization (Parameterized Query or Parameterized Statement);
3. Also, there are currently many ORM frameworks that automatically use parameters. It solves the injection problem, but it also provides a "splicing" method, so you need to be careful when using it!