Today I learned some common Web attack methods, such as XSS attack, CSRF attack, SQ L injection attack, DDos attack and so on. XSS attacks, CSRF attacks, SQL injection attacks and other attacks are relatively easy to defend against. For enterprises, it is more necessary to guarantee from the development process, so as not to cause losses due to human negligence. As for DDos attacks, there are various means of attack and great impact and harm. Defending against DDos attacks is also a complex system engineering, which requires continuous defense drills, emergency plans, and effective monitoring. I will introduce them one by one:
1.XSS(Cross Site Scripting, named XSS to avoid CSS repetition)
It means that an attacker inserts malicious scripts into a web page. When a user opens a web page, the script is executed to obtain the user’s cookie, user name and password, download viruses, and even obtain admin permission. Is one of the most common Web attacks.
It works like this, for example, in a web page there is a form called Nick that is used to submit information about the site’s users to the server. The content of the form Nick comes from user input when, instead of a normal nickname string, the user enters “/>
Insert a script after the input box. Of course, this script just pops up a” haha” message box, which does no harm. The attack power depends on the type of script the user enters.
An attacker can use URLEncode on the URL, as shown in Figure 3-2, to confuse users and make it look like a normal promotion link. In addition, the URL can be promoted by mass email or other forms. Once clicked by users, the script will be executed on the client, causing harm to users.
Solution: XSS happens because the data entered by the user becomes code. Therefore, we need to the user input number, according to HTML escape processing, the “Angle bracket”, “single quotation mark”, “quotation mark” and other special characters escape encoding.
Perform HTML transfer processing. Escape the special characters of parentheses, single and double quotes.
CRSF attack (Cross Site Request Forgery)
Cross Site Request Forgery (CSRF) is a malicious exploitation of a website. Although it sounds similar to XSS cross-site scripting, IN fact, CSRF is very different from XSS. XSS exploits trusted users within a site. CSRF exploits trusted web sites by masquerading requests from trusted users. You can think of a CSRF attack this way: An attacker steals your identity and sends malicious requests to third-party websites on your behalf. CRSF can use your identity to email, text, transfer transactions, and even steal your account.
- CRSF attack principle
As shown in the figure, malicious site B impersonates user C to request site A, and can do some operations such as sending emails, SMS, payment and messages. After the victim logs in to site B, the attacker can launch CSRF attacks: • Logs in to trusted site A and generates cookies locally; • Access malicious site B without logging out of site A(clearing cookies from site A)
Here’s an example:
Assume that A bank website A initiates A transfer operation with GET request. The transfer address is www.xxx.com/transfer.do?accountNum=10001&money=10000. Parameter accountNum indicates the destination account of the transfer, and parameter money indicates the amount of the transfer. On a large forum B, a malicious user uploaded a picture, and the address bar of the picture was not the address of the picture, but the address of the transfer mentioned above:
Suppose the bank changes its transfer method to POST submission, and forum B happens to have an XSS vulnerability, where a malicious user inserts the following code on its page:
Solution: (1) Set cookies to HttpOnly
CRSF attacks largely make use of browser cookies. In order to prevent site XSS vulnerabilities from stealing cookies, it is necessary to set the “HttpOnly” attribute in cookies. In this way, programs (such as JavaScript scripts and applets) cannot read cookie information, avoiding the occurrence of forged cookies by attackers.
SetHeader (” set-cookie “, “Cookiename = cookievalue; response.setheader (” set-cookie “,” Cookiename = cookievalue; HttpOnly”);
(2) increase the token
The reason why CSRF attack can be successful is that the attacker can forge the user’s request and all the user authentication information in the request is stored in the cookie. Therefore, the attacker can directly use the user’s cookie to pass the security authentication without knowing the user authentication information. Therefore, the key to resist CSRF attacks is to put information in the request that the attacker cannot forge, and that information does not exist in the cookie. In this way, the system developer can add a randomly generated token in the form of a parameter in the HTTP request and verify the token on the server. If there is no token in the request or the token content is incorrect, the request is considered as a CSRF attack and rejected.
Add token to session
(3) Identification by Referer (not commonly used)
According to the HTTP protocol, there is a field in the HTTP header called Referer that records the source address of the HTTP request. Often, requests to a page with restricted security come from the same site. Such as a bank transfer is done by the user to access http://www.xxx.com/transfer.do page, the user must first log on to www.xxx.com, then click the submit button on the page to trigger events. When a user submits a request, the Referer value of the transfer request is the URL of the page where the submit button is located (www.xxx.com/transfer.do in this case). If an attacker wants to carry out a CSRF attack on a bank’s website, he can only construct a request on another website, and when a user sends a request to the bank via another website, the value of the request’s Referer is the address of the other website, not the address of the bank’s transfer page. Therefore, to defend against CSRF attacks, bank websites only need to verify the Referer value of each transfer request. If the address starts with www.xxx.com domain name, it means that the request is from the bank website itself and is legitimate. If the Referer is any other site, it could be a CSRF attack, and the request is rejected.
String Referer = request.getheader (“Referer”)
3.SOL injection attack (extremely harmful)
The so-called SQL injection is to disguise SQL commands as normal HTTP request parameters and pass them to the server to deceive the server into executing malicious SQL commands to achieve the purpose of intrusion. Attackers can use SQL injection vulnerability to query unauthorized information, modify the data of the database server, change the table structure, and even obtain the root permission of the server.
For example, in the input of the login, set the password to:
‘or 1=1’;
When executed, it will become: Select * from hhuser where Nick =’zhangsan’and passwords =’ or ‘l’=’l’ select* from hhuser where Nick =’zhangsan’and passwords =’ or ‘l’=’l’
How about this? Type ‘; in the password box. drop table aaa; — select * from hhuser where nick = ‘zhangsan’and passwords =”; drop table aaa–‘
A more serious result is that the database table is dropped.
The solution
1. Use precompiled statements
PreparedStatement is an interface in java.sql that inherits from the Statement interface. When an SQL Statement is executed through a Statement object, it is sent to the DBMS for compilation and execution. Unlike a Statement, a PreparedStatement is specified when the PreparedStatement object is created. The Statement is immediately sent to the DBMS for compilation. When the compiled Statement needs to be executed, the DBMS runs the compiled SQL Statement without first compiling it as other SQL statements do.
The root cause of SQL injection is that a malicious user passes SQL instructions disguised as parameters to the back-end database for execution. As a more secure way to build dynamic strings, precompiled statements use parameter placeholders instead of parameters that need to be passed in dynamically. In this way, an attacker cannot change the structure of SQL statements. The semantics of SQL statements do not change, even if the user passes in a string like or’l’=’l ‘before thousands. The database will also treat it as a normal string.
2. Use ORM framework
Common ORM frameworks such as IBATIS and Hibernate support corresponding keyword or special symbol escape. With variables configured with the # symbol, iBATIS can escape some keywords of input variables to prevent SQ L injection attacks.
3. Do not store passwords in plain text
Persisting password data after encryption with MD5 and salt.
- File upload vulnerability
File upload attacks refers to a malicious attacker using some sites is not doing a good check the type of the file, upload the executable files or scripts, and obtain the corresponding rights on the server through the script, either induced by external users access, download, upload a virus or Trojan files, achieve the goal of the attack.
To prevent user upload malicious executable files and scripts, and will file upload server as free use file storage server, we need to upload the file type for white list (not the blacklist, this is very important) calibration, and limit the size of uploaded files, renaming files need to be uploaded, The attacker cannot guess the access path of the uploaded file.
For thousands of uploaded files, the file type cannot be determined simply by the suffix name, because malicious attacks can change the suffix name of executable files to pictures or other suffix types to induce users to execute. Therefore, a more secure way to determine file types is required. For many types of files, the first few bytes are fixed. Therefore, the file type can be determined based on the contents of these bytes, which are also known as the Magic number 6.
In the back, we can use magic numbers to determine the type of file
Different types of files correspond to different headers. The FileType contains the hexadecimal encoding of the headers corresponding to common file types. Read the file header to determine the file type: /** * Read the file header */ privates 7 aticString getFileHeader(String filePath) throws IOException Startwith byte db = new byte [2 8]; InputStrearn inputStream = null; inputstream=new FileinputStream(filePath); inputStream.read(b, 0, 28); inputstream.close(); return bytes2hex(b);
Public static FileTypegetType(String filePath)throws IOException {public static FileTypegetType(String filePath)throws IOException {
String fileHead = getFileHeader(filePath); if (fileHead == null || fileHead.length () == 0) { return null; }
} read the first 28 bytes of a file and convert the read content to hexadecimal. Compare it with the file header enumerated in FileType to determine the FileType.
After uploading a file of the image type, you can scale the image to destroy the structure of the binary executable file uploaded by malicious users to avoid malicious code execution.
The solution
1. Backstage, you can use the Imagemagick development kit
2. The front-end can use the front-end framework to limit the format and verification of uploaded files.
Tomorrow: DDos attack www.jianshu.com/p/fd871bad9…
It is not easy to organize, please give a thumbs-up if you like