Pull to refresh
0

Почему находится всё: ответ Яндексу от разработчиков Shop-Script

Reading time 5 min
Views 46K
Мы являемся разработчиками скрипта интернет-магазина Shop-Script, который волей-неволей стал замешан во вчерашней истории о том, что Яндекс проиндексировал приватные данные покупателей многих интернет-магазинов. В статье шла речь о магазинах, работающих на основе движка Shop-Script. Я понимаю, что могу получить много гневной критики от тех, кто считает, что вина полностью на разработчике движка, однако, считаю необходимым отразить нашу позицию и постараюсь объективно описать, что произошло, обсудить возможные решения.

Вчера, конечно, было неожиданностью узнать о сложившейся ситуации. Первое, что мы сделали — это проверили, все ли магазины подвержены такой проблеме. Оказалось, что далеко не все. Было преподложение, что проблема может быть в магазинах, которые установили какой-нибудь плагин или сторонний серверный модуль. Но оказалось, что дело и не в этом. Все магазины, у которых страницы с приватными данными клиентов появились в результатах поиска Яндекса, объединяло одно — установленный код Яндекс.Метрики. В точности, как и в недавнем случае с «Мегафоном».

Далее — о том, откуда взялись ссылки на приватные страницы, и как они могли попасть в индекс Яндекса, масштабности проблемы и возможных решениях.

Проблема заключалась в следующем:
  1. В интернет-магазине на базе Shop-Script можно оформить заказ без обязательной регистрации. То есть без ввода логина и пароля.
  2. После того, как заказ оформлен, покупателю по электронной почте отправляется уведомление о заказе, в котором есть прямая ссылка на страницу с подробной информацией о заказе, его статусе, возможности оплатить заказ и посмотреть историю его обработки.
Так как заказ оформлен незарегистрированным пользователем, то эта страница открывается по ссылке из письма-уведомления (в ссылке аутентификация происходит по хешу, в которой все параметры передаются, естественно, в GET-запросе). У пользователя никакой пароль не запрашивается, так как пароля в данном контексте нет.
Требовать обязательную регистрацию для оформления заказа в интернет-магазине, согласитесь, совершенно неудобно для покупателя, а показать ему страницу с историей выполнения заказа необходимо.
  3. Яндекс проиндексировал именно такие страницы. Точнее, страницы, которые посещали покупатели (переходили по ссылкам из писем-уведомлений).
  4. Гугл и другие поисковики проиндексировали эти же страницы уже после того, как информация об этом появилась в новостных лентах, на Хабре и стала «достоянием общественности».

Оперативное решение мы сделали следующее: прикрутили авторизацию пользователя по фамилии. Если пользователь перешел по ссылке из письма-уведомления о заказе, то сначала мы у него спрашиваем фамилию, и только если он ее ввел правильно, показываем информацию о заказе. Можно, конечно, сказать, что это тоже не очень красивое решение, однако, в данном случае это единственный параметр, на который можно было бы «опираться». Плюс, мы добавили редирект, который «съедает» все «проблемные» GET-параметры сразу, не отдавая их Яндекс.Метрике (об этом чуть ниже в посте). Патч и обновленная версия опубликованы в блоге на нашем сайте.

Теперь самое интересное. Откуда Яндекс мог узнать об адресах (URL), которые отправлялись только пользователю персонально по электронной почте? Так как все пострадавшие интернет-магазины объединяет один общий признак — установленный код Яндекс.Метрики — нетрудно сделать вывод, что адреса, которые фиксирует Яндекс.Метрика, уходили в общий индекс Яндекса. Эти адреса нигде не были публично задокументированы на стороне интернет-магазина Shop-Script, поэтому неправильно было бы говорить о том, что адреса находятся в публичных источниках. Ответ Яндекса с пятью пунктами о том, как Яндекс может узнать о новой страничке, мы читали, однако не нашли ответа на этот вопрос. Сейчас, конечно, очевидно, каким образом адреса были «слиты», и, безусловно, мы будем учитывать это в будущем. (Кстати, большое спасибо автору первого комментария в обсуждении «Почему находится все» на сайте Яндекса за конструктивность и хорошие примеры.)

Масштабность сложившейся ситуации заключается в том, что практика передачи аутентификационных параметров в качестве GET-параметров в письме или как бы то ни было применяется очень широко. А это значит, что случаи, подобные случаю «Мегафона» и нашему, могут и будут возникать в будущем с другими сайтами, движками и сервисами. Это очевидно, и является только вопросом времени. Случай «Мегафона» обратил хорошее внимание на эту проблему.

Взять для примера хотя бы распространенные сервисы онлайн-трассировки посылок по номеру отправления. Отправитель посылки не зарегистрирован на сайте, и просто получает адрес на страницу трассировки, например, по электронной почте. Адрес можно добавить в избранное, чтобы проверять статус регулярно (я, например, так делаю постоянно), можно отправить получателю отправления. При этом нельзя говорить о том, что подобная система онлайн-трассировки отправлений априори построена неверно, потому что не требует от пользователя ввода авторизационных данных — в данном случае ведь нет логина и пароля. Не заставлять же отправителя получать аккаунт на Почте России.

Примеров уведомлений, когда пользователю по электронной почте приходит ссылка, ведущая сразу внутрь аккаунта (с автоматической авторизацией), можно найти в интернете в достатке. Насколько мне известно, сервис Яндекса «Мой круг» использует такую систему для авторизации пользователей.

Теперь давайте поговорим о решении.

Как и в случае с Мегафоном, основным упущением разработчиков называли неправильно сформированный (или отсутствующий) файл robots.txt. Согласен с тем, что наличие правильных инструкций в файле в данном случае помогло бы не допустить проблему, однако, в общем смысле это неполное решение, так как robots.txt — это всего лишь инструкции рекомендательного, а не директивного характера. Хорошо, что robots.txt принимают во внимание поисковые боты сегодня, однако, как это будут обрабатываться в будущем — вопрос открытый. Вдруг что-нибудь в боте сломается. Или бот будет не поисковым…

В этой связи полностью (в самом общем случае) решить вопрос можно, конечно, только введением обязательной авторизации пользователя для просмотра всех приватных страниц. В случаях же, когда это недопустимо, и пользователю надо сразу показать некоторую приватную информацию сразу после перехода по ссылке с явно указанными GET-параметрами (как в примере с трассировкой отправлений), технически представляется разумным сразу после перехода по ссылке делать PHP-редирект на страницу без этих параметров, запоминая их в сессию. Это позволит не довести параметры до JS-счетчика, установленного на странице (Яндекс.Метрик, Google Analytics, чего бы там ни было) — и я бы рекомендовал разработчиками обратить на это внимание, сделать такие редиректы в своих проектах. Впрочем, это тоже частичное решение, ведь вдруг адрес еще до редиректа будет замечен установленным баром или плагином для браузера. Ну или введить дополнительную авторизацию по косвенным параметрам (как сделали с проверкой фамилии)…

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

Учитесь на ошибках других, и старайтесь делать это вовремя. Спасибо за внимание.

UPD: Кажется, проблема только набирает обороты. Теперь, вот, железнодорожные билеты: http://news.yandex.ru/yandsearch?cl4url=www.ria.ru%2Fsociety%2F20110725%2F407118103.html
Tags:
Hubs:
+99
Comments 520
Comments Comments 520

Articles

Information

Website
www.webasyst.ru
Registered
Founded
Employees
11–30 employees
Location
Россия