Application security
Loophole
Code vulnerability
XSS script injection
XSS attack is one of the most common attack methods in web attacks. It achieves the purpose of the attack by injecting executable code into the webpage and successfully executed by the browser, forming an effective XSS attack. Once the attack is successful, it can obtain The user’s contact list, and then send false fraud information to the contact, you can delete the user’s log, etc. Sometimes, it also implements phishing with other attack methods such as SQL injection attacking the server and database, Click hijacking, and relative link hijacking. The harm it brings is huge, and it is the number one enemy of web security.
What can XSS attacks do?
1. Cookie hijacking
Using browser plug-ins, you can obtain the cookie information in the request, and read the user's private information from the obtained cookie information.
2. Simulate GET and POST requests to operate the user's browser.
This method is very useful when using JavaScript to simulate browser packet "Cookie hijacking" failure, or the target user's network cannot access the Internet, etc.
3. XSS Phishing
Use JavaScript to "draw" a fake login box on the current page. When the user enters the user name and password in the login box, the password will be sent to the hacker's server
4. Obtain user browser information. The
JavaScript script reads the browser's UserAgent object through XSS to identify the browser version. alert (navigator.userAgent)
distinguishes implementation differences between browsers through JavaScript scripts
5. Identify the software installed by the user
. Determine whether a certain software or a certain plug-in is installed by querying whether certain attributes exist
6. Use CSS to discover the websites the user has visited.
Use the visited attribute of style to determine whether the link has been visited
7. Hijack the browser session to perform arbitrary operations, such as illegal transfers, forced posting of logs, sending emails, etc.
8. Force pop-up advertising pages, brush traffic, etc.
9. Conduct a large number of client attacks, such as DDoS attacks
10. Get the real IP of the user's computer
We also encountered XSS script injection before in our project, but we didn't know the term at that time, until a technical forum shared the explanation of the name last week. We enter in the input box on the front page <script>alert(111)</script>, and a pop-up window appears when reading the content of the interface. Of course, this is just a non-malicious test. Our processing method is to filter the type of characters like <and >, of course, it can also be escaped, depending on the project requirements.
CSRF cross-site request forgery
As can be seen from the above figure, to complete a CSRF attack, the victim must complete two steps in sequence:
1. Log in to trusted website A and generate a cookie locally.
2. Visit the dangerous website B without logging out of A.
At present, there are three main strategies for defending against CSRF attacks: verifying the HTTP Referer field; adding a token to the request address and verifying (form token verification); customizing attributes and verifying in the HTTP header.
1. Try to use POST and limit GET
The GET interface is too easy to be used for CSRF attacks. Looking at the first example, you can know that you only need to construct an img tag, and the img tag is data that cannot be filtered. The interface is best limited to POST, GET is invalid, reducing the risk of attack. (The difference between get and post: https://blog.csdn.net/qq_42806764/article/details/86596589?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none- task-blog-BlogCommendFromMachineLearnPai2-1.channel_param) Of course POST is not foolproof. Attackers only need to construct a form, but it needs to be done on a third-party page, which increases the possibility of exposure.
2. Add verification code
The verification code forces the user to interact with the application to complete the final request. Under normal circumstances, the verification code can well contain CSRF attacks. However, due to user experience considerations, the website cannot add verification codes to all operations. Therefore, the verification code can only be used as an auxiliary means, not as the main solution.
3、Referer Check
The most common application of Referer Check on the Web is to "prevent image hotlinking". In the same way, Referer Check can also be used to check whether the request comes from a legitimate "source" (whether the Referer value is a specified page, or the domain of the website). If neither is, then it is most likely a CSRF attack. However, because the server does not always get the Referer, it cannot be used as the main means of CSRF defense. However, it is a feasible method to use Referer Check to monitor the occurrence of CSRF attacks.
4 、Anti CSRF Token
Now the industry's consistent approach to CSRF defense is to use a Token (Anti CSRF Token).
Example: The
user visits a certain form page. The server generates a Token and places it in the user's Session or the browser's Cookie. Attach the Token parameter to the page form. After the user submits the request, the server verifies whether the Token in the form is consistent with the Token in the user's Session (or Cookies). If it is consistent, it is a legal request, and if it is not, it is an illegal request. The value of this token must be random and unpredictable. Due to the existence of the Token, the attacker can no longer construct a request with a valid Token to implement a CSRF attack. In addition, you should pay attention to the confidentiality of the token when using the token, and try to change the sensitive operation from GET to POST, and submit it in form or AJAX to avoid Token leakage.
This piece has not been encountered in the current project. After reading the general meaning, I will try to reproduce it when I have the opportunity.
SQL injection
SQL injection is more common, for example:
execute a SQL, as follows:
String sql = "select * from user_table where username =
' "+userName+" ' and password =' "+password+" '"
-When the above user name and password (or 1 = 1, 123456) are entered, the above SQL statement becomes:
SELECT * FROM user_table WHERE username = or 1 = 1 and password= 123456
At this point, this sql will be executed successfully anyway, successfully bypassing the user name and password verification and obtaining the information in the database, and even delete or manipulate the data in the database.
This sql example is a very common problem. At the same time, development in the company currently uses a more mature framework for development, so basically you will not encounter such problems, but how to successfully perform sql injection under the framework of mybatis?
That is the use of parameter acquisition ${param}. We used ${param} in many places in the project to obtain parameter values. Later, we discovered that there would be a problem of SQL injection, and #{param} can avoid this problem.
Clear text transmission
Plain text means unencrypted text. For example, the http protocol, the http website we often visit is plaintext transmission. If the packet is captured, the information inside will be directly exposed. Because there is no encryption, it is very insecure. At present, more and more websites use https, s is safe and secure. This means that the https protocol is encrypted during transmission, which is much safer. Nowadays, some browsers open the http website and directly say that the website is not safe for this reason. Our project uses the base64 encryption method, which may not be very secure. It needs further enhancement. I haven't touched the login and security section. I will add it after learning.
Ultra vires
Data ultra vires
I found a circle of information. There are very few data ultra vires, but some information was found. Regarding horizontal ultra vires, data ultra vires should also be called horizontal ultra vires. Horizontal overreach can also be referred to as an access control attack vulnerability. When the web application receives the user's request, we do not judge the user corresponding to the data when we add, delete, modify, and check a piece of data, or when we judge the user of the data, it is achieved by obtaining the userid from the user form parameter. Here If so, we can modify the userid to achieve level ultra vires.
Function ultra vires
Vertical overreach is also called a privilege escalation attack. The specific reason is that the web application does not control user privileges, or only performs privilege control on the menu. As long as malicious users guess the URL of other management pages, they can access or control other roles. Data or pages to achieve the purpose of privilege escalation. This piece has not been done in the current project, but it will be realized in the follow-up work arrangement, to be added.
Error log output
Due to the time relationship, the sharer did not share, personal guess is related to the log output level setting.
URL injection
URL injection attacks are similar to XSS cross-site and SQL injection, and are also an attack method with controllable parameters. The essence of URL injection attacks is that URL parameters are controllable. The attacker can modify the URL address to a controllable address constructed by the attacker to achieve the purpose of the attack.
The number of login errors is not controlled
The main purpose is to prevent brute force cracking with tools, which is very common in daily life.
No verification code or verification SMS is added to the login and submission pages
It is also to prevent brute force cracking and effectively prevent this problem from continuously logging in to a specific registered user with a specific program brute force cracking method.
Weak password
The password is simple and easy to crack, such as: name + birthday. Common weak passwords are divided into default weak passwords and social work weak passwords. For our ordinary users, it is mainly a weak social work password.
File upload vulnerability
Most websites and application systems have upload functions. Some file upload function implementation codes do not strictly limit the file suffixes and file types uploaded by users, allowing attackers to upload arbitrary PHP files to a directory accessible through the Web, and can By passing these files to the PHP interpreter, any PHP script can be executed on the remote server.
When there are file upload vulnerabilities in the system, the attacker can upload viruses, Trojan horses, WebShell, other malicious scripts, or pictures containing scripts to the server. These files will facilitate the attacker's subsequent attacks. According to the difference of specific vulnerabilities, the scripts uploaded here can be PHP, ASP and JSP scripts with normal suffixes, or these scripts after tampering with the suffixes.
When the uploaded file is a virus or Trojan horse, it is mainly used to trick users or administrators into downloading and executing or directly running automatically;
When the uploaded file is WebShell, the attacker can execute commands and control the server through the backdoor of these web pages;
When the uploaded file is another malicious script, the attacker can directly execute the script to attack;
When the uploaded file is a malicious image, the image may contain a script, and the script will be executed silently when these images are loaded or clicked;
When the uploaded file is a malicious script disguised as a normal suffix, an attacker can execute the file with the help of the Local File Include vulnerability. For example, rename the bad.php file to bad.doc and upload it to the server, and then execute it through PHP's include, include_once, require, require_once and other functions.
There are three main reasons for malicious file upload here:
The file was not checked strictly when uploading. No file format check is performed. Some applications are only checked on the client side, and in the eyes of professional attackers, almost all client side checks are equivalent to no checks. Attackers can easily bypass the client side checks by using breakpoint upload tools such as NC and Fiddler. Although some applications have performed a blacklist check on the server side, they may ignore the case, such as changing .php to .Php to bypass the check; some applications have performed a whitelist check on the server side but ignore %00 The truncation character, if the application originally only allows uploading of jpg images, then the file name can be constructed as xxx.php%00.jpg, where %00 is the 0x00 character in hexadecimal, and .jpg has deceived the application’s upload file type detection. But for the server, because of the %00 character truncation, the final uploaded file becomes xxx.php.
Improper handling when modifying the file name after the file was uploaded. Some applications carry out complete blacklist and whitelist filtering on the server side, but when modifying the file name of the uploaded file, the file name is completely sparse, allowing users to modify the file suffix. For example, when the application can only upload .doc files, the attacker can first modify the .php file suffix to .doc, and then change the suffix back to .php when modifying the file name after successful upload.
Introduced when using third-party plug-ins. Many applications refer to third-party plug-ins with file upload functions. These plug-ins may have loopholes in the file upload function. Attackers can use these loopholes to carry out file upload attacks. For example, the famous blogging platform WordPress has a wealth of plugins, and a large number of file upload vulnerabilities are discovered every year in these plugins.
Leakage of sensitive information
As a fairly simple but powerful client-side scripting language, JavaScript is essentially an interpreted language. Therefore, its execution principle is to run while explaining. The above characteristics determine that JavaScript is different from some server scripting languages (such as ASP, PHP) and compiled languages (such as C, C++), and its source code can be easily obtained by anyone. Some careless developers store all kinds of sensitive information in JavaScript scripts. Due to the characteristics of JS, attackers can have a clear view of this information, resulting in varying degrees of threats to WEB services and user privacy.
Directory traversal
1. What is a directory traversal vulnerability?
Directory traversal (path traversal) is a security vulnerability caused by insufficient security verification of the file name entered by the user by the web server or web application, allowing the attacker to use some special characters. Bypass the security restrictions of the server, access any files (you can make files outside the web root directory), and even execute system commands.
2. The principle of directory traversal vulnerabilities The
program does not fully filter the directory jump symbols such as …/ input by the user in its implementation, causing malicious users to traverse any file on the server by submitting the directory jump.
3. Example of directory traversal vulnerability
Read the url of the file:
http://www.test.com/my.jsp?file=abc.html
Malicious url:
http://www.test.com/my.jsp?file=…/…/Windows.system.ini
4. Defense against directory traversal vulnerabilities
1. Verify the user's input, especially the path substitution character ".../"
2. Use the whitelist as much as possible to verify all inputs
3. Reasonably configure the directory permissions of the web server
4. Don't display internal related details when there is a program error
V. Scenarios
appearing in the file reading or displaying pictures and other functional blocks that interact with the file reading.
Summary: In contrast to each point, I found that many problems exist in my current project, indicating that we still have a lot of work to do with regard to web security. This may also be the drawback of many small and medium-sized Internet company projects at present, and it is not enough. Pay attention to safety. I hope that in the next work, I can work with the team to improve the security.