Relatively recently, I switched from searching vulnerabilities on random sites to Bug Bounty sites, and for many people this choice seems obvious - in such programs, a researcher in 90% of the cases will receive not only good experience, but also a guaranteed reward for valid vulnerability, while on a random site, you can stumble upon misunderstanding and threats. Actually, in order to gain reputation and "acceleration" on the largest Bug Bounty - HackerOne, it was decided to focus on finding vulnerabilities on one of the major bugbounty programs -

This article will deal with several bugs at itself, as well as a vulnerability in one of the subdomains, which allowed access to the admin panel, and therefore it was possible to view the personal data of 2 million users (such as email addresses, telephone numbers, home address, etc.) with more than 10 popular online stores in Russia, as well as to enter their accounts without a password.

In order to participate in bug bounty on hackerone, 3,000 subdomains were sorted and checked one by one. A small part of my time was allocated to work with this Bug Bounty and in ~ 3 months I managed to send 45 valid vulnerabilities (40 are now fixed, 5 со статусом «triaged»).

Некоторое время назад я приступил к исследованию поддомена — это интернет магазин брендированных товаров.

Most often, testing begins from the functionality of a personal account, this case is also not exception. Authorization on the site occurs via Oauth, or by entering the email address. If we take into the account the second method, the authorization wil be like follows: the user enters an email, web app send him a code, he sends it through the form and enters the account. Here the first vulnerability was discovered:

Дело в том, что кроме самого кода, который нужно ввести в форму, присылается ещё и ссылка для входа вида, при посещении которой выполняется автоматический вход в аккаунт. Такую ссылку обычно называют «автологином», этот функционал присутствовал в старых WAP сайтах. Сейчас такой способ входа в аккаунт почти не используется ввиду его небезопасности.

Vulnerability impact:

  • Attacker can make a brute-force attack, find out a lot of identifiers for autologin and enter other people's accounts;
  • The login link can be indexed by search engines and get into the Google results issue, an attacker can parse them. Sometimes, even when search robot banned in robots.txt, urls can be indexed without content.

After a careful search for directories (I use the dirb program with a custom dictionary for this), I began to test forms for changing personal data, delivery addresses, etc. CSRF tokens were present in the forms, and attempts to bypass the protection were unsuccessful. There was no XSS and no hints on other vulnerabilities (such a conclusion was made after fuzzing).

Finally, I changed my data and delivery address to js payloads and made a test order of goods, where I entered another js payload in the comment.

At 00:10, I found that my blind xss script was executed in the admin panel of the site that I don't know, and I received logs on the server. At that time, there was not even a thought that it would be possible to access the admin panel, since most often cookies are protected by the http only flag.

But, to my surprise, there was no flag and I successfully entered the admin area. The site itself looked like a 2000–2006 y. CMS with a very old design, poor performance (the pages were loaded for a long time) and a lot of php and sql errors.

After viewing the main page, it became quite clear that the admin panel was related to and orders on the subdomain were trusted to manage a third-party site (the team later said that it was a partner and was not developed by In the admin panel it was possible to view, edit and delete orders of all users from 10 online stores (some large ones), as well as view personal data of 2,017,271 users. The second vulnerability Blind XSS is confirmed

If an intruder would have access to the admin panel, he could download the database with information about all users with one click, but there was a php error in the download functionality itself, so he would have to limit himself to searching the users by id in the admin panel and parse them with burp intruder.

Кроме этого, к странице каждого юзера в админ панели была прикреплена ссылка для автологина. Может быть, кто-то из читателей помнит о небезопасных автологинах в старых русских социальных сетях, которые были популярны в 2007 году, — и др.

As soon as I got access to the admin panel and made a couple of screenshots, I immediately wrote a report on hackerone.

A report with details was sent at 00:20. At about 00:43, Sergey Belov, head of application security at, answered me in a report. He asked to stop the post exploitation of my blind xss and immediately exit the admin panel, which I did.

The next morning I checked the bug, and since the logs did not come to my server, we can assume that it was fixed. Also, access to the admin panel was closed, this was only restricted by IP access (most likely).

Unfortunately, the subdomain was not in the scope Bug Bounty of the program and the vulnerability could not claim to be rewarded. Therefore, in order for the effort and time spent on vulnerability to be rewarded, I contacted the developers of the admin panel itself and I was paid a reward.

I also sent a report with the first Improper Authentication vulnerability in Bug Bounty, while knowing full well that the bug is difficult to exploit and I will only get reputation points. As a PoC for the vulnerability I sent autologin url, which worked well during the writing of the report. But, later I received a message from the analyst that he could not reproduce the bug, that, apparently, the autologin functionality was disabled by the developers and it was no longer possible to recover the password to the account or enter to the account using the link.

After a couple of months, it was discovered that the autologin functionality was turned on again, I told the developers about it and a few days ago the bug was finally fixed.


  • April 12, 00:20:50 — Репорт отправлен через HackerOne.
  • April 12, 00:43:03 — Первый ответ.
  • April 12, 00:47:15 — Triaged.
  • April 26, 19:14:38 — Репорт помечен как «Resolved».
  • June 27, 00:59 — Выплачена награда за уязвимость.

Большинство найденных багов — это XSS, Open Redirect и CSRF, но хотелось бы отдельно рассказать о наиболее интересных:

1. IDOR in support service, which revealed several million tickets.

2. Также я хотел бы рассказать о баге Double Authentication Bypass на, но, к сожалению, уязвимость пока не была исправлена и помечена как «Informative», в ближайшее время исправлять его не собираются, поэтому, увы, его здесь не будет. Могу только сказать, что защита обходится с помощью перехода на мобильную версию, в то время, когда в веб версии защита работает. И всё же, когда его исправят, вы сможете посмотреть информацию о нём на моём канале

3. Blind XSS on in pet name, which allowed to hack the admin panel.

4. Stored XSS was found on ****, with the help of which it was possible to de-anonymize any user of and get his email in case if he simply follows the link. It was necessary only to create a page with js.

Due to the fact that the user automatically logs in to **** and the user's email is automatically substituted in the subscription field, we can find out the email address of any user who will follow the link of our consultation. It is possible to see the email address in the html source of the page, as well as in local storage, the value of which will come to our sniffer.

5. Blind XSS at (служба поддержки in-scope сайта, который позже был помечен как «Duplicate».

6. 6. No Rate limit in the login to account on The site has a login functionality using otp, code came to the phone number, there was no restriction on enumerating the numbers, so the bruteforce attack would help to hack any account knowing only the phone number.

7. The disclosure of email addresses of users on page with article on **** using pictures">, similar to report of Isaeva.

Conclusions from this article:

  • NEVER use autologins in authorization.
  • Закрывайте доступ к админ панели с помощью ошибки 403 через .htaccess (если у вас сервер apache), ограничивайте доступ по IP адресу, требуйте аутентификацию. Таким образом злоумышленнику будет труднее найти уязвимые места в админ панели, кроме того, если он узнает cookies или другие данные, он не сможет их задействовать.
  • Не используйте устаревшее программное обеспечение в админ панели.
  • Всегда фильтруйте запрещенные символы [ «<>’/ ] в информации, которая приходит в админку, чтобы избежать XSS.

Советы для тестировщиков безопасности [Blind XSS]:

  • Пытайтесь найти все возможные места, где можно отправить ваш скрипт, например, жалоба на страницу / пользователя, оценка работы сайта, логирование (попробуйте заменить свой user agent на скрипт, возможно, он окажется в логах админ панели, где нету фильтрации) и тд.
  • Часто вы не получаете логи про успешную blind xss атаку из-за фильтрации или CSP настроек. Обходите фильтры в админ панели с помощью использования других скриптов (например meta, img — во многих случаях выполнения этих скриптов хватит для доказательства уязвимости), также закрывайте теги, чтобы они не помешали выполнению.
  • Если в админ панели стоит фильтрация на <>, попробуйте испытать удачу и выполнить js инъекцию «; alert(1);// .

P.S: Рекомендую подписаться на мой telegram канал по информационной безопасности, ссылка внизу или в профиле.

Categories: Bug Bounty

ru_RURussian en_USEnglish