Ну товарищи пишут на своем сайте и на других сайтах, прямого пруфа не нашел, но видимо основываются на данных по скачиваниям (27 миллионов) и собирают данные по мета-тегам, аналогично по друпалу и вордпресу — прям отдельной статьи с описанием методов подсчета так и не увидел, но будем надеяться что все они нам не врут.
Нет, когда злоумышленник Иванов, после того как пользователь Петров зарегистрировался по его ссылке, попытается войти, щелкнув «Войти через ВКонтакте», то ему как и всем откроется окошко «разрешить — отказать», и code он получит свой собственный, и access_token для себя, и данные в уже созданном аккаунте (vk-id-Иванова) обновятся: в качестве отображаемого имени там стояло Петров и фотография была Петрова, а после этого станет Иванов и фотография Иванова.
Как я уже говорил — пользователь из социальных сетей не может узнать свой пароль на моем сайте, не может изменить его или восстановить, поэтому для злоумышленника в используемой у меня схеме авторизации из данной уязвимости выжать получится мало что.
Ценное замечание, странно, что в документации ВКонтакте об этом не было упоминания. Но я бы не стал это считать настолько большой проблемой, по сути пользователь, перешедший по ссылке от злоумышленника, создаст аккаунт vk-id-злоумышленника, а фото и отображаемое имя будет жертвы, причем при следующем заходе жертвы на сайт через авторизацию от этой соц.сети нормальный порядок вещей будет восставлен. Аналогичные действия (создание фейкового аккаунта) можно сделать поменяв фотографию и имя/фамилию и войдя на сайт.
Херня — херней, кроме пары цитат. Я представляю как решив сегодня одно дело, через 10 лет вы решите 1024. И таких людей встречал, на том же фрилансе много таких, чья основная задача урвать заказ за любую сумму, а потом искать людей, которые бы его сделали за сумму меньшую. А их мечта — найти человека, который бы делал эту работу за них и ежедневно перечислял деньги.
Спасибо, кэп, я право дело, забыв про людей, у которых могут наблюдаться определенные проблемы с возможностью плюсовать, всё терялся в догадках относительно этого явления.
Извиняюсь, рабочий код у меня немного отличается от примера, я нигде не упомянул этого. Анонимус на пхп.нет столкнулся с проблемой отправки запроса на томкат-сервер, однако разделитель задается с mode PHP_INI_PERDIR, т.е. его можно указать в .htaccess-файле, а представить ситуацию, когда у нас нет доступа даже туда, — очень сложно.
Спасибо, но ансет делать не хочется по причине того, что массив с майловскими переменными хотелось бы хранить всегда в исходном виде. По поводу http_build_query — анонинумус наверное был не в курсе, что разделитель задается в php.ini и от того куда мы в дальнейшем посылаем запрос это никак не зависит.
Как я уже говорил — пользователь из социальных сетей не может узнать свой пароль на моем сайте, не может изменить его или восстановить, поэтому для злоумышленника в используемой у меня схеме авторизации из данной уязвимости выжать получится мало что.