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

    Мы являемся разработчиками скрипта интернет-магазина 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
    Webasyst 31,70
    Компания
    Поделиться публикацией
    Комментарии 520
    • +6
      Хм, думаю разработчикам yandex метрик следует добавить параметр dontIndex в их js api
      • –7
        Я думаю разработчикам магазинов нужно правильно делать архитектуру проекта.
        Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?
        Да просто разработчики наплевали на стандарты и спецификации, касающиеся разделения прав пользователей. Ответ мне напоминает стиль: «сам дурак».
        Ребята, не надо отмазываться — это ошибка ваша и больше не чья. С такой архитектурой проекта только… сказал бы, но здесь и детей много.
        • 0
          Да какая архитектура в данных конкретных «фэйлах Яндекса» — robots.txt было бы достаточно.
          • +1
            Скрытый разработчик Webasyst, или бывший разработчик )))
          • +9
            Опять прикрываемся robot.txt, это привязка к конкретному случаю. Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую. Я уверен что разработчики и сами понимают в душе, что виноваты они. Просто теперь пытаются сохранить хорошую мину при плохой игре.
            • +3
              Я к тому, что в данных случаях («неделя Яндекса») не нужно было привлекать гуру архитектуры или суперспецов по криптографии — пары строчек в одном файле хватило бы. Другие уязвимости остались бы, но не эта. А все уязвимости закрыть вроде невозможно — вроде как все современные методы аутентификации базируются на теории вероятности и комбинаторике, что не исключает «благоприятного» исхода при первом же испытании.
              • 0
                Доверять «авторизацию» по одной строке get — дилетантская ошибка, согласитесь. А взломать можно любую систему, любым алгоритмом, на крайний случай социальным (методы бывают разные — начиная от троянов секретарше, заканчивая силовыми) :)))
                • +2
                  Не хватало только, чтобы авторизацию доверяли. Аутентификацию вот доверили и уже скандал, а прикиньте, если авторизацию? если Яндекс начнёт контент на сайте менять или сообщения пользователям рассылать? O_o
                  • –1
                    Называем вещи своими именами (назовите хоть х, как на заборе (хотя это ж не х, а забор)) — это и есть фактически частная авторизация, которую решили разработчики сделать через один get запрос.
                    • 0
                      Фактически это идентификация, а что разработчики решили на её основе проводить авторизацию…
                      • +2
                        Ну опять вы начинаете демагогию.
                        Пользователь получил «права», право на то, что он может проследить заказ, и только он и админы. Так как он получил какие-то права, значит он должен быть авторизирован, путь хоть временно, но авторизирован, а авторизация под собой подрузомевает, что? ;) Но уж не как по одному запросу get. Я написал про забор, как его не называй и что на нем не пиши — он забор.
              • +2
                >Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую

                да, давайте все будем умными и красивыми, будем писать правильный код с первого раза и не допускать дыр.
                • 0
                  Знаете, сарказм, признак примитивного юмора. Представьте, вас послушают и будут писать код, который никто кроме «него» не прочтет, от этого «ему» легче будет? Сомневаюсь.
                  Есть основопологающие принципы, которых надо придерживаться изначально, тогда легче жить будет, особенно другим, как мы видим.
                  Всегда, и везде будут дыры, но млин, не такие примитивные и детские. Если бы не забывали изначально про принципы построения, то такой фигни бы не было.
                  Я как разработчик считаю, что дыра была детская. Называя вещи своими именами вы предоставили авторизацию (да, да если пользователю предоставили какие-то права — это уже авторизация, пусть и временная), через один get запрос.
                  • +3
                    >Представьте, вас послушают и будут писать код, который никто кроме «него» не прочтет, от этого «ему» легче будет?

                    извините, я сейчас пьян, можете объяснить проще, что за хуйню вы несете?

                    >Если бы не забывали изначально про принципы построения, то такой фигни бы не было.

                    да-да, а если при написании кода на сишечке не забывать про то, что на каждый malloc() должен быть свой free(), то больше половины дыр в софте вообще бы не было.

                    еще раз извините за переход на личности, но мне кажется, что вы не понимаете, что такое разработка ПО, откуда в нем берутся дыры и почему они вообще бывают.

                    аутентификация гет-запосом — вынужденная мера, один из сайд-эффектов которой не был учтен. это выглядит глупо (как и большинство дыр) исключительно потому, что уже найдено.
                    • +2
                      > но мне кажется, что вы не понимаете, что такое разработка ПО
                      Ну да 20 лет стажа и университет по профилю, мало.
                      Не обижайтесь: по вашей пьяни — это вы сейчас не понимаете что несете ;)
                      • +2
                        > Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?

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

                        вообще, я видел нескольких разработчиков 45+ лет. у всех 20 лет стажа, всё знают, цикл написать не могут и inner join от left join не отличают. но на словах-то все линусы торвальдсы, эрики липперты и гвидо ван россумы.
                        • 0
                          >вообще, я видел нескольких разработчиков 45+ лет.
                          Идиотов везде хватает и в 20 лет. Вы плохо думаете о разработчиках. Как раз архитектурное мышление приходит позднее.

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

                          Причем здесь это ;)? Понятное дело могут, но в 90% открываются в том же браузере, а остальным 10% — пусть введут временный пароль (пока действует отслеживание заказа), который есть (разработчик должен об этом позаботиться) в письме.
            • 0
              Вы статью-то читали? ссылка принимается там, где авторизация недопустима.
              • 0
                применяется*
                добавлю: какие здесь куки?
              • 0
                Можно ссылки на стандарты и спецификации, на которые наплевать разработчикам?
                • +2
                  RFC 2616
                  15.1.3 Encoding Sensitive Information in URI's
                  Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
                  • +1
                    Здесь же речь о формах. Подразумевается, что не стоит делать метод формы GET, если в ней передается номер кредитной карты :)
                    • –1
                      Это единственная придирка к букве текста, которую можно найти, да.
                      Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
                      Так что подразумевается здесь совсем другое.
                      • 0
                        В приведенном отрывке речь идет исключительно о формах. Примеры не смотрел.
                        • +1
                          Написано же
                          Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties.
                          Да и раздел называется «Encoding Sensitive Information in URI's». Если кто-то использует HTTP на серверной стороне не прочитав описание, то ССЗБ, жаль, что страдают от этого пользователи.
                          • 0
                            Вырвано из контекста ;)

                            Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
                  • +1
                    RFC 2616 не рекомендует (SHOULD NOT USE) передавать «чувствительные» данные в URI.
                    • 0
                      упс, не обновил
                • +2
                  Также известный как robots.txt.
                • +15
                  Достаточно сделать вывод информации о заказе, после ввода email клиента, например.
                  • 0
                    Согласен, но в данном случае мы решили сделать дополнительную идентификацию по фамилии клиента.
                    • +9
                      «Пароль» можно и в письме прислать. Тогда его совсем никто знать не будет.
                      • +3
                        Не поможет… не будем забывать на чьих серверах обрабатывается почта.
                        Кто сказал, что нельзя ссылки брать и из писем, раз уж они все равно парсятся для подбора релевантной рекламы.
                        • +4
                          Кто говорил что какие-либо ссылки берутся из писем??

                          Имеется ввиду следующее:

                          Ваш заказ номер 745867 успешно добавлен.
                          Используйте свой емаил idtyc@tufv.ru для входа и управления заказами.
                          Пароль для входа: 76fgtfiu7i7f6tgy (Вы можете его сменить через профиль)

                          примерно так…
                          • 0
                            Все гораздо-гораздо проще. Генирить номара заказов не по порядку и для просмотра статуса заказов использовать этот номер.

                            Плюс к этому слать все обновления по емэйлу.
                            Плюс не показывать завершенные заказы.
                            Плюс анонимусам показывать минимум приватной инфы (как это кстати часто делается с трекингом). Детальная информация все равно должна приходить первым письмом. А тут оставить только адрес с детализацие до населенного пункта, сумму заказа, и статус.
                            • 0
                              Генирить номара заказов не по порядку и для просмотра статуса заказов использовать этот номер.

                              Как показывают последние скандалы — это не панацея.
                              Плюс не показывать завершенные заказы.

                              Не юзабельно — проверяю я статус заказа: «идёт», «идёт», «идёт», 404 нет такого заказа — и что мне думать?
                              • 0
                                > Как показывают последние скандалы — это не панацея.

                                Насколько я понимаю, последние скандалы показвают, что не разумно передавать идентификаторы пользователя в GET-параметрах. В моем случае, пользователь по ссыке из письма попадает на старницу с полем «Введите номер заказа» и post-формой.

                                > Не юзабельно.

                                В сочетании с email-нотификациями — вполне. Более того, при грамотных email-нотификациях (почти) никто вобще не пойдет в магазин проверять статус заказа.

                                В идеале — прятать заказ после подтверждения о доставке покупателю (после этого зачем покупателю возвращаться и проверять статус?). При нашем несовершенном шиппинге — через какой-то разумный таймаут. Можно подумать как это реализовать.

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

                                Показывать всю приватную инфу чуваку, пришедшему по ссылке — это верх корявости.
                                • 0
                                  Про пост-форму вы не упомянули, сорри.

                                  Ну не знаю, за последние лет 5 мой режим использования почты сильно изменился, прежде всего перестал использовать десктопные клиенты, теперь уведомления о новой почте не появляются, захожу смотреть почту в основном на предмет просмотра рассылок или когда где-то зарегался. Заходить смотреть не изменился ли статус заказа будет неудобно.
                                  • 0
                                    > Про пост-форму вы не упомянули, сорри.

                                    My bad. :)

                                    > Заходить смотреть не изменился ли статус заказа будет неудобно.

                                    Ну, тут у каждого свой кейз. Сейчас, имхо, тренд на мобильные клиенты, и email-нотификации гораздо более оперативная и удобная штука. Чтобы никуда не ходить и не проверть по 10 раз изменился ли статус.

                                    Но мой главный поинт был даже не в том. Сейчас все ругаются, одни обвиняют Яндекс, что проиндексировал через метрику, другие — владельцев магазина (robots.txt, etc). Мой поинт, что главный фейл — в том, что все эти приватные данные были доступны по ссылке (не важно насколько она супер-секретная), без какого-либо процесса аутентификации. Хоп и все! Тыкнул и читаешь.

                                    Это и есть криворукость разработчиков движка. Как, в каком виде это реализовать — это другой вопрос. Тут можно сесть командой в переговорке и за 2 часа придумать красивое изящное решение. Или сделать несколько и давать на выбор. По-разному можно сделать. Но не так.

                                    А яндекс на сам деле так или иначе проиндексировал _публичные_ ссылки. От того, что о них никто не знает, они публичными быть не перестают.
                                    • 0
                                      Это да, их фэйл. Но вот юридическую ответственность за то, что данные утекли несут всё же владельцы магазинов — пользователи пользовались их услугами и сообщали данные им, а не разработчикам. Владельцы сайтов могут попробовать обратиться к разработчикам с требованием возместить вред, включая недополученные доходы и урон деловой репутации, но сомневаюсь, что такое требование имеет судебную перспективу — наверняка «AS IS», «no warranty» и т. п.
                      • +5
                        Обычно в таких случаях просят ввести кодовое слово, может быть и ФИО. Ну нельзя чтобы без каких-либо ограничений открывалась страница с персональными данными просто при переходе по ссылке — это неправильно! Это нарушение любых понятий об ИБ.
                        • 0
                          как вариант можно сделать отправку пользователю на email ссылки с одноразовым токеном — он перешел 1 раз, авторизовался, смотрит свой заказ. если кто-то другой попробуйет перейти по той же ссылке — ему выдастся ошибка что токен уже использован.

                          При использовании токена пользователю сразу высылать новый чтобы потом он смог еще раз зайти. Получается система без дополнительных требований что-то ввести, без лишних редиректов и т.д.
                          • +1
                            Ок. А если токен оказался скомпрометирован еще до того, как по нему перешел пользователь 1 раз?

                            Надеемся на почту? На то, что ссылки из писем не ставятся в очердь на индексирование?
                            • +1
                              если авторы надоумились писать в один хеш все данные пользователя для входа и не спрашивают пароль(который могут поставить сами на время пока пользователь не поставит свой) — это большая ошибка.
                              Перейдя не только на поисковик, но на сайт недобросовестного вебмастера счастливый обладатель заказа может пострадать.
                              Думаю или из писем или из других источников проявились эти дырки — обязательно выяснят.
                            • +1
                              Одноразовый токен не годится. Есть почтовые антивирусы (или антиспамы), которые при получении почты еще до доставки её в ящик ходят по указанным в письме ссылкам на предмет «не раздаёт ли она зловреды» или «не спамные ли страницы» (если в письме ничего кроме ссылки нет, то антиспам анализирует страницу по ссылке), т.е. фильтр съест такой счетчик, не оставив пользователю.

                              У меня альтернативное предложение, как не сдавать роботам закрытые страницы, если нужно отдавать их без авторизации: подгружать «секретную часть» страницы ajax'ом. Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят. И яндекс.бар не спалит.
                              • –1
                                Выход один — куки, или авторизироваться :)
                                • 0
                                  >Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят

                                  да лаааадно, не запускают…
                                  • 0
                                    Неужто запускают? А я такой трюк с подгрузкой применял, страницы попали в индекс без подгружаемого блока — почему тогда?
                                    • 0
                                      Яндекс и гугл очень неплохо научили запускать ajax скрипты, причем сами.
                                      У меня движок заточен под ajax запросы, но без дела я их не применяю, так вот google почему-то посчитал переменную в js var block как дополнительный параметр и сам вызвал все ссылки с этим параметром, логику я гугла конечно не понял, но у меня так вызываются ajax версии запросов, т.е. тот же url с параметром block. Откуда он это взял я так и не понял до сих пор. Но суть в том что он проиндексировал все блоки вызвав их ajax методом, даже каптчу проиндексировал :)
                                      Мало того у меня все url вида /la-la-la (реальные сами понимаете /la/la/la так вот гугл выдрал из js переменную real_url, где я для js скриптов хранил реальныу пути и присвоил всем ссылкам такую вот фигню, соответсвенно проиндексировав их, хорошо не все я вовремя убрал переменные block и real_url. Но логику гугла до сих пор не понял. Я так понял они учат бот «инстинктивно» запускать и различать всякие там url и block, кстати на основе популярных cms.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • 0
                                  Поисковик не будет совать фамилию из кэша совать во все поля на индексируемых страницах, чтобы пройти дальше. И вообще, как уже здесь кто-то писал, это сделано чтобы защитить новых клиентов, а их фамилий ещё нет в кеше
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +1
                                      Что утекло — то утекло. Теперь нацелены силы на то, чтобы защитить новых. Со старыми будут разбираться другими методами: например, просить яндекс убрать из кеша данные
                            • +1
                              Сопутствующий вопрос — зачем на странице трекинга заказа показывать персональные данные получателя и содержимое заказа?
                              • 0
                                С этой страницы клиент может перейти к оплате заказа и получить данные об оплаты: например, распечатать счет или квитанцию. Эти действия предполагают вывод информации о клиенте и составе его заказа. Поэтому вся эти информация показывается. Это такой маленькие «личный кабинет», ограниченный всего одним заказом (так как пользователь не зарегистрирован с постоянным логином-паролем, других связанных данных у него нет — только заказ).
                                • 0
                                  А еще можно показывать сокращенную фамилию и сокращенный адрес :) Как номера кредитных карт никогда не показывают на страницах полностью — наверняка уже давным-давно на грабли с утечками натыкались.
                              • +7
                                Вся ответственность, безусловно, лежит на разработчиках движка.
                                Дело тут не в поисковике, даже если он не должен был что-то-там индексировать. Проблема в том, что личные данные были в открытом доступе, авторизации не было предусмотрено.
                                • +14
                                  Мы и не снимаем с себя ответственности. Конечно, следовало делать дополнительную идентификацию клиента (что и внедрили сегодня в виде патча), однако, стоит обратить внимание и на поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс. На наш взгляд, эту практику необходимо менять, иначе подобные проблемы в рунете могут (и будут) происходить еще со многими сайтами и скриптами.
                                  • +2
                                    Не факт, что виновата Метрика. Вполне может быть виноват какой нибудь аддон|плагин к броузеру.

                                    Но факт, что разработчики часто забывают про robots.txt. И про мета тег noindex.

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

                                    Если сломается, то это уже будет не ваша вина. И будьте уверены Гуглу или Яндексу придется оплачивать приличные суммы если утечет приватная информация.
                                    • +3
                                      В действительности яндекс очень четко следует robots.txt и пока у нас нет в известности ни одного случая его нарушения. Так что действительно, попытка перекинуть все на Яндекс авторами движка как-то очень криво смотрится.

                                      Неужели нельзя было добавить учитывающий это robots.txt в стандартную поставку? Я уверен что можно.
                                      Неужели сейчас нельзя признать свою ошибку? Мне кажется, это тоже следовало бы сделать.
                                      • –1
                                        Более того, ваш скрипт мог бы отдавать:


                                        Почему это не заложено в движке? Тоже кривая метрика виновата?
                                        • 0
                                          Не знаком с движком, но есть подозрение, что скрипт только выводит данные в шаблоны, созданные веб-мастерами/верстальщиками на основе шаблонизатора типа Smarty.
                                          • +2
                                            В таком случае помог бы robots.txt. Плюс в движке можно завести переменную, что страница приватная, по которой шаблон должен выводить этот мета-тег. Это в любом случае полезно, т.к. пользователи с барами, хромами и прочими троянами были есть и будут, и если не яндекс, так гугл, бинг или яху — все равно бы это сделал, т.к. давайте будем честными — авторы пренебрежительно относились к этой угрозе.
                                            • 0
                                              Если действительно используется шаблонизатор в режиме включения вывода движка в шаблон (я бы сделал так), а не наоборот, то ни один тег без явного указания в шаблоне не выведется. То есть угроза того, что данные «утекут» (будут проиндексированы честным поисковиком) мета-тегом в общем случае не устраняется — максимум в мануал можно включить рекомендацию этот тег ставить для таких страниц.
                                              • 0
                                                Мануал + robots.txt, не забывайте. robots.txt уже и так будет с головой, и если он будет идти в стандартной комплектации — его не забудут. Вообще не понимаю, почему это валят на вебмастера? Разве это не часть движка? В целой куче движков он идет уже готовый.
                                                • 0
                                                  Это я просто забыл дописать, хотел, но забыл :) По-моему логическое следствие из того, что мета-тегом угроза не устраняется.
                                        • +1
                                          Хабрапарсер съел HTML:
                                          <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
                                          • 0
                                            Используйте псевдоэлементы <source></source> для предохранения блоков кода от поедения их парсером Хабрахабра.
                                          • 0
                                            Ошибка не в робот.txt она более глобальная, на уровне наплевательства на стандарты безопастности.
                                            • 0
                                              прекратите клеймить и нагнетать. проебали, пофиксили, бывает.

                                              я вот сейчас подумал и вспомнил, что в одном проекте мы такой же способ применяли. потомучто это удобно. и ссылка там не может быть одноразовой. шо делать, повеситься?
                                              • +1
                                                Пофиксить! :)
                                                • +2
                                                  Ну разработчик ошибку то не признал ;) И начинает отмазываться, а здесь не все великие программисты, начинают верить отмазкам, потом все это начинают рассказывать своим друзьям, потом ламерить и т.п. Вот к чему я.
                                                  Пусть напишет как вы сказали: мы прое… ли, бывает. Пофиксили.
                                                  Не вешаться не надо. Если вы делали проект на основе своего движка, совет: ни в коем случае не вешаться, и второй: ping-update (если интересно что это, могу написать в личку) прикрутить к движку.
                                                • –1
                                                  Скажите пожалуйста, о каких стандартах вы говорите? Вы можете привести ссылку на какие-то материалы освещающие эти стандарты?
                                                  • +2
                                                    RFC 2616
                                                    • +1
                                                      Спасибо!
                                                      Из рекомендаций RFC по использованию протокола HTTP можно сделать два вывода:
                                                      1) В GET параметрах нельзя передавать частную и чувствительную информацию,
                                                      2) Программы которые раскрывают ссылки, которые не предназначены для публики, занимаются сливом персональных данных.

                                                      Согласны?
                                                      • +2
                                                        По-моему 2 противоречит 1. Раз нельзя в GET параметрах передавать ничего важного, значит в ссылке нет ничего важного и её можно публиковать.
                                                        • 0
                                                          В самой ссылке нет ничего важного, но на странице на которую она ведет — может быть важное. И если программа показывает содержимое страницы, не предназначенное для всех, потому что она смогла увидеть это содержимое, используя своих «жучков» — это слив. Помоему так.
                                                          • 0
                                                            А по-моему нет. То, что не предназначено для всех должно быть защищено аутентификацией и авторизацией. А раз показывается любому, знающему адрес, то эта информация считается (законом) общедоступной.
                                                            • 0
                                                              Согласно законодательству РФ:
                                                              1. К общедоступной информации относятся общеизвестные сведения и иная информация, доступ к которой не ограничен.


                                                              Персональные данные хранились на странице, ссылка на которую выдавалась только владельцу — вот такое ограничение. С другой стороны RFC говорит, что ссылка не может быть ключом, потому что она везде светится — логируется, передается в реферере и прочее. В общем, defected by design, как тут уже кто-то сказал.

                                                              Остается вопрос — насколько это порядочно со стороны Яндекса, брать ссылки из всяких странных мест. Ведь не все знали, что их может найти поисковый бот — на сайте-то на них ссылки нет. Это похоже на то, как если бы кто-то копался в моей сумке, пока я отвернулся. Но это лично мое мнение, а не мнение общественности. А мнение общественности здесь как раз и имеет определяющее значение.
                                                            • 0
                                                              Вы ошибаетесь.
                                                              В самой ссылке есть важное.
                                                              Сама ссылка — это authentication credentials. Аналог логина и пароля.
                                                              Которые нельзя передавать ГЕТом.
                                              • +1
                                                > поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс.

                                                Чем страница /a/b/c отличается от страницы /d/e/f с точки зрения поискового бота? ничем. То, что страница /d/e/f приватная известно только вам
                                              • +18
                                                Что значит в открытом доступе? По сути, страница с персональными данными возвращается при предъявлении уникального хеша, известного только пользователю. Яндекс эти хэши тупо пиздит. Этот примерно то же самое, как если бы яндекс пиздил вводимые пароли и индексировал, например, почту.
                                                • +9
                                                  Не забывайте, что это всего лишь бот. Он кушает всё, что ему дают.
                                                  • –2
                                                    О том и разговор, что адреса посещаемых сайтов, не говоря уже про передаваемые в адресной строке параметры — персональные данные. Яндекс как минимум не должен их публиковать, а по-хорошему не должен их вообще собирать. Тогда и вопроса о том, что именно нельзя индексировать не возникнет. Ещё раз, речь идёт о данных, получаемых яндексом с помощью клиентских скриптов и браузерных плагинов с компьютеров пользователей.
                                                    • +1
                                                      А каким образом бот должен понять что это персональная/приватная страница? Если она доступна простым запросом, если нет никаких метатегов, если нет информации в robots.txt?
                                                    • +1
                                                      Вопрос в том, кто скармливает ссылки боту?
                                                      Если он их находит на просторах интернета — это одно, а если он их получает из метрики, то тут пускай уж удосужится проверить ссылку на общедоступность (хотя бы просто поискав эту ссылку в своей же базе)
                                                      • 0
                                                        Если ссылки нет в базе, не значит, что она не общедоступна (инче новые ссылки в яндексе никогда не появлялись).
                                                      • –1
                                                        Вот именно. Боту дают ссылку из приватного имейла. Это нормально?
                                                      • +4
                                                        Не примерно. Как минимум общепринято («обычай делового оборота» — есть такой термин в юриспруденции), что секретные/конфиденциальные/персональные/личные/… данные не передаются в GET запросах по HTTP протоколу.
                                                        • +2
                                                          Увы, это не так. Ссылка с ключем авторизации в параметре это слишком удобно, чтобы от этого отказываться, и ее используют довольно многие (в том числе Мой Круг, кстати). Поэтому хорошо бы решить эту идеологическую проблему.
                                                          • 0
                                                            Сделать её одноразовой (МойКруг, кажется, именно так её использует)? Пока пользователь не перейдёт по ней в браузере о ней никто не узнает (кроме хакеров и индексаторов почты), а когда узнает, то смысла знать её уже не будет!
                                                            • 0
                                                              Надо посмотреть. А если пользователь захочет по ней пройтись дважды из своего письма?
                                                              • 0
                                                                В момент перехода выслать ему вторую уникальную ссылку.
                                                                • –1
                                                                  Действительно, у МоегоКруга они одноразовые.

                                                                  Ага, и забить ему почтовый ящик :)
                                                                  • 0
                                                                    В какой мемент перехода высылать вторую ссылку? В первый раз или каждый раз.
                                                                    • 0
                                                                      Как только одноразовая ссылка использована — высылать новую, если уж так не хочется аутентифицировать по кукам и/или паролю.
                                                                      • 0
                                                                        А при повторном обращении по уже использованной ссылке, что должно происходить?
                                                                        Что делать, если отправленная новая ссылка не получена адресатом?
                                                                        • +1
                                                                          если отправленная новая ссылка не получена адресатом

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

                                                                          при повторном обращении по уже использованной ссылке

                                                                          выводить сообщение «ваша ссылка устарела, зайдите пожалуйста на почту и перейдите по новой».

                                                                          Ну и в рамках одной сессии подразумевается что человек может кликать по «использованной» ссылке сколько влезет — она будет работать верно т.к. человек уже авторизован. Когда кончается сессия чтобы снова авторизоваться он переходит по новой ссылке.
                                                                          • 0
                                                                            >самыйпростой способ — телефон

                                                                            Забавно, что это самы простой способ решения не только этой проблемы, но и вообще почти всех поднятых в этом топике.

                                                                    • 0
                                                                      Сделать авторизацию как сделали авторы (по фамилии) можно по почте, по фамилии, по чертче чему еще кто знает, букву в почте присылать которую нужно вставлять, и все эти данные уже будут защищены на порядок выше.
                                                                  • 0
                                                                    Угу, а что будет, если по этой ссылке первым перейдет индексатор, а не пользователь?
                                                                    • 0
                                                                      А что будет если ваш трафик снифают или кейлоггер у вас сидит? Афаик, нет ни одного случая умышленной передачи персональных данных или переписки из почты третьим лицам известными почтовыми сервисами, если они не обязаны были это сделать по закону или пользователь явно не выразил такого желания.
                                                                      • +2
                                                                        Механизм, которым «непубличные» URLы попали в индексаторы до сих пор неизвестен и никаких официальных комментариев, насколько я знаю, до сих пор не было сделано. В качестве одной из версий — называлось то, что индексируются URLы, найденные в почте.

                                                                        То, что туда ходят краулеры — я сам прекрасно знаю, неоднократно наблюдал в логах своих веб-серверов — когда ссылки, которые упоминались только в почте, внезапно посещали клиенты с чудесными словами Yandex и Google в user-agent. На вопрос — попадали ли в итоге посещаемые страницы в публичный поисковый индекс — я пока ни однозначного утвердительного, ни однозначно опровергающего ответа не знаю.
                                                                        • 0
                                                                          Да найдены они могут быть где хочешь. Вопрос в том, что разработчики наплевали на нормы и стандарты безопасности, если бы они их соблюдали изначально, такого бы не было.
                                                                          • 0
                                                                            Вы уверены, что только в почте? Что пользователи (или вы) по этим ссылкам не переходили до их визита краулером?
                                                                            • +1
                                                                              URLы достаточно персонализированы. Пользователи — достаточно инертные работники бюджетных организаций, ходят с рабочих компьютеров в рабочее время.

                                                                              Наблюдал развитие по примерно следующему сценарию:

                                                                              1. Письмо со ссылкой отправляется в ~20:00 MSD (нерабочее время рабочего дня)
                                                                              2. В ~23:00 MSD приходит робот
                                                                              3. В ~10:00 MSD следующего рабочего дня приходит легитимный пользователь — получатель этого письма и начинает свою сессию работы с системой
                                                                              URL, насколько я мог проверить, в поисковый индекс так и не попал.
                                                                              • 0
                                                                                Это да, серьёзный повод задуматься. А почта была у одного почтовика?
                                                                                • +3
                                                                                  Почта рассылалась автоматически из скрипта, запускаемого вечером по cron через собственный smtp-сервер. Адресатов порядка нескольких десятков, ссылки у каждого уникальные и персонализированные. Прямой корреляции типа «послал на gmail => придет Googlebot», «послал на yandex => придет Yandex» не строил, но подозреваю в первую очередь все-таки индексацию URL из почты.

                                                                                  Собственно, сейчас посмотрел на то, что выдает Google и Яндекс при поиске по обозначенному сайту, ситуация, прямо скажем, странная. Сайт состоит из:

                                                                                  • одна страничка dashboard-style морды — доступна свободно, на ней список URL подсистем
                                                                                  • n подсистем, каждая из которых закрыта авторизацией
                                                                                  • открытая «публикующая» часть внутри каждой подсистемы, обеспечивающая отображение подготовленной в системе информации по ряду открытых URL — частично они рассылались упомянутым выше cronjob'ом

                                                                                  А интересно и странно то, что Google честно показывает для этого сайта в индексе только одну открытую морду, а Яндекс зачем-то и откуда-то заиндексировал еще 3-4 очень странных внутренних URL, причем отрубив у них query; для внешнего человека без авторизации они и так в любом случае нерабочие, но без query — они даже с авторизацией будут выдавать внутренние ошибки системы. Эти внутренние URL (особенно в таком обрезанном виде) вряд ли когда-либо пересылались через почту, зато вполне вероятно, что какой-то из пользователей имеет Яндекс.Бар.

                                                                                  Никаких внешних счетчиков и javascript'ов на сайте не стоит.
                                                                          • 0
                                                                            ну вот например, если отправить в gtalk ссылку на ютуб, то умный клиент на андроиде быстренько загрузит превьюшку.

                                                                            что мешает ему в какой-то момент решить подгружать любую страницу, чтобы вместо длинной дурацкой ссылки показывать содержимое тега «title»?
                                                                        • 0
                                                                          Ну нельзя делать их одноразовыми вам уже кажется писали. Антивирусы проверяют, сбрасывая счетчик, расширения ит.п.

                                                                          Только куки или авторизация — это в принципе, то, основная концепция авторизации, но уж ни как не через get (а это именно в конкретном случае и была авторизация — будем называть вещи своими именами) запрос (ну просто детская ошибка).

                                                                          И не надо делать вид разработчикам что они здесь не при чем, всё они знают как лоханулись, только надож хоть немного «кармы» продукта сохранить, только вот на карму хабра можно наплевать, а вот от «кармы» продукта зависит фактически жизнь компании. Поэтому и не признают, и не признают. Но для специалистов — виновник известен, рассказывайте басни дальше и другим.
                                                                          • 0
                                                                            Я имел в виду «условно одноразовые»: приходит пользователь с кукой — даём ему доступ один раз. Приходит без куки (или второй раз?) — даём 401 (403?) и просим пароль, высланный в том же письме, что и ссылка. Где-то в комментах расписывал подробнее.
                                                                            • 0
                                                                              Достаточно привязать первый запрос к ip пользователя.
                                                                              • 0
                                                                                Так не надо делать, на одном ip могут сидеть тысячи пользователей :) куки и еще раз куки
                                                                                • 0
                                                                                  У меня динамический IP от нескольких мобильных провайдеров, а статический расшарен чуть ли не со всем районом (НАТ).
                                                                                  • 0
                                                                                    И как это помешает Вашей анонимности в поисковиках при получении Вами ссылки?
                                                                                    У яндексбота другой IP :)
                                                                                    Ну а если бояться сниффинга — тут поможет только SSL
                                                                                    • 0
                                                                                      При использовании мобильного провайдера я сам не смогу перейти второй раз по ссылке (айпи будет уже другой), а при использовании стационарного по ней сможет зайти любой человек с района.
                                                                          • 0
                                                                            Одно дело прикрывать ключиком фоточки, другое дело прикрывать, таким вот ключиком, личные данные, включая полное имя/отчество, мыло и адрес доставки!
                                                                            Тот же амазон 10 раз переспросит логин пароль, пока я доберусь до смены адреса.
                                                                            • 0
                                                                              Я вижу как вариант для интернет-магазинов предлагать указывать не фамилию, а псевдоним. Данные сразу перестают быть персональными.
                                                                              • 0
                                                                                Посылку отправляют на адрес и выдают по паспорту…
                                                                        • 0
                                                                          Круто, а, то что любой провайдер/снифер/проксисервер/другое так же спокойно как и яндекс могут парсить эти get запросы, создателей движка не должно волновать?
                                                                        • +1
                                                                          Вы так говорите, что все, что находится в интернете, должно передаваться только безопасным путем. А как быть с людьми, которые работают в небезопасной Wifi и кто-то начнет собирать пароли и индексировать, что находится внутри. Или при аутентификации открытым токеном, который передается в HTTP Property. А уникально сгенерированный ключ в запросе слабая, но все-таки защищенная ссылка.

                                                                          Даже Гугл, который относится к безопасности очень ревностно, позволяет расшарить фотографии и документы только на основе ссылки.
                                                                          • 0
                                                                            Даже Гугл, который относится к безопасности очень ревностно, позволяет расшарить фотографии и документы только на основе ссылки.

                                                                            Ключевое слово «позволяет расшарить».
                                                                            • 0
                                                                              Кстати да, Гугл документы расшариваются по ссылке. (если вноват яндекс бар или другой плагин) Похоже можно пробовать искать в Яндексе и эти приватные документы.
                                                                            • +6
                                                                              Долгое время механизм уникального урл, известного только пользователю, де-факто являлся авторизацией. Создав Метрики, Бары и т.п., поисковые системы поломали этот механизм. Механизм, который используется везде.
                                                                              Конечно, Яндекс может прикрыться законом о персональных данных и сказать — «теперь защита от нашего бота — это ваша проблема», но очевидно, что данную ситуацию Яндекс просто проворонил.
                                                                              Я согласен насчет robots.txt: поисковым системам он не указ и на половину параметров в нем они просто плюют.
                                                                              • +7
                                                                                Вы счас это серьезно про механизм, который используется *везде*?
                                                                                /me Взглянул на дату; нет, не `96-й на дворе…
                                                                                Расшаривание ссылки гуглом — отдельная история, она, во-первых, передается человеку лично (по емэйлу, Im и т.д), во-вторых, предполагается, что она выдается на короткое время.
                                                                                К слову, даже в древние времена де-факто авторизацией являлась Basic Auth, описанная в rfc1945.
                                                                                Да, и яндекс предоставляет свой сервис бесплатно, а в условиях использования ясно сказано:
                                                                                Пункт 11. Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные данные [...] и в автоматическом режиме передаёт их Яндексу [...] доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.
                                                                                • 0
                                                                                  Именно используется. Именно везде. В условиях, когда магазины борются за клиентов, в приоритете всегда будет максимально простой сервис.
                                                                                  собирает анонимные данные

                                                                                  «Вы счас это серьезно про» «анонимные данные»?
                                                                                  • +2
                                                                                    расскажите-ка, как робот должен отличать «анонимные» get-параметры от «неанонимных»?
                                                                                    • –3
                                                                                      Спросите об этом людей, персональные данные которых скриптами скопировали все, кому не лень.
                                                                                      • 0
                                                                                        Скопировали, потому что кто-то за этих людей (или, по некоторым данным, они же и сами) явно решил следить за этими людьми посредством счётчиков и плагинов.
                                                                                      • 0
                                                                                        Кстати, я смотрю на проблему несколько шире. Роботы роботами, а за выдачу Яндекс все-таки должен отвечать, как ни крути.
                                                                                        • 0
                                                                                          За всех говнокодеров никто ответить не в состоянии, кроме их самих. Может хоть уволят кого…
                                                                                          Это им удалось проигнорировать элементарные правила безопасности, robots.txt и свойство ut:'noindex' специально для метрики, куда уж тут шире смотреть?
                                                                                          • 0
                                                                                            За что увольнять-то?!
                                                                                            • +1
                                                                                              Это все местечковые «правила безопасности». Google noindex не учитывает, Яндекс начал учитывать nofollow только недавно, а завтра возьмет, и опять перестанет. Появится другая ПС — вообще на все наплюет. То, что в robots.txt учитываются не все директивы, похоже, неизвестно только вам. Т.е. robots.txt изначально учитывается частично. Все подобные меры просто смехотворны.
                                                                                              • –2
                                                                                                Да, согласен, смехотворны, но это были бы хоть какие-то попытки что-то прикрыть.
                                                                                                А вообще, ниже много на эту тему написано, можно толкать куку, которая бы аутентифицировала по ссылке.
                                                                                                Без куки был бы виден только статус заказа и список товаров, с кукой — фио, адрес, контакты, и прочее, что сейчас выставлено всем на обозрение.
                                                                                                • +1
                                                                                                  Да, можно было бы сделать много чего. Только когда придумывали механизм уникального урла, никому и в голову не могло прийти, что вебмастера будут добровольно ставить на сайты троянов. :)
                                                                                                  Вы представляете себе, сколько сайтов сейчас нужно переделывать? Т.е. сколько народу Яндекс и другие гипотетически поставили на деньги?
                                                                                                  • –2
                                                                                                    да кто вообще суёт в УРЛ хеши????
                                                                                                    какой век на дворе???
                                                                                                    • +1
                                                                                                      Какие деньги? Три-четыре (ну всяк не больше десятка) строчки на PHP и одну колонку в БД добавить, чтобы закрыть свою безалаберность и, извиняюсь, похуизм к отношению персональным данным клиента?
                                                                                                      • 0
                                                                                                        Что значит троянов, не пойму? Никто не скрывал, что метрика индексирует страницы, для этого есть параметр, предотвращающий это.
                                                                                                        Ну да, куча народу, а что делать? Или «миллионы мух не могут ошибаться»? )
                                                                                                        Общеизвестно, что в этой стране любят заказать магазин за 15к руб., а потом жаловаться что «ниработаит», ну сами виноваты, че.
                                                                                                        • 0
                                                                                                          Я за 2к рублей делаю магазины с роботс.ткст.
                                                                                                          • +1
                                                                                                            Буду рекомендовать вас ))
                                                                                                            • 0
                                                                                                              Без дизайна и вёрстки, только вёрстку на движок натянуть :)
                                                                                                      • 0
                                                                                                        Без куки нужно просить пароль, высланный в том же письме, что и ссылка. Сам факт, что сделан заказ (а тем более список товаров) может быть неприятен клиенту, если о нём узнают третьи (особенно близкие) лица, даже если клиент почистит куки.
                                                                                                  • –2
                                                                                                    как не крути — эта информация была доступна всем людям в сети…
                                                                                                    ещё чуть шире, попробуйте, поразмышлять
                                                                                                    • +2
                                                                                                      Вы вообще о чем?
                                                                                                      Доступна всем, когда Яндекс сделал ее доступной всем?
                                                                                                      До этого она была доступна только клиенту, получившему ссылку.