CSRF vulnerabilities on the example of HabraHabra

Vulnerability is no longer - it was fixed long before the appearance of this topic.

Very often, many web developers forget about the existence of this method of hacking, and some do not even know about it.

Unfortunately, similar vulnerabilities are found even in such large systems as HabraHabr.
')

How it all began

It all started with the fact that my karma was quickly drained to -16 units due to a quite normal, I think, comment. I felt hurt, because I registered on this resource to write interesting topics for everyone, and now I can't do it.



I flipped through the tape, looking through the topics, and thought about how well their authors, who quickly gain rating and glow in the rays of glory. Without any hope, I poked at the arrow to put a plus sign on the topic. As it is not difficult to guess, I received an error like "Your karma is not enough to vote."

We are looking for vulnerabilities

I immediately noticed that the page is not updated and, therefore, AJAX is used.

Immediately I remembered about the little-known CSRF, or as they are also called XSRF vulnerabilities.

I became a FireBug to see where and how requests are sent. First of all, it was embarrassing that only the evaluation (for or against), the type of record (topic) and id were transmitted. No additional fields like hash or token were transmitted.

Not so simple

Perhaps the impatient reader has already decided that I found an elementary, obvious hole for everybody? No matter how! All my attempts to fake a request led to the same thing:



At first, I decided that I was wrong somewhere. But no, I sent a request to the desired address and passed all parameters as necessary. But when this was done by the HabraHabra script, I received the status of an answer 200, and I 404.

I began to carefully check the HTTP headers, and here it caught my eye:



What is this strange headline that was not in my request?

A little googling, I learned that this header is by default transmitted when AJAX'e, but when you request from the form, by itself, is not transmitted.

I could not make an AJAX request, because Habr is on a different domain and I simply would not let the browser go there. And then I remembered the FlashPlayer that I abandoned a long time ago. Quickly googled, I screamed cheers !

Yes, comrades, this so much not favorite addon to the browser can send any requests to any domain if ... If there is a correct crossdomain.xml file in the root of this domain.

Do you believe in fate? Me not. But I was just shocked when I found this coveted file at the root of HabraHabra, which allowed me to send requests to the 80th port from any domain !

We write an exploit

I chose ActionScript version 2 firstly, because I knew him better, and secondly, because I can bring old FlashPlayer users (starting with version 7) with me to the ship.

var req:LoadVars = new LoadVars(); req.addRequestHeader("X-Requested-With","XMLHttpRequest"); req.addRequestHeader("Referer","http://habrahabr.ru/"); //    req.decode("ti=666&tt=2&v=1"); //  666 id   req.send("http://habrahabr.ru/json/vote/", "_blank", "POST"); 

What to do with the exploit?

Everything is now small. If you have your own website, then without thinking, fill in the code there and put it in the iframe.

If you do not have a website, then thinking, we negotiate for Profit with the owner of a large VKontakte application and fill in the code for it. Coverage of 50% of users is guaranteed.

Everything, now any user, if he did not vote for your topic earlier, puts you + without knowing it.

In addition, you can vote not only for topics, but also for comments, questions and CARMU!

In memory

Breaking sites is not very good. For this, they can do an ata-ta-ta in the back seat.

In the case of this vulnerability, I quickly wrote a letter to the support service and closed the vulnerability (correcting crossdomain.xml).