ethoz 7 фев 2016 в 14:30

Почему Яндекс отказался от подтверждения сайтов txt-файлом

5 мин

56K

Информационная безопасность *

+62

Комментарии 31

spbdimka 7 фев 2016 в 14:51

Достаточно было бы проверять не только наличие файла, но и его содержимое

Delphinum 7 фев 2016 в 16:22

На деле это решение все равно потребовало бы от вебмастеров переподтверждения. Потому поддерживаю Яндекс, смысла в этом способе нет, если подтверждение через HTML по сути то же самое.

Borz 7 фев 2016 в 17:22

чем отличается от проверки HTML файла? и как это поможет человеку с тысячей сайтов, если раньше достаточно было пустого файла?

grishkaa 7 фев 2016 в 20:53

В HTML файл надо положить определённую строку, которую тоже даёт яндекс (и которую он тоже проверяет).

Borz 7 фев 2016 в 20:58

вот и я про то — чем отличается требование «положить определённую строку в HTML файл» от «положить определённую строку в TXT файл»? Не предлагаете же в TXT проверять просто сам факт наличия содержимого в TXT файле

zapimir 7 фев 2016 в 15:16

через несколько дней после отправленного отчёта, судьба txt-фала была решена (R.I.P.):

И что во всем яндексе не нашлось человека который предложил бы создавать txt-файл с каким либо содержимым, каким-нибудь хэшем, как это делают все остальные, а не надеяться на код ответа сервера.

fr33z3 7 фев 2016 в 16:05

Я думаю, вскоре появится. Странно конечно, что с самого начала это не сделали, но сейчас им нужно все согласовать, прописать стандарты и так далее. В таких компаниях, как яндекс дажи такие незначительные изменения так быстро не делаются.

m_z 7 фев 2016 в 16:58

Т.е. чтобы выпилить фичу никаких согласований не требуется, а внести простое исправление нужно месяцы? Да и в тексте указано «решение отказаться».

mannaro 7 фев 2016 в 17:29

Выпилить фичу — это просто решение менеджера. А вот ввести новую фичу — решение команды. Поэтому первое и быстрее, чем второе. Но так, да. Неправильно это.

el777 7 фев 2016 в 20:24

Выпилить фичу — это закрыть известный баг. При наличии альтернатив — это, конечно, не очень удобно, но не фатально.
Добавить фичу, не согласовав с остальными отделами/проектами/и т.д. — это добавить 10 неизвестных багов. Может отвалиться что угодно — например, подтверждение для Директа или еще чего. В итоге заранее неопределенный круг пользователей может оказаться под угрозой.

Думаю именно так и появилось подтверждение через текстовый файл. Есть полная процедура — через html-файл с проверкой содержимого. Решение ввести упрощенную схему выглядит совершенно логично — веб-мастер контролирует содержимое своего сайта, он может создать файл с особым именем и записать туда что-то. Начинаем оптимизировать. Если вебмастер уже создал файл, то зачем проверять содержимое? Логично? Весьма. Внутри системы изъяна нет. Проблема начинается при «интеграционном тестировании» с интернетом. Практически все распространенные системы ведут себя как положено. Но есть особый баг в ряде CMS, где наличие файла можно сымитировать.

valera5505 7 фев 2016 в 20:22

HTML-файл делает по сути то же самое

Скриншот

DmitriyPopov 8 фев 2016 в 08:53

как это делают все остальные

А кого Вы имеете ввиду, когда пишете «все остальные»?
Не могли бы вы рассказать — у каких других вебмастерских сервисов есть «подтверждение через текстовые файлы»? Я может быть плохо искал?

zapimir 8 фев 2016 в 09:03

Не обязательно вебмастерские, любые другие сервисы которые требуют подтверждение владением сайта. А это различные конторы выдающие SSL-сертификаты, рекламные сети, платежные системы и т.п. Да у самого Яндекса есть проверка по html, или чтобы найти на сайте нужный хэш его обязательно нужно в html заворачивать?

Jeditobe 7 фев 2016 в 17:55

Заплатили за уязвимость?

kuber 7 фев 2016 в 17:56

В статье даже сумма указана.

onto 7 фев 2016 в 17:56

В этот же день мне ответили и начали разбираться с моим репортом, а на следующий, присудили награду в размере 41337 рублей (примерно $700 в тот момент).

Чукча не читатель

justmara 8 фев 2016 в 18:28

четырекулхаксора, окааай

booomerang 7 фев 2016 в 22:06

Являясь закоренелым любителем почитать логи...

К сожалению, я не большой любитель копания кода...

Почему я замечаю, такие ненужные факты об авторе?!

ONEGiN 8 фев 2016 в 11:41

Почему я замечаю ваш комментарий?

ONEGiN 7 фев 2016 в 23:29

В чем магия чисел 41337 313373?

spbdimka 8 фев 2016 в 00:02

true h4x0r leet-speak
1337 = leet

Psychosynthesis 8 фев 2016 в 10:48

Это были времена, когда в половине программ русский шрифт не поддерживался и «cool-][ацкеры» изгалялись с написанием собственных ников любыми способами. Хотя память мне подсказывает, что 31337 началось гораздо раньше и появилось ещё во времена Митника за Океаном. В общем, было дело, 31337 читали как eleet, аля «элитный» (хотя элита и пишется через i). А автор, видимо, с последней тройкой просто ошибся.

Untosh 9 фев 2016 в 08:28

Вряд ли автор ошибся. Ведь в слове elite на конце есть буква e. Так почему бы дополнительно троечку не добавить? Сумма-то гораздо внушительнее получилась бы без потери смысла. :)

fso 7 фев 2016 в 23:39

Не покидает мысль, что в таком случае содержимое txt (и html) файла, которое однозначно определяется именем, не имеет особого значения.
Труда не составит и сформировать корректное «содержимое» файла с именем yandex_0123456ABCDEF.html в виде

<html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 </head>
 <body>Verification: 0123456ABCDEF<</body>
</html>

Тоесть на запрос бота яндекса, легко отдается «корректный» проверочный файл. Хорошая идея для плагина вордпресса — «автоподтвержение в яндексе».

mapron 8 фев 2016 в 00:17

А как сайт узнает, на какой из 20 запросов бота яндекса, нужно ответить верным кодом? фишка подтверждения, что их этих запросов какой-то случайный есть с реальным кодом, остальные — нет.