1. Brute force cracking
1 Overview
"Brute force cracking" is an attack method. 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 for automated operations.
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。
2. Form-based brute force cracking
Condition: The user does not have any security verification, and can directly capture packets for brute force cracking.
3. Verification code bypass
Verification code bypass (on server): The verification code verification is completed on the server side, but the verification code has timeliness. At this time, we can capture packets within this time limit to bypass the verification code in a short time.
Verification code bypass (on client): Verify the verification code on the front end. At this time, enter the correct verification code to submit. After capturing the package, we found that we do not need to modify the verification code by modifying the password and account , thereby bypassing the verification code and realizing brute force cracking.
4. Is the token explosion-proof?
Since the token value is output in the source code of the front end, it is easy to be obtained, so it loses the meaning of explosion protection. We can obtain the value of the token generated by the front-end page during each brute force cracking process, so as to achieve brute force cracking.
5. Security Policy
1. Whether to require users to set complex passwords;
2. Do you use a secure verification code for each authentication (think about the verification code you entered when you bought a train ticket~) or a mobile app;
3. Whether to judge and restrict the behavior of attempting to log in (such as: 5 consecutive wrong logins, account lock or IP address lock, etc.);
4. Whether two-factor authentication is used;
Two, XSS
1. Introduction to basic concepts and principles
Cross-site scripting attack refers to an attack method in which an attacker controls a user's browser to perform malicious operations by tampering with a webpage and embedding a malicious script program when the user browses the webpage.
Cross-Site Scripting is referred to as "CSS" for short. In order to avoid conflicts with the abbreviation "CSS" of the front-end stacked style sheet, it is also called XSS. General XSS can be divided into the following common types:
1. Reflective XSS
Interactive data generally does not exist in the database, one-time, what you see is what you get, generally appear in the query
2. Stored XSS
The interactive data will be stored in the database for permanent storage, and generally appear on the message board, registration and other pages.
3. DOM type XSS
No data interaction with the background server is a problem that occurs when the front-end code is output through DOM operations, and it is also a reflection type at one time.
Cause
The main reason for the formation of xss vulnerabilities is that the program's control of input and output is not strict enough, resulting in "well-designed" scripts being input, which are executed by the browser as valid code when output to the front end, causing harm.
2. Cross-site scripting vulnerability testing process
(1) Find input points on the target site, such as query interfaces, message boards, etc.
(2) Enter a set of "special characters + unique identification characters", click submit, and check the returned source code to see if there is any corresponding processing.
(3) Locate the unique character by searching, and combine the grammar before and after the unique character to confirm whether the condition of js can be executed (construction closure).
(4) Submit the constructed script code (and various bypass gestures) to see if it can be successfully executed. If executed successfully, it means that there is an existing xss vulnerability;
TIPS：
(1) The general query interface is prone to reflective xss, and the message board is prone to storage type xss;
(2) Since there may be filtering measures in the background, the formed script may be filtered out, and the second cannot take effect, or the environment restricts execution (browser).
(3) Try to bypass the background filtering mechanism by changing different scripts.
3. Security Policy
(1) When inputting: strictly filter single quotes, double quotes, and angle brackets.
One thing to remember: don't trust anything that is typed. For example, the user name can only be a combination of letters and numbers, and the mobile phone number can only have 11 digits and all of them are numbers, otherwise it is illegal. These format checks are similar to the whitelist effect, restricting the characters allowed to be input, and making the attacks of special characters invalid.
(2) When outputting: convert single quotes, double quotes, angle brackets, etc. into HTML entities.
Three, csrf
1. Principle
CSRF (Cross-Site Request Forgery, cross-site forgery request) is a network attack method, which can forge a request in the name of the victim without the victim's knowledge and send it to the attacked site, so that the unauthorized Executing operations under the protection of permissions under certain circumstances is very harmful.
2. How to confirm that a web system is purely CRSF vulnerability
(1) Mark the additions, deletions, checks and modifications of the target website, and observe its logic to determine whether it can be forged
– For example, when modifying the administrator account, there is no need to verify the old password, which makes the request easy to be forged;
– For example, the modification of sensitive information does not use secure token verification, which makes the request easy to be forged;
(2) Confirm the validity date of the voucher (this problem will increase the probability of CRSF being used)
– Although the browser is exited and closed, the cookie is still valid, or the session has not expired in time, which makes the CRSF attack easier.
3. Defensive measures
(1) Verify the HTTP Referer field
(2) Add and verify the token in the request address, the backend generates a token and sends it to the frontend, and the frontend submits it to the backend for verification.
(3) Customize attributes in the HTTP header and verify
(4) Strictly distinguish between POST and GET data requests in the server area (it is recommended not to use GET requests for persistent operations)
(5) Use the verification code or password confirmation method to proceed
4. SQL Injection
1 Overview
2. Causes
What is SQL injection attack
The attacker injects malicious SQL code into the HTTP request. When the server uses parameters to construct database SQL commands, the malicious SQL is constructed together and executed in the database.
User login, input user name lianggzone, password' or '1'='1, if the method of parameter construction is used at this time, it will appear
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
No matter what the user name and password are, the user list that is queried is not empty. How to prevent SQL injection attacks It is necessary to use precompiled PrepareStatement, but generally we will start from two aspects at the same time.
Web side
1) Validity test.
2) Limit the length of the string input.
Server
1) No need to concatenate SQL strings.
2) Use a precompiled PrepareStatement.
3) Validity test. (Why does the server need to check the validity? The first criterion is that the outside world is untrustworthy to prevent attackers from bypassing web requests)
4) Filter the special characters in the parameters required by SQL. Such as single quotes, double quotes.
5. RCE
1. Overview of RCE (remote command/code execute)
The RCE vulnerability allows an attacker to remotely inject operating system commands or codes directly into the background server, thereby controlling the background system.
Remote System Command Execution
Generally, this kind of vulnerability occurs because the application system needs to provide users with a specified remote command operation interface from the design.
For example, the web management interface of our common routers, firewalls, intrusion detection and other equipment will generally provide users with a ping operation web interface. The user enters the target IP from the web interface. After submitting, the background will ping the IP address once. test, and return the test results, and if the designer does not implement strict security control when completing this function, it may cause the attacker to submit "unexpected" commands through this interface, so that the background can be executed, thereby controlling The entire backend server.
For example: 127.0.0.1 & ipconfig
Now many Party A companies have begun to implement automated operation and maintenance, and a large number of system operations will be operated through the "automated operation and maintenance platform". Vulnerabilities in remote system command execution often appear on this kind of platform. If you don’t believe me, you can find the system of your operation and maintenance department to test it now, and there will be unexpected "harvests".
shell_exec() is used to execute user-transmitted commands
remote code execution
In the same way, because of the requirement design, the background sometimes executes the user's input as part of the code, which causes a remote code execution vulnerability. Whether it is using a function for code execution, or using unsafe deserialization, etc.
Therefore, if you need to provide front-end users with operational API interfaces, you must strictly judge the content of the interface input. For example, implementing a strict whitelist strategy would be a better method.
eval() is used to execute the code transmitted by the user
6. The file contains loopholes
1 Overview
file contains, is a function. Various development languages provide built-in file inclusion functions, which allow developers to directly include (introduce) another code file in one code file.
For example, in PHP, it provides:
include(),include_once()
require(),require_once()
The include and require syntax is the same, except for error handling:
- require will generate a specified error (E_COMPLIE_ERROR) and stop the script;
- include will only generate a warning (E_WARNING), and the script will continue;
These files contain functions that are frequently used in code design.
In most cases, the code files included in the file include functions are fixed, so there are no security issues. However, sometimes, the code file included in the file is written as a variable, and this variable can be passed in by the front-end user. In this case, if not enough security considerations are taken, it may cause a file inclusion vulnerability. The attacker will designate an "unexpected" file for the containing function to execute, thereby causing malicious operations. According to different configuration environments, the file contains vulnerabilities into the following two situations:
**1. Local file inclusion vulnerability: ** can only include local files on the server. Since the files on the server are not controlled by the attacker, in this case, more attackers will include some fixed files. system configuration files to read system sensitive information. In many cases, local file inclusion vulnerabilities will be combined with some special file upload vulnerabilities to form greater power.
Protective measures: set a whitelist (the if function is set with "||")
**2. Remote file inclusion vulnerability: ** can include remote files through url addresses, which means that attackers can pass in arbitrary codes. Therefore, in the functional design of the web application system, try not to allow front-end users to directly pass variables to the containing function. If you must do this, you must also implement a strict whitelist policy for filtering.
Premise: php.ini configuration is required as follows
allow_url_fopen = on //open by default
Allow_url_include = on // off by default
Hazard: Files such as a one-word Trojan horse can be directly transmitted, resulting in the client being controlled.
2. Preventive measures
(1) In terms of functional design, try not to put the file corresponding to the file containing the function in the entire section for selection and operation;
(2) Filter various …/…/, http:// , https://
(3) Configure the php.ini configuration file
allow_url_fopen=off
allow_url_include=off
magic_quotes_gpc=on //gpc在
(4) Through the whitelist policy, the specified files are allowed to be included in the operation, and others are prohibited;
7. Unsafe file downloads and file uploads
1. File download
Many websites will provide the function of file download, that is, users can click the download link to download the file corresponding to the link. However, if the file download function is improper, the attacker may never obtain other sensitive files on the background server by constructing the file path (also known as: arbitrary file download).
Precautions
(1) Strictly filter and limit the incoming file name
(2) Strictly limit the directory for file downloads
2. File upload
Due to business function requirements, many web sites have file upload interfaces, such as:
(1) Upload an avatar picture (such as jpg, png, gif, etc.) when registering;
(2) Upload file attachments (doc, xsl, etc.);
However, in the background development, no security considerations were taken for the file function of file upload or flawed measures were adopted, which led to attackers bypassing security measures by some means and uploading some malicious files (such as a one-word Trojan horse). Thereby controlling the entire web background by accessing the malicious file.
3. File upload vulnerability testing process
(1) Upload the file as required in the place where the file is uploaded, and check the returned result (path, prompt, etc.)
(2) Try to upload different types of "malicious" files, such as xx.php files, and analyze the results;
(3) Check the html source code to see if there is an upload restriction on the front end through js, which can be bypassed;
(4) Try to use different ways to bypass; black and white list bypass/MIME type bypass/directory 0x00 truncation bypass, etc.;
(5) Guess or combine other vulnerabilities (such as sensitive information disclosure) to get the Trojan path, connection test
Precautions
(1) Do not use js on the front end to implement the upload strategy
(2) Restrict file uploads through the server
Perform multiple combined checks: such as file size, path, extension, file type, file integrity, or set a whitelist of file extensions.
Rename uploaded files in server storage (specify reasonable naming rules)
Perform permission control (such as read-only) on the directory where the server uploads files, and limit the harm caused by the execution of permission removal.
Eight, ultra vires loopholes
Due to the lack of strict judgment on user permissions, low-privileged accounts (such as ordinary users) can complete operations within the scope of high-privileged accounts (such as super administrators).
1. Horizontal ultra vires
User A and user B belong to the same level of users, but they cannot operate the other party's personal information. If user A exceeds the authority to operate the personal information of user B, it is called parallel unauthorized operation.
2. Vertical overreach
The authority of user A is higher than that of user B, and the situation where user B overrides the authority of user A is called vertical overreach.
3. Repair suggestion
- Verify all parameters from the client, focusing on parameters related to permissions, such as user ID or role permission ID.
- The session ID is bound to the authentication token and placed in the session of the server, not sent to the client.
- For the request involving the user's unique information after the user logs in, the ownership must be verified and checked every time, and the parameter of the random number is added to the sensitive information page to prevent the browser from caching the content.
- Divide the program into anonymous, authorized and administrative areas by matching roles and data functions.
- No parameters are used to distinguish administrators from normal users.
Nine, PHP deserialization
1. Serialize()
In layman's terms, serialization is to turn an object into a string that can be transmitted. For example, the following is an object:
class S{
public $test="pikachu";
}
$s=new S(); //创建一个对象
serialize($s); //把这个对象进行序列化
序列化后得到的结果是这个样子的:O:1:"S":1{s:4:"test";s:7:"pikachu";}
O:代表object
1:代表对象名字长度为一个字符
S:对象的名称
1:代表对象里面有一个变量
s:数据类型
4:变量名称的长度
test:变量名称
s:数据类型
7:变量值的长度
pikachu:变量值
2. Deserialize unserialize()
It is to restore the serialized string to an object, and then continue to use it in the next code.
$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}");
echo $u->test; //得到的结果为pikachu
常见的几个魔法函数:
__construct()当一个对象创建时被调用
__destruct()当一个对象销毁时被调用
__toString()当一个对象被当作一个字符串使用
__sleep() 在对象在被序列化之前运行
__wakeup将在序列化之后立即被调用
漏洞举例:
class S{
var $test = "pikachu";
function __destruct(){
echo $this->test;
}
}
$s = $_GET['test'];
@$unser = unserialize($a);
payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
Ten, xee vulnerability
1 Overview
"XML External Entity Injection Vulnerability".
To sum up, "the attacker injects the specified xml entity content into the server, so that the server executes according to the specified configuration, causing problems", that is to say, the server receives and parses the xml data from the client, but does not do anything. Strict security controls, resulting in xml external entity injection.
2. Preventive measures
1. Use the method provided by the development language to disable external entities
2. Filter the XML data submitted by the user
Keywords: <!DOCTYPE and <!ENTITY, or, SYSTEM and PUBLIC.
Eleven, ssrf vulnerability
1 Overview
SSRF (Server-Side Request Forgery: Server-side request forgery) is a security hole constructed by an attacker to form a request initiated by the server. Use a server with permission to attack a server without permission.
2. Protective measures
1. Filter the returned information, if the web application is to obtain a certain type of file. Then verify whether the returned information meets the standards before displaying the returned results to the user.
2. Unify the error information to prevent users from judging the port status of the remote server based on the error information.
3. Limit the requested port, such as 80, 443, 8080, 8090.
4. Prohibit uncommon protocols and only allow http and https requests. It can prevent problems caused by files:///, gopher://, ftp://, etc.
5. Use DNS cache or Host whitelist.
12. Directory traversal (…/…/)
1 Overview
In web function design, many times we will define the files that need to be accessed as variables, so that the front-end functions will be more flexible. When the user initiates a front-end request, the value of the requested file (such as the file name) will be passed to the background, and the corresponding file will be executed in the background. During this process, if the background does not have strict security considerations for the values passed in from the front end, the attacker may use ".../" to make the background open or execute some other files. As a result, the file results of other directories on the background server are traversed, forming a directory traversal vulnerability.
13. Sensitive Information Leakage
Due to the negligence of background personnel or improper design, data that should not be seen by front-end users is easily accessed.
For example:
—By accessing the directory under the url, you can directly list the file list under the directory;
— After entering the wrong url parameter, the error message contains the version of the operating system, middleware, development language or other information;
— The front-end source code (html, css, js) contains sensitive information, such as the background login address, intranet interface information, and even account passwords;
Similar to the above situations, we have become a leak of sensitive information.
14. URL redirection
1 Overview
The problem of unsafe url jumps may occur in all places where url address jumps are performed. If the backend uses the parameters passed in from the frontend (maybe the user passed the parameters, or the url address previously embedded in the frontend page) as the jump destination, and if no judgment is made, "jump to the wrong object" may occur The problem.
2. Harm
–> Phishing, that is, the attacker uses the domain name of the vulnerable party (for example, a relatively well-known company domain name often allows users to click with confidence) to cover up, and the final jump is indeed a phishing website.
3. Preventive measures
whitelist restrictions
Directory, you can directly list the file list under the directory;
— After entering the wrong url parameter, the error message contains the version of the operating system, middleware, development language or other information;
— The front-end source code (html, css, js) contains sensitive information, such as the background login address, intranet interface information, and even account passwords;
Similar to the above situations, we have become a leak of sensitive information.
14. URL redirection
1 Overview
The problem of unsafe url jumps may occur in all places where url address jumps are performed. If the backend uses the parameters passed in from the frontend (maybe the user passed the parameters, or the url address previously embedded in the frontend page) as the jump destination, and if no judgment is made, "jump to the wrong object" may occur The problem.
2. Harm
–> Phishing, that is, the attacker uses the domain name of the vulnerable party (for example, a relatively well-known company domain name often allows users to click with confidence) to cover up, and the final jump is indeed a phishing website.
3. Preventive measures
whitelist restrictions