Before learning network security, we must first know an organization – OWASP. OWASP is an open source, non-profit, global security organization dedicated to application software security research. We use the organization’s published technical documents to learn about how cyber attacks work and how to prevent them. The core of Web security is never to trust data sent by users:

Common Web attacks are as follows:

1. google hack

2. Web crawler

3. Violent guessing

4. Scan for Web vulnerabilities

5. Use of error information

6. Exploit server configuration vulnerabilities

7. Upload and download files

8. Construct malicious input (SQL injection attacks, command injection attacks, cross-site scripting attacks, etc.)

9. HTTP attacks

10. Denial of service attacks

11. Other attacks (Web Service, Flash, Ajax, etc.)

1. SQL injection attacks

1.1 Simple Injection

1. Numerical injection: For example, we have a query SQL in the background:

SELECT * from user_info WHERE id= 

So we can query all the data by changing the front-end value bit: -1 or 1=1, where -1 indicates the data that will never exist.

2. String injection method: through the annotation character to achieve detour

# / — is usually marked as a comment, so you can enter the user name with ‘#’, and then enter any password, so that the following SQL query password will be commented out, directly bypass password verification implementation login;

 

Therefore, it is necessary to ensure the absolute verification of the input box format. SQL concatenation is strictly prohibited and placeholders must be used

2. XSS attacks

Cross-site scripting attacks, a type of code injection, allow malicious users to inject code into a web page, which will affect other users while browsing the web page. Data entered by the user is executed on the page as AN HTML statement

2.1 Reflex XSS Attacks

Definition – When a page makes a request, the XSS code appears in the URL and is submitted to the server as input. The server parses the XSS code and responds. The XSS code is sent back to the browser along with the response, and the browser parses and executes the XSS code.

The demo is as follows:

When accessing the project, add the XSS parameter to display the following page:

Let’s change the value of XSS:http://127.0.0.1:8080/tomatocc/?xss=The following dialog box is displayed. The premise of this attack is that the parameters in the address must be resolved on the page. Otherwise, this attack is meaningless.

There are three types of attack:

  1. Active attack: the above img tag is active attack.

  3. Iframe mode: If the parameter value is , a website will be directly rendered to the page.

2.1 Storage XSS Attacks

1. Suppose this is a communication forum and one of the pages has a text input box for comments. We write the offensive script to the text box and submit it to the server. (The meaning of this script is to get the cookie of the client and send it to the specified address).

2. The background service has stored the data we submitted to the database. When other users log in this website on their own computers, the server side will render the offensive XSS script message we wrote before to the HTML page, so as to send the cookie information in the user page to the website we reserved.

3. Next, we can use this person’s cookie information to “replace” him in the website for a series of operations; A simple stored XSS attack (cookie spoofing) is done.

The solution for JS to get cookies: set the HttpOnly attribute to true in the cookie, then the COOKIE information will not be read through the JS script, which can effectively prevent XSS attacks

2.3 Defense Measures against XSS Attacks

1. Escape HTML: Common template engines such as dot.js, EJS, FreeMarker, etc., usually have only one rule for ESCAPING HTML, which is to escape & < > “‘ /, which does provide some XSS protection

2. Filtering: Be careful when using.innerhtml,.outerhtml, and document.write(). Do not insert untrusted data into the page as HTML. Instead, use.textContent,.setAttribute(), etc. If use Vue or React technology stack, and do not use the v – HTML/dangerouslySetInnerHTML function, on the front end render phase avoid innerHTML, outerHTML XSS concerns. Inline event listeners in the DOM, such as location, onClick, onError, onload, onmouseover, etc. JavaScript eval(), setTimeout(), setInterval(), etc., can all run strings as code. If untrusted data is concatenated into strings and passed to these apis, it is easy to create a security risk that must be avoided.

3. Correction: To avoid direct HMTL escape, we need a more complete transfer strategy