Securelist.com - XSS and SQL Injection vulnerabilities

Hello!
Securelist.com is developed by Kaspersky Lab. The site has a blog in which the staff of the LC posts fasting, and ordinary users, after registering, can comment on them. The comments have a rating. As soon as the rating of all user comments becomes> = 100, the user gets the status of a blogger and can post to the blog. And once I registered there ...


[Disclaimer]
All actions described below are presented for reference only. The portal administration was informed about all the vulnerabilities found on the site. To take some screenshots of the site, I used the peeep.us service of habrau snusmumrik . Special thanks to the team of the portal R3AL.RU for their help and support.

[Xss]
By registering, I decided to conduct a standard test for XSS vulnerability. I inserted a JS-script with an alert and it worked , i.e. There was no filtering against XSS in the Login field.
Without hesitation, I inserted a sniffer, commented on several blogs and waited. Sniffer hung on the site for about a month. During this time I was able to intercept 91 accounts to the site. Let's look at the work site in more detail:
1) User enters login and password
2) The site records the user’s cookie (VLUserkaspru) in the form of:
id: 19DEShash
where id is the user ID (can be found at: securelist.com/ru/userinfo/id)
19DEShash - standard php DES hash with salt = 19
3) When switching to any page of the site, the script takes the user's cookie and breaks it into 2 parts (by ":"), selects the user's password from the database, where id = id, and compares the password hash from the database with the hash value from the cookie.
This means that, having intercepted a cookie once, I can go to the site at any time (or I can clear the hash).
I decided to find out how the passwords are stored in the database. It was very easy to check this - click on the link “Forgot password” and we receive a clear password on the E-Mail. This means that passwords are stored in the database openly, not by hashes.
Logging in to the account, I found that I can change the E-Mail password recovery. To confirm the change of E-Mail, the link came only to a new E-Mail => I can change E-Mail in any account, confirm it and return the password to it in the open form.
Since I intercepted cookie LK employees, I could go to the blog control panel. She looked like this:

View of the user profile with the status “Administrator” from the inside:

Having carried out several tests, I found that the blog text is also not filtered => I can insert any HTML / JS code (for example, an exploit) there.
This is the blog editing page:

Posting title field is also not filtered, and the title is displayed on the main => we can make a small deface:

Or like this:

And especially for Habrahabr .
The list of interesting id's, the cookies of which I was able to intercept:
69 - Dmitry Bestuzhev, Kaspersky Lab Expert
72 - Sergey Golovanov, Kaspersky Lab Expert
81 - Maria Namestnikova, Kaspersky Lab Expert
82 - Yuri Namestnikov, Expert, Kaspersky Lab
85 - Tatyana Nikitina, Blogger
1052 - dr, administrator
7053 - Alexander Gostev, Kaspersky Lab Expert
')
[SQL Injection]
It took a little time, and I already wanted to inform the site administration about the vulnerability, but decided to check the cookie settings for filtering. And it turned out that id is not filtered!
Substituting various parameters into cookies, I learned that there is Blind SQL Injection:
12345) AND 1 = 2 -: hash
With this parameter, I was not allowed to enter my account, but with
12345) AND 1 = 1 -: hash
I logged in as a logged in user.
I spent a couple of hours trying to achieve a normal Blind output. As a result, I received:
12345) AND 1 = 1 AND (SELECT ascii (substring (version (), 1,1)))> 100 -: hash
Those who know SQL can easily understand that here I am comparing the ascii code of the first character of version c 100. If it is more than 100, then I become a user (AND TRUE AND TRUE), otherwise, I am a guest (AND TRUE AND FALSE) . By substituting different values, I can recognize the ascii code of a character and translate it into a character.
The server is running PostgreSQL not the latest version.
We display labels from INFORMATION_SCHEMA.TABLES:
12345) AND 1 = 1 AND (SELECT ascii (substring (table_name, 1,1)) from INFORMATION_SCHEMA.TABLES LIMIT 1 OFFSET 1)> 100 -: hash
And now I started to display the names of the tables, but there was a bummer: I could only output the name of the first table, and the vulnerability stopped working (most likely, the administrator burned the logs, but I do not exclude the fact that someone whispered).

More recently, a new entry has appeared on securelist.com called “XSS for Beginners” . =)
The XSS vulnerability was not fixed, although I sent a letter to support and a message to the LC Complaints and Suggestions Book (they answered that all necessary measures were taken). Maybe this post will force the administration to finally close the vulnerability.

UPD: Attention! This is not a PR site, company or product product.
UPD2: On topic:
Magic triptych or bad advice from KAV (the article appeared before my research, however, I learned about it quite recently).