Another type of XSS attack on the site

Hi, Habr! Last night my wife complained that she could not go to the children's clothing site, because she was throwing it from him to a completely foreign resource. I check it myself - indeed, during the loading of the main page (or any other, if I manage to follow the link from the loading page) it suddenly transfers to another domain.

It is September in the street and it is getting colder, so I decided not to retreat before the problem and choose the child a demi-season suit, having figured out what was wrong!

The first and obvious thing that comes to mind is to search for a clear redirect on the page. I open the source code of the page in an attempt to find something like this:

<meta http-equiv="refresh" content="3;url=http://---/"> 

To no avail, moreover, it would be too easy. Once there is no standard redirect, therefore it is implemented by means of JS. We check the hypothesis by turning off JS in the browser - the page has loaded, does not throw it anywhere. At the same time, window.location is not used anywhere on the page, there is no substitute URL either. We look, what resources are downloaded by the browser:
')


Immediately catches the eye of a suspicious URL, on request to which the HTTP code 301 is returned: is.gd/J87Pzs

At this URL we quickly find a line in the source of the page:



I note that this line is present on all pages where I looked.

Hmm, you need to figure out what happens on this link: is.gd/J87Pzs .

is.gd is a typical reference quarantine. The following URL stands behind this URL: home-income-business.com/sfi/i/qwe

A GET request for it returns such content:

 function process(){ window.location = "http://---/"; } window.onerror = process; process() 

The case could already be closed, as at that moment I switch to another Internet access point, and the problem (suddenly) disappears: the HTTP request at the last URL in the chain starts returning empty content! What the?! We switch again to another access point - the malicious code is given again. And this is more interesting! It turns out, depending on the ip-address is given different content . How can this be? For example, in nginx there is a special geo module with which you can configure this behavior. The content of the HTTP response indirectly confirms the above:


Why make an attack with a redirect to another site? There can be many reasons, including mercantile ones, for example, for unfair competition or for attracting traffic to the site.

At the same time, the owner of the victim site may not even guess what is under attack , since from his ip-addresses the site will open and work perfectly, and from others ... Users accessing such a site will probably just leave and not bother.

I was confused. And wrote on the e-mail specified in the contacts. And the very next day, that is, today, the site administrator contacted me, to whom I described the problem in detail. And, while I was writing this post and preparing pictures, the problem had already been fixed, removing the malicious script from the pages of the site!

Probably, it is interesting for you to find out how the malicious code appeared on the pages of the site: the administrator suggested that it was his predecessor who left a “gift”.

Findings:

• The most effective way to prevent the introduction of such scripts is not to use resources downloaded from third-party sites;
• To exclude them, you can also use Content Security Policy using the Content-Security-Policy HTTP header ( X-WebKit-CSP for older versions of Chrome and X-Content-Security-Policy for older versions of Firefox and IE 10-11), which because of its relative youth and Candidate Recomendation status is not supported in older browsers;
• And if possible, send bug reports, so we can make the Internet cleaner.

PS I considered it inappropriate to indicate the site under attack.