Home / Blog / DDoS attacks through XSS

DDoS attacks through XSS

Posted on 03/24/2015, by Álvaro Díaz Hernández
DDoS attacks through XSS

Over the course of the last year there have been various items of news confirming that many DDoS attacks are being triggered from websites with vulnerabilities of the persistent Cross Site Scripting (XSS) type.

This is because cybercriminals inject JavaScript code into the persistent XSS vulnerability which is executed by all those visiting the site via their browser. This allows a large number of requests included in the JavaScript code to be made to the attacked site every second. Depending on the traffic visiting the site harbouring the persistent XSS, this may have the effect of a massive DDoS.

- Users / Infected Website / DDoS Attack / Attacker / Server -

As may be seen, this sort of attack may be very harmful. This is because all it needs to do is to find a site vulnerable to persistent XSS that has sufficient traffic and visitors to keep the page open, which will keep the JavaScript code in execution in browsers.

Attackers also keep in mind the sort of request that the JavaScript code inserted through the XSS will make. For example, a request like:


might not be as harmful as:



The second uniform resource locator (URL) would trigger a greater amount of processing work for the victim's server, because it must search for the word "incibe" in the database.

The news that has been published stated that video sites are a frequent target for this type of attack. The reason is that victims spend a long period of time visiting a site while they watch videos. This makes them a prime target for such attacks, because the longer a page stays open, the longer the attack continues.

This sort of attack is generally simple and effective when attackers put in the time and effort needed to ensure it works. They also have the great advantage for attackers that they do not require any kind of infection in a user's computer, just JavaScript code on vulnerable sites.

How to protect against this sort of attack

Just as for any DDoS attack, the first thing to do is to identify the pattern used by the attacker. This can be done by executing the following command to view the access logs for the server, in this case Apache:

When this is executed, it becomes possible to view in real time all visits to the site, so that the attacker internet protocol address (IP) can be identified.

- IPs and Dates for All Request -

- Request Received by Web Server -

- User-Agent Employed by Users -

As can be seen, each IP corresponds to one of the different users who are accessing the infected website. It is the site that causes users to send requests to the server, without their even being aware of what is going on.

As the headers have not been edited, it is possible to find out which page is being used to trigger the DDoS attack.

In this case it is: http://alvarodiaz.ovh/index.php?video=ID

At this point, the best thing is to warn the administrator responsible for that page, who will certainly not be aware of what is happening. While the programmers for the site sort out the vulnerability, it is possible to block access by the attacking IPs so as to try to slow down the DDoS attack that is being suffered.

Among other possibilities, this can be done by using fail2ban. Fail2ban is a script programmed in Python that monitors Apache logs for suspicious patterns. It is also able to take measures to block attackers, either with iptables or by running whatever command we choose. It is distributed under a GNU licence.

Fail2ban allows requests to be filtered by a number of fields, such as by IPs, header reference or the number of connections in a given period of time. In the example filtering can be by the reference "http://alvarodiaz.ovh/index.php?video=ID" .

If this piece of data was not available, it would be necessary to take into account all requests, filtering with the string "GET / HTTP/1.1". This is a very common state of affairs and might lead to the banning of legitimate visits.

- Installing Fail2ban -

Below are some guidelines on configuring fail2ban. The configuration directory for fail2ban is to be found in: /etc/fail2ban/, where there are two further directories, action.d and filter.d

  • action.d: This has the actions that fail2ban will take when any of our filters finds some misbehaving IP.
  • filter.d: This stores the filters that will be used to identify attackers.

To avoid an attack the file /etc/fail2ban/jail.conf should be edited, adding the following lines:

- Configuration Lines to Be Added -

  • Maxretry: This specifies how many tries will be allowed before an IP is banned.
  • findtime: This is the amount of time over which retries will be counted (300 seconds = 5 minutes).
  • bantime: This is the amount of time that will elapse before fresh requests will be permitted. It is effectively the time that an IP will be locked out, in this case five minutes.
  • Logpath: This is the route to our Apache log.

It is crucial to configure this file correctly, because otherwise fail2ban will lock out genuine visits.

Next the filtering file is created in /etc/fail2ban/filters.d/http-get-dos.conf. The following lines will be included in it:

- Configuration Lines to Be Added -

Finally, fail2ban must be restarted so it will adopt the new configuration.

- Restart Command for Fail2ban -

Once it has restarted, all that is necessary is to wait while fail2ban blocks attacking IPs automatically. It is possible to see what bans it imposes by looking at its log file /var/log/fail2ban.log

- Banning IP -

When this IP tries to access our server, fail2ban will stop it in its tracks.



Why Ban IPs with Fail2ban and Not from Apache or Htaccess?

The reason is that if locking out of IPs is done from the applications level this is ineffective because the server, in this case Apache, still receives the request. If a firewall like iptables is used, then connections are blocked at network level, so that Apache will never process the request.

Finally, it should be noted that although fail2ban limits the impact of an attack of this kind, it is not a definitive solution, as the server continues to receive requests. If an attack generates a large volume of these, it could also cause a denial of service on our server.