6 XSS on Habrahabr and methods of protection with their consequences

Once I wondered how much corporate blogs cost in Habrahabr. I went to this page and clicked on the link to order . Automatically, instead of the expected data, I entered the vector for testing XSS and received JS execution in my browser. But this is not all as interesting as the methods of protection on Habré from the effects of XSS.

Protection. HTTP Only

Running XSS in two fields in step 2 and in four in step 3, I wondered what could be done about it. The most standard attack vector, if possible, is to conduct XSS - this is to “merge” the authorization session and substitute yourself. Turning to the cookies, I saw that the PHPSSESID uses the HTTP Only flag, which prohibits accessing this cookie through JS. Those. even having implemented malicious JS code, we cannot “merge” the user's session and substitute to ourselves (in order to be authorized by the user, the classic attack vector). There are ways to circumvent this protection, on some versions of Apache (and here is nginx, so it does not) and through the use of plug-ins in the browser, but the next item breaks all the vectors.

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

Protection. Anti-CSRF protection

Since we are dealing with XSS through POST, in such cases XSS exploitation through CSRF is used. The attacker creates an identical form on his website, as well as on a vulnerable resource, with already filled data (placing a vector for XSS in vulnerable fields) and places it in a hidden frame on his own website. When the attacked user opens the site with this frame and form - he will automatically send the data to Habr and execute the 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 Secure Web Resource. Part 1 - the server software I considered the following rule in nginx (which can be implemented directly at the level of the web application) 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, a bright example - Habrahabr, uses this rule. Those. we can not send a POST request to the server from another site - we get 403. As a result, we can execute the JS code only in our browser.

hint: protection from CSRF saves from the effects of XSS through POST, which negates the vulnerability.

Attack. Cookie injection

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

It consists in analyzing the JS code of the application and setting the value of document.cookie. If there is a DOM XSS or such conditions that allow you to embed your Cookie value (for example, some kind of test cookie which sets itself 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, inform the support service , respond very promptly.

hint: in the article Finding loopholes: DOM based XSS guide describes the moments from where to wait for a trick with DOM XSS.

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