6 XSS on Habrahabr and methods of protection with their consequences / Digital Security Blog

Somehow I was wondering how much corporate blogs cost on Habrahabr. I went to this page and clicked on the order link . Automatically, instead of the expected data, I introduced a vector for XSS testing and got JS execution in my browser. But it is not all so interesting, as methods of protection on Habr from consequences of XSS.

Protection. HTTP Only

Having performed the XSS in two fields in step 2 and four in step 3, it became interesting what can be done about this. The most standard attack vector when possible to conduct XSS is to "merge" the authorization session and substitute it for yourself. Turning to cookies, I saw that the HTTP Only flag is used for PHPSSESID, which prohibits accessing this cookie through JS. Those. even having implemented the malicious JS code, we cannot “merge” the user session and substitute it (to be authorized under the user, the classic attack vector). There are methods to bypass this protection, on some versions of Apache (and here nginx, so it disappears) and through the use of plug-ins in the browser, but the next paragraph breaks all the vectors.

hint: For phpsessid to have the HTTP Only flag, set the following value in php.ini: session.cookie_httponly = true

Protection. Anti-csrf protection

Since we are dealing with XSS through POST, then exploiting XSS through CSRF is used in such cases. The attacker creates an identical form on his site, like on a vulnerable resource, with data already filled in (placing a vector for XSS in vulnerable fields) and puts it in a hidden frame on his own site. When the attacked user opens a site with this frame and form, he will automatically send data to the Habr and execute malicious JS in his browser. But, there is a difference - the HTTP Referer field will contain the domain of the attacker's site.

In the article Towards a Safe Web Resource. Part 1 - server software I considered the following rule in nginx (which can be implemented right at the web application level) as a dirty hack:

# ANTI CSRF HACK
    valid_referers blocked example.com www.example.com;
    if ($invalid_referer) {
    set $possible_csrf 1;
}
    if ($request_method = POST) {
    set $possible_csrf "${possible_csrf}2";
}
    if ($possible_csrf = 12) {
    return 403;
}

And here he is, a striking example - Habrahabr, uses this rule. Those. we cannot send a POST request to the server from another site - we will get 403. As a result, we can execute JS code only in our browser.

hint: protection against CSRF saves from the consequences of XSS via POST, which nullifies the vulnerability.

Attack. Cookie injection

But still, can there still be loopholes? Continuing to study how the form works, I came across that the data filled in the application form is temporarily stored in some cache on the server (maybe memcache). This cache is not associated with the user session (PHPSESSID), but with the other - habrsession_id. Those. having already generated a form with an XSS vector and substituting our cookie habrsession_id to another user, we can theoretically carry out an attack. But we cannot (under standard conditions) set a cookie value on another domain. But there is a way - Cookie injection.

It consists in the analysis of the JS code of the application and the calls to set the value of document.cookie. If there is an XSS DOM or conditions that allow you to implement your cookie value (for example, some test cookie that exposes the titile value of the current window (we can open the window through window.open with its title, there are cases in real systems) , the attacker can write his habrsession_id value to the attacked and execute JS. At the moment, all XSS are fixed. If you find something, tell the support team , they respond very quickly.

hint: in the article Looking for loopholes: guide for DOM Based XSS describes the moments from where wait for the trick with the DOM XSS.

PS And hint off topic topic: While writing the topic, did not save it and accidentally pressed f5. As a result, at one point, I lost the entire text of the article (when I had almost finished it, the “restore” button did not help). Instantly dumped the process through a regular task manager, opened it through HxD , found the article text using its keywords (Russian text was in json) and substituted it here . Restored the lion's share of the article.