Webasyst
Компания
31,89
рейтинг
26 июля 2011 в 17:25

Разное → Почему находится всё: ответ Яндексу от разработчиков 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
Автор: @vofka
Webasyst
рейтинг 31,89
Компания прекратила активность на сайте

Комментарии (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
                  Вы вообще о чем?
                  Доступна всем, когда Яндекс сделал ее доступной всем?
                  До этого она была доступна только клиенту, получившему ссылку.
                  • 0
                    Почему Вы забываете о возможности просмотра «HTTP referer»???
                    Или этого мало???
                  • +2
                    Она была доступна до этого любому, «догадавшемуся» набрать нужный урл. Среди «догадавшихся»: правоохранительные органы, сотрудники провайдеров многих уровней, сотрудники администрации прокси-серверов, сотрудники создателей браузеров и, главное, расширений (добровольно установленных пользователем) к ним, сотрудники сайта, а также «тупым» брутфорсерам или просто людям, которым сопутствует удача. В стандарте http написано — нефиг передавать «чувствительные» данные гет-запросом — их пишут (а занчит и могут прочитать) все кому не лень!
      • +16
        Есть три основных понятия в данной сфере: идентификация, аутентификация и авторизация. Первое, грубо говоря, является процессом представления клиентом серверу «Я такой-то» (логин, ник, ФИО и т. п.). Второе — то же плюс доказательство, что клиент действительно «такой-то» (пароль, сертификат и т. д.). Третье — проверка сервером, что представившийся клиент (идентифицированный или аутентифицированный) имеет право на то действие, что запросил. Согласно духу и букве RFC 2616 аутенфицирующая (как и любая другая «чувствительная» ) информация не должна передаваться в GET-запросах
        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
      > данные были в открытом доступе, авторизации не было предусмотрено.

      Ну, секретный URL тоже ведь можно считать своего рода паролем…
      • +1
        Не нужно — прочтите цитату из RFC в моём комменте выше вашего.
  • –3
    У Яндекса — Метрика, а у Гугля — что?
    • +4
      Об этом написано поста:

      3. Яндекс проиндексировал именно такие страницы. Точнее, страницы, которые посещали покупатели (переходили по ссылкам из писем-уведомлений).
      4. Гугл и другие поисковики проиндексировали эти же страницы уже после того, как информация об этом появилась в новостных лентах, на Хабре и стала «достоянием общественности».
      • 0
        Вообще-то у Google есть аналог Метрики — Гугл Аналитика. Хотя о ней речь в данном ключе ни разу не заходила, возможно, сделали ее по уму.
        • +2
          Скорее метрика — аналог аналитикса.
          • 0
            С блэкджеком и индексацией писем.
            • 0
              Да не писем, что вы все к письмам привязались, метрика была установлена на странице куда вела ссылка из письма, и при загрузке этой страницы вместе с загрузкой метрики, она (метрика) выдавала яндексу «ололо, меня загрузили с такого-то адреса». Письма здесь вообще не причем.
  • +4
    Вот только в трекинге не отображается адрес получателя и содержимое его отправления.
  • +40
    Суммируя: разработчики скрипта обвиняют Яндекс, Яндекс обвиняет создателей сайтов, те, кто поумнее, обвиняют оленей-веб-мастеров, веб-мастера молчат в тряпочку, прочие журналисты просто пишут «Ололошеьки Яндекс слил вашу приватную информацию».
    Единственное, чего я не понимаю в данной ситуации — это что такое «Смазка с эффектом «Узкий вход».
    • +2
      Мы не обвиняем Яндекс — мы обращаем внимание на вопрос этичности и легитимности добавления любых адресов, которые нашел Яндекс с помощью своих сервисов, в общий публичный индекс.
      • +15
        а что Яндексу посадить миллион негров и азиатов и пусть они ручками каждый линк проверяют, что ли? Яндекс сделал то, что должне был сделать. Нашел ЛЮБУЮ ИНФУ, которая была в ОТКРЫТОМ доступе.
        Вопрос этичности к вам, товарищи разрабы.
        • +2
          Так в том и дело, что в данном случае доступ НЕ открытый.
          • +5
            открытость в инете априори. все что не скрыто, кушается ботами.
            • +8
              Боты кушают все, некоторые из них подбирают пароли и создают ботнеты, пользуясь принципом, что ненадежно защитили — ваши проблемы.
              • +3
                Угу, Вы пошли в лес голышом, даже без трусов, по-вашему, то, что Вас искусали комары и за причинное место клещ вцепился это вина комаров и клещей? А вот и нет: нехуй нудизмом заниматься в лесу полном кровососов.
                • +2
                  Или, ходя бы, репеллентом не помазаться (роботс.ткст не прописать нормально).
                • +4
                  Вот, наконец, и вывод дискуссии: поисковые машины — кровососы, паразиты и хищники? Яндексов бояться — в Сеть не ходить :)

                  Всё таки Яндекс в данной истории стащил URL НЕ СО СТРАНИЦЫ В ИНТЕРНЕТЕ, а скриптом на странице стащил адрес страницы или яндекс.бар'ом в браузере стащил адрес посещаемой страницы. В первом случае он без ведома пользователя запущенным у пользователя скриптом стащил приватные данные, во втором — вроде как с ведома (пользователь сам установил бар), но все равно приватные.

                  Если Яндекс в этой истории будет оправдан, то в будущем писатели кейлоггеров будут иметь прецедент-отмазку «а нефиг было пароль на клавиатуре набирать, она в открытом доступе (моему шпиону)». Может Яндекс.Бар кроме урлов и пароли сливает? Где его исходники? И что, он потом скажет, что надо было в robots.txt написать «яндекс, не используй мой пароль»?

                  Программисты шопа, конечно, виноваты, но это не значит, что Яндекс не виноват. И Яндекс виноват намноооого больше.
                  • +1
                    В первом случае он вроде как стащил с сайта данные с ведома владельца сайта. Пользователь (вернее его браузер, выполняющий скрипт) — лишь средство передачи этих данных.

                    Только кейлогерам нужно будет при инсталляции «заставить» пользователя принять EULA с пунктом типа: «все нажатия клавиш передаются на сервер Авторов и могут быть использованы ими по своему усмотрению».
                    • 0
                      Да ладно, яндекс бар сплошь и рядом ставиться даже без уведомления об его установке.
                      • 0
                        Не знаю, не встречал, а когда попытался поставить, то браузер сообщил что это расширение хочет иметь доступ к данным на всех сайтах, истории и закладкам. После чего было послано.
            • +1
              Ага, ну-ну. «Мы шли мимо, дверь открыта была, ну подёргали, открылаксь, зашли и начали выносить всё, ну а что добру пропадать, на предметах же не было табличек „Собственность Пети“ — значит ничьё»…

              Так это, по-вашему, выходит?
              • 0
                Это абсолютно разные вещи. То что у вас могут спереть чемодан в камере хранения не ваша проблема, а камеры хранения и ответсвтенность несут они. Примерно, так!
                Никто же с вашего компьютера ничего не индексировал и в паблик не выложил.
                • +2
                  В данном случае URL (как ключ к секретной странице) был ТОЛЬКО на пользовательском компьютере в адресной строке его браузера. Не на сайте («камере хранения») каком-нибудь, и даже не в реферере. Натурально стащил из-за незапертой двери.

                  Если этот ключевойURL был в открытом доступе — то пусть Яндекс в свою защиту приведёт URL страницы, на которой он увидел этот «открытодоступный» ключевойURL! Тогда все претензии к Яндексу снимаются, и виновными остаются авторы шопа в одиночку.
                  • +4
                    Ну никак он не мог быть только там. Прежде всего он был сгенерирован на сервере, потом был передан по открытым каналам открытым текстом, никаких мер для его сокрытия не предпринималось, что по сути означает, имхо, что данная информация не относится к информации с ограниченным доступом или конфиденциальной. А даже если относится, то согласно нормам права конфиденциальную информацию владельцев сайта (ссылка никак пользователю принадлежать не может, это владельцы сайта ему её сообщают) разгласил либо пользователь, выполнив у себя программу «Яндекс.Бар», либо сам владелец сайта, «заставив» пользователя выполнить программу «Яндекс.Метрика».
                    • 0
                      Мы не знаем, по какому каналу пришло письмо тем пользователям. Вполне возможно, что на MX оно пришло по SMTP со STARTTLS (на своём сервере вижу, что многие отправители его используют, т.к. видят анонс его поддержки в EHLO), и с большой вероятностью пользователь прочел его по httpS или imapS. Т.е. нигде от очереди исходящих на почтовом сервере шопа и до почтовой программы у пользователя открытым текстом оно не шло.

                      Да и какая разница — сниффинг паролей вряд ли законное дело. А тут как раз полная аналогия (не с открытого сайта стащен URL, а с промежуточных «технических средств»).
                • +1
                  кстати, неплохой пример!
                  камера хранения, конечно, тоже будет виновата, если чемодан сперли. Но это не снимает ответственности с того, кто спёр, правда?
                  • 0
                    Если камера хранения вместо того, чтобы хранить в защищённом от третьих лиц месте просто бросила чемодан посреди тротуара, то снимает.
              • +3
                401 или 403 ошибку не выдало? Не выдало, значит доступ санкционирован создателями сайта или они используют протокол HTTP ничего о нём не зная. Грубо говоря, сложили вещи на тротуаре и надолго ушли, понадеявшись, что их никто не унесёт. И то, эта аналогия в пользу веб-мастеров.
                • +3
                  То есть, если во внутреннем кармане пиджака, лежащего на тротуаре, не было зеленой бумажки формата Letter с разборчивой надписью чернилами на русском языке «брать запрещено», то человек, взявший мой пиджак с тротуара, в случае поимки избежит ответственности?

                  Более развернутая аналогия с изъятием материальных ценностей, с учетом общего тренда комментариев:

                  Так как в день получки, когда Петя нёс зарплату домой, у Пети при себе не было в нагрудном кармане бумажки с надписью:
                  жуликос.txt

                  на которой было бы написано:
                  жулики *
                  карманы не выворачивать /

                  то мы вывернули карманы и забрали всё, что упало, и, согласно общепринятым поговоркам — пропало (а раз пропало — то уже не принадлежало Пете).

                  А Петя сам виноват — он когда входил в переулок, читал соглашение, и принял его, соглашение висит на 4-м фонарном столбе перед переулком и пункт 5.1 его гласит:
                  Вошедший полностью и безоговорочно соглашается с тем, что лица, стоящие в переулке, имеют права вывернуть карманы, если нет записки с содержанием…
                  • 0
                    Не путайте ситуации, когда мы в наглую вывернули карманы пиджака на Пете (ст. 161 УК РФ, а если угрожали оружием или насилием — ст. 162 УК РФ) и когда мы вывернули карманы на пиджаке, брошенном Петей (ст. 226 ГК РФ).
                    • +2
                      Здесь именно вывернули карманы пиджака (браузера) на Пете (компьютере пользователя). Никуда этот секретный URL не падал — ни на какой открытый сайт его авторы шопа не выкладывали. Яндекс стащил его из браузера пользователя — кармана на живом Пете. Без угрозы насилием, конечно, а незаметно для него. Какая там статья для карманных воров?
                      • 0
                        Урл принадлежит владельцам сайтов. Либо они сами согласились передать его Яндексу, установив Яндекс.Метрику. Либо их клиенты передали их Яндексу, установив Яндекс.Бар.
                        • 0
                          А соглашались ли они где-нибудь явно на индексацию/публикацию этих URL'ов (частной информации, принадлежавшей владельцам сайтов, открытой ими только пользователям)? Тут противоречие и упоминаемому Вами ФЗ.
                          • 0
                            Вот-вот. Поисковики работают на правовом минном поле.
                  • 0
                    Ох. Вот представим себе: я родом из ЮАР, из какого-нибудь дикого племени. В моем племени убивать людей — не является чем-то плохим. Волею судеб, я попал в Россию. Читать вообще не умею (из дикого племени же). Соответственно, что такое УК РФ — понятия не имею, что это уголовно (щито O_o, для вождя-то?) наказуемо — так же.
                    Прибил я на улице табельным томагавком прохожего. Через 5 минут меня схватили полицейские, и пытаются посадить на 10 лет.
                    А теперь проведем аналогию с 4-м фонарным столбом — ведь то же самое, получается?
                    Не знание закона не освобождает от ответственности. Любые спорные моменты (применительно к данной ситуации) описаны в пользовательском соглашении. Почему же паника-то?
                    Хоть убейте, не понимаю.
        • 0
          Нет, здесь вопрос в том, что почему яндекс добавляет в индекс все страницы с метрикой, а гугл adwords — нет?
          • 0
            adwords и метрика разные вещи. Учите матчасть!
            • 0
              ок — analytics.
              • 0
                вообще вопрос чисто гипотетический, а как вы точно знаете что виновата метрика, что она собирает такие данные?
                • 0
                  Ну по-моему статья как раз об этом. Паук ходит по ссылкам. Если страница unreachable пауком, то вариантов попадания немного — webmaster tools (ну или что там у яндекса) плюс скрипты трэкинга, которые сообщают адрес недостижимой страницы.
                  • +2
                    так ссылки эти нужно исключить путем nofollow и robots.txt
                    Все просто! Разрабы в этом случае виноваты, но все наезжают на ПС
                    • +1
                      Да как раз это не так. Во-первых, robots.txt — это рекомендация. Она не является никаким стандартом или еще что. Более того, любой может прийти и скачать этот robots.txt, провести анализ и сделать выводы, мол вот тут будут лежать вкусности.

                      Потом, очень интересно, что в правилах Яндекс.Метрике:
                      Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам, за исключением тех, доступ которым к таким записям Пользователь предоставил самостоятельно.


                      Т.е. как бы странновато получается — вроде как в открытом доступе не выставлены, доступ сам не предоставлял, просто сессию записал с содержимым страницы — а тут нате — все в паблике. WTF?
                      • +1
                        Сессию он не записывал — он сам зашёл по урлу и сайт открыл (скорее попытался открыть) боту Яндекса новую сессию.
                        • 0
                          Так а урл-то он откуда взял?
                          • 0
                            Какая разница? Сессию он не размещал? Не размещал. Её запись предоставлял? Не предоставлял. Он в открытом доступе показывает адрес по которому пользователь может начать свою сессию.
                            • +1
                              Разница принципиальная. Все те секретные URL'ы, по которым прошелся Яндекс НЕ БЫЛИ в публичном доступе (или где тот сайт, откуда он их взял?).

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

                              В следующий раз он стащит не URL из браузера, а пароль, который вы ввели в том же браузере, но в другом поле — это тоже ему прощать?
                              • 0
                                Да почему стащил? Вы соглашения Бара и Метрики читали?
                                • +3
                                  Да. У меня на всех сайтах и метрика, и аналитикс. И нигде я не видел в соглашениях моего согласия на индексацию тех урлов, которые я передаю метрике. Я их Метрике передаю, чтобы он мне статистику считал, а не поисковому индексу на публикацию. Это ведь разные сервисы.

                                  P.S. От того, что понижением кармы вы не даете мне отвечать чаще 5 минут, моё мнение не изменится :) Приводите более убедительные аргументы.
                                  • 0
                                    Полностью согласен. Яндекс просто взял ПРИВАТНУЮ ссылку из адресной строки броузера (через бар или метрику).
                                    Некоторые пишут, что аутентификация должна быть не по GET, но сие есть полный бред. В будущем никто не помешает тому же скрипту метрики слить Ваш пароль, который вы вводите в форму авторизации. По сути бар.метрика — это трояны, которые кроме выполнения своих основных функций еще и сливают приватную информацию.

                                    В связи с этим еще весной начали переходить на Piwik для сбора статистики по своим проектам. Доверять это стороннему сервису может быть очень опасно!
                                  • +2
                                    Я с вами согласен. Поисковик использовал средства, которые не являются нормальными для сбора урлов. Это больше похоже на шпионаж.
                                  • 0
                                    Можете процитировать пункт соглашения, согласно которому вы их передаёте исключительно для подсчёта статистики?

                                    Минусую комменты я крайне редко, если только там открытые оскорбления, а карму, кажется, никогда.
                                    • 0
                                      Могу: «Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам»
                                      • 0
                                        Ссылка != Сессия
                                        • 0
                                          Ну как же — если покупатель посетил одну страницу с данными о заказе, то вся его сессия из этой ссылки и состоит. И см. ниже, там яндекс указывает, что адрес страницы (т.е. ссылка) тоже персональная информация.
                                          • 0
                                            Эта сессия состоит из запроса и ответа. Адрес лишь часть запроса и не может быть назван сессией целиком.
                                            • 0
                                              Ну тогда тем более :-) этот пункт запрещает размещение в открытом доступе не только адресов страниц, но и самих страниц :) Значит яндекс даже дважды виноват.
                                              • 0
                                                Яндекс страницы с сессиями не размещает, он размещает страницы, которые сам получил
                                                • 0
                                                  Прочтите указанное соглашение еще раз. Сессией там считаются адреса страниц, посещенных пользователями. Он эти адреса добавляет в индекс, хотя пишет, что не будет.
                                    • 0
                                      И еще, в тексте соглашения ссылка на политику конфиденциальности, в которой к персональным данным яндекс относит в частности: «1.1.2 Данные, которые автоматически передаются Сервисам Яндекса в процессе их использования с помощью установленного на устройстве пользователя программного обеспечения, в том числе IP-адрес, информация из cookie, информация о браузере пользователя (или иной программе, с помощью которой осуществляется доступ к Сервисам), время доступа, адрес запрашиваемой страницы
                                      • 0
                                        Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные (без привязки к персональным данным посетителей сайта) данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.

                                        Фактически это явное разрешение веб-мастером Яндексу использовать анонимные данные о посещения сайта, в том числе индексировать посещенные страницы.
                                        • 0
                                          Ничуть. Явно написано, что для статистики. Никакого индекса, никакой публикации не подразумевается. Под Яндексом здесь имеется в виду не поисковик, а сторона договора, т.е. мою статистику могут смотреть сотрудники яндекса и я. Всё. Никакой сдачи никуда не предусмотрено, что явно указано в политике конфиденциальности.
                                          • 0
                                            Как использовать статистику вы Яндекс не ограничиваете. Сотрудники Яндекса смотрят статистику и адреса из неё вбивают в «адд урл». Использование? Использование. Запрещено такое использование соглашением? Нет! Используются персональные данные? Нет! Используются данные статистики: «на сайте 100500 таких-то урлов, 500 таких-то из них посещаются часто, т. к. есть в индексе, а вот 100 000 — по одному разу, добавим-ка мы их в индекс, сделаем вебмастеру приятное, тем более они точно не секретные раз в роботс не запрещены». Соглашением это не запрещено, персональными данными не пахнет
                                            • 0
                                              В соглашении о конфиденциальности Яндекс отнес адрес страницы к персональным данным.
                                    • 0
                                      И наконец: «данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.»

                                      Посетители поиска не являются ни Пользователем (вебмастером, установившим Метрику), ни Яндексом.
                                      • 0
                                        Яндекс использует анонимную статистику о посещениях страниц для предоставления услуг посетителям своего поиска. По-моему, он вправе это делать, в соглашении варианты использования не ограничиваются.
                                        • 0
                                          А о разрешении индексации посещенных страниц по-прежнему ничего. Разрешение дается только на статистику.
                                          • 0
                                            Вы можете запретить поисковику индексировать какие-то страницы, указав их роботс, баня по юзер-агент или айпи и т. п. Разрешения вашего для посещения общедоступного урла им не нужно — всё что не запрещено, то разрешено. А статическую базу урлов вы сами разрешили им собирать.
                                            • 0
                                              Метрика — не поисковик. С поисковиком отдельные отношения с другим соглашением и другими урлами — sitemap и т.п.
                                    • 0
                                      О, пока мы тут спорим, Яндекс уже решил исправить Метрику (приравняв её к Яндекс.Бару, который по их уверению ссылки не палит) — webmaster.ya.ru/replies.xml?item_no=11122

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

                                      В общем, вопрос исчерпан, Яндекс исправился, магазины тоже исправляются, пользователи могут спать спокойнее :)
            • 0
              к тому же adwords имеет трэкинг целей, так что его тоже можно туда отнести, так как устанавливается он как раз там где достигается цель, что может быть страницой с результатом заказа и приватной инфой
          • 0
            Если уж сравнивать, то с Google Analitycs…
      • +6
        Адреса доступны публично? Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так? Или у вас приняты двойные стандарты?
        Защитить данные пользователей — ваша забота. Сделать хороший поиск — забота Яндекса.
        Вы (или админы сайтов) когда ставили метрику соглашались с лицензионным соглашением? Соглашались. Какие потом вопросы-то?
        • +2
          > Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так?

          Если ЛЮБОМУ, то так. Но шоп выслал секретный URL (как если бы выслал пароль) ОДНОМУ человеку, ни на какой сайт «для всех» этот URL не помещал, а без этого никто бы его «случайно» не подобрал. Т.е. фактически никакого отличия от пароля. И Яндекс, взяв этот URL из адресной строки пользовательского браузера (а не с открытого сайта) выдал его всем.

          Точно также он может стащить на пользовательском браузере (яндекс.баром) и параметры POST-запросов, и пароли. И стащит когда-нибудь, если его на первых кражах не остановить.
          • 0
            Что такое «секретный URL», в каком стандарте обозначено такое понятие?
            URL не может быть секретным, URL не является объектом авторского права, URL не является персональными данными. Равно как и любой другой (IP, адрес дома и др.) адрес.
            Исходить нужно их этих предпосылок.
            • 0
              Все, что прислано мне на email (и больше никуда) являются моими секретными персональными данными. Почтовый клиент тоже мог бы выдавать мои письма яндексу «для более полной индексации», однако он этого не делает. С какой стати мои URL'ы имеют какой-то пониженный приоритет в сравнении с другими словами из той же почты?

              Пусть яндекс индексирует то, что его паук найдет по ссылкам на других сайтах. А то, что выдаётся Метрике — выдается только для статистики, доступной только владельцу сайта (такую же статистику он мог бы и из своих секретных логов сервера собирать), а не для индексации и публичного показа.
              • +1
                Еще раз — URL не может быть секретным, просто по определению. И понятия «мои URL» в RFC тоже нет.

                Все методы авторизации по ссылке в письме основаны на предположении, что адрес это ссылки не знает никто, кроме получателя письма. Это предположение неверно, можно сказать — defected by design. Что в итоге и показали нам поисковики.

                Впрочем при уточнениях «ссылка действует в течении X времени» и «ссылка действует только один раз» система авторизации получается достаточно надежно, но кто знает…
              • 0
                Вы как-то однобоко смотрите на проблему. Давайте на секуду представим, что Яндекс бы вдруг признал свою вину и резко отказался от индексации страниц, поступивших через метрику/бар. А разработчики Shop-Script не писали бы патч, закрывающий страницу заказа хотя бы на фамилию.

                Мы бы тогда имели:
                1) Отсутвие в выдаче Яндекса страниц с заказами в будущем
                2) Знание, что есть некий урл, при переходе на который я получаю некие персональные данные.

                Что остановит плохих дядек имея знание о втором пунке от написания своих ботов/пауков, которым глубоко класть как на robots.txt, так и на этику как таковую.

                Вам бы понравилась такая ситуация?
                • +1
                  1) и нечего им делать в яндексе
                  2) Каким образом (кроме перебора) плохие дяденьки получат этот самый «секретный» урл? Вот у яндекса таких способа целых два — бар и метрика.
                  По сути форма авторизации — это тот же самый секретный урл, и передана она по POST или GET для желающих получить Вашу информацию не так уж важно.
                  • 0
                    2) Прокси/снифер/открытый Wifi, можно еще пяток способов придумать, передавать личные данные пользователя в открытом виде, плохой тон, а передавать их в get запросе это вообще верх маразма.
                    • +1
                      «Прокси/снифер/открытый Wif» таким же способом может и пароль скушать, особой разницы post или get здесь нет.
                      Никто не говорит, что разработчик молодец. Но яндекс эту ссылку УКРАЛ и выложил в паблик.
                      • 0
                        Каким же интересно образом яндекс УКРАЛ ссылки?:) Веб мастера сами их отдали яндексу, или вы утверждаете, что по подобным ссылкам никто и никогда не вешает другие счетчики? Эти ссылки принесли яндексу на блюдечке с голубой каемочкой, а потом кричат что яндекс их украл :) Классно.

                        Я вообще не могу себе представить как кому то в голову пришло держать личные данные пользователей в открытом доступе, без банальных методов аундификации, хотя бы как здесь по фамилии, имени, полу, году рождения етк… это вообще не должно укладываться в голове у любого нормального итишника.
                        • 0
                          Если в соглашении явно написано о том, что все ссылки индексируется, вопросов нет. Но я такого пункта там не нашел.
                          • 0
                            А там явно написано, что она не будет индексироваться? Передача любого адреса (в том числе урла) предполагает, что по этому адресу тот, кому его передали, может спокойно обратиться: ответят-не ответят, пустят-не пустят, пошлют-не пошлют, выдадут 200 и инфу или 401/403 и предложение аутентифицироваться — дело владельца даже не адреса (адрес это чистой воды информация), а ресурса, на который этот адрес указывает.
                            • 0
                              А вот это уже довольно скользкий момент. Через прокси сервера тоже проходят кучи урлов…
                              • 0
                                В том числе и поэтому не рекомендуется передавать секретные данные в GET запросах.
                              • 0
                                Простите, а какой закон или моральный принцип нарушат держатели прокси если пройдут по любому из урлов прошедших через их прокси, без учета личностей предыдущих? Если ссылка открыта, то значит скрывать там нечего.
                                • 0
                                  И если POST форма засабмичена не по https протоколу, то тоже скрывать нечего? )
                                  • 0
                                    Хех, если веб мастер отдает эти пост запросы на анализ в гугл/яндекс, то видимо нечего.

                  • 0
                    RFC не рекомендует передавать «чувствительные» данные через GET-формы.
                  • +1
                    Я в прошлом топике описывал метод компроментаци таких урлов через referer.
                    Например, вам на почту пришла секретная ссылка, по которой вы можете посмотреть список заказов. Вы заходите в список заказов и оттуда переходите на страницу какой-нибудь заказанной вами вещи. Вполне реальная ситуация, правильно?

                    Теперь все скрипты на этой странице (товара) знают вашу секретную ссылку через document.referer. Думаю не надо объяснять что кроме метрики часто владельцы магазинов вставляют еще разные скрипты от рекламодателей и т. д.

                    Кто будет гарантировать что рекламодатель не плохой дядька который купил рекламу только ради того чтобы тырить секретные урлы пользователей сервиса?
                    • 0
                      Далеко не все магазины вешают на такие страницы баннеры и прочие внешние скрипты. И если таковых нет, то сам механизм «секретной» ссылки безопасен (приведите пример компроментации, если не согласны с этим аргументом). Но скрипт на странице был и им оказалась Яндекс метрика.

                      Если клиент ходит в сеть через прокси, то прокси имеет доступ к подобным ссылкам. Но так же прокси может сохранять и POST запросы. Поэтому единственным надежным решением будет https
                      • 0
                        Далеко не все магазины вешают на такие страницы баннеры и прочие внешние скрипты

                        С этим не согласен — на страницы товара и другие страницы сайта всякие баннеры вешают довольно часто.

                        А я и не говорил что на страницу просмотра заказа (с секретным url) кто-то что-то вешает. Я говорю если человек со страницы просмотра заказа переходит по прямой ссылке на страницу товара, да даже просто на главную страницу магазина — «секретная» ссылка будет видна в document.referer всем банерам и остальному контенту, размещенному на главной странице магазина или странице товара
                        • 0
                          Согласен.
                • +1
                  Такой софт и пишут. Трояны называется. Жалко в данной истории яндекс сам выступает трояном :(
                • 0
                  А быстрое удаление из индекса данных об смс — это признание чужой вины?
                  • +1
                    Быстрое удаление данных из индекса — это результат неких переговоров Яндекса и Мегафона.
                  • 0
                    Обыкновенная этика. Вы что нашли случайно, к вам пришёл хозяин и попросил отдать. Не отдадите?
                • 0
                  Пауки не найдут эти секретные урлы без помощи Метрики, т.к. этих секретных урлов нет нигде кроме почтовых сообщений.

                  Разработчики шопа тоже виноваты, конечно, но это не отменяет вины Яндекса, спалившего урлы, которые были предназначены для статистики, а не для индексации и публикации.
      • 0
        Да и вообще, я думаю, что будь такое в Америке, там бы уже гугл местный бы последние портки бы продавал чтобы выплаты по искам раздать
        • +2
          Там владельцы сайтов бы последнее продавали…
          • +3
            По крайней мере, «гугл местный» постарался бы избавиться от персональных данных в своей базе. Какой скандал поднялся, когда обнаружилось, что Гугл собирает данные по открытым (!) точкам вай-фая с помощью своих гугломобилей. И гугл пообещал так больше не делать и удалить собранные персональные данные.
            А Яндекс может себе позволить посмеиваться — «обнаружили, что можно искать» — над глупыми людишками, у которых персональные данные оказались в публичном доступе.
            Две ситуации: персональные данные в общем доступе. Два подхода: этичный и неэтичный.
            • 0
              Афаик, они быстро удалили из выдачи мегафоновские СМС
    • +2
      единственный нормальный вопрос за весь топик. сразу видно что вы детально проработали ситуацию.
      специально для глубоко вдумчивых профессионалов отвечаю на ваш вопрос:
      сужающие смазки -это такие которые повышают трению и способствуют сужению пилотного входа так сказать путем стимулирования оттока крови от наружнго шлюза…

      и не спрашивайте откуда я это знаю.
      • 0
        Учтемс…
  • +5
    А почему вы куки какие-нибудь особые не можете класть клиенту, когда он оформляет заказ, а потом, когда приходит по get-запросу на сайт, проверять их? Конечно, он может зайти из другого браузера/компьютера, и вот тогда вы можете просить вбить пароль/фамилию/и тп. То есть в типичном случае пользователю не придется ничего вводить.

    Еще идея: по ссылке отправлять пользователя на промежуточную страницу, с простеньким яваскриптом, который будет к исходному урлу дописывать какой-нибудь маркер (и оставлять хэш), а потом перенаправлять на страницу заказа. И уже на странице заказа вы будете проверять этот маркер. Тогда, когда бот будет индексировать исходный линк, яваскрипт не сработает, страница заказа маркер не прочитает и бота не пустит). Это решение вообще без ограничений, кажется.
    • –1
      Сначала пользователеь переходит mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, его авторизует скрипт и пересылает на mysexshop.com/order/4222
      • 0
        да, это похожая схема, но не такая же. И, судя по этому описанию, с недостатками.

        Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.

        Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.

        То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
        • 0
          > нечто, что позволит отличить человека от поисковой машины (отработка js, например).

          Или капча… у которой к всеобщему горю может снова вырасти популярность. Теперь для борьбы с поисковиками.
    • +1
      Пропустил ваш комментрарий. Сразу пришла та же мысль на счёт кук. C javascirpt — хорошая идея.

      Разработчики Shop-script, примите во внимание.
    • 0
      Проще (и надёжнее) отправлять на страницу с формой из одной кнопки «Нажмите эту кнопку, если вы не поисковый робот», отправляющей POST-запрос. Их поисковики не отрабатывают, насколько мне известно.
      • +1
        Им ничто не запрещает их начать обрабатывать. А вот Meta robots и robots.txt — вполне проверенные решения.
        • +2
          В принципе им также ничто не мешает игнорировать мета и роботс…
          • 0
            Для чего? У Яндекса нет цели выведать какой фаллоимитатор вы купили накануне, его цель — предсотавить максимально широкий и релевантный поиск. Если страница не должна находиться в поиске, то нет резона ее туда включать.
            • 0
              Мне казалось цель Яндекса (как и любого ООО) — зарабатывать деньги :)
              • 0
                Да. Только если яндекс начнет обрабатывать все подряд, не учитывая robots.txt и прочие способы указать, что индексировать, а что нет, то его сервисами — метрикой, яндекс баром, и прочим перестанут пользоваться, и яндекс начнет эти деньги терять. И авторитет он тоже начнет терять. А он еще на IPO вышел, акции же могут падать.
                • 0
                  Вот потому он не будет обрабатывать и пост-запросы своим баром, хотя возможность, вроде бы, есть, даже по https.
                  • 0
                    Так как он встроен в браузер, конечно есть возможность.
                    И кстати говоря, способов запретить считывать определенные страницы куча. Например выдавать обфусцированный код, который будет собираться JavaScript'ом, использовать капчу, делать проверки, бот это или нет. После перехода по ссылке ставить куку(бот куки не принимает и не отправляет, как я полагаю), и редиректить на страницу заказа, которая будет доступна только при наличии именно этой куки с определенным значением. Можно придумать кучу способов. Но все же самый простой — robots.txt.
                    А еще яндекс метрика вдруг может начать брать все содержимое страницы и отправлять постом в яндекс, мало ли? Это же JS, подгружаемый на Вашу страницу.

                    Просто нужно четко разделять зоны безопасности на сайте, и использовать разный подход. В общем, заботиться о своих пользователях.
                    • 0
                      Что нужно заботиться — полностью согласен. В последних событиях (неделя Яндекса не то, что на Хабре или даже в Рунете, а в масштабах страны — про фэйл Мегафона в газетах уже читал) владельцы сайтов явно не позаботились… Паранойя про чтение браузером или его сторонними расширениями данных post-запросов https сессий и передачей их куда-то на сторону — это одно, выкладывать конфиденциальные данные по публично доступной (даже ботам!) ссылке — совсем другое.
                      • +1
                        Эти данные не были публично доступны ботам, пока метрика не стащила секретный URL в пользовательском браузере.

                        Она (метрика) конечно не могла не узнать этот URL из реферера (и админ шопа ей это явно разрешил), но вовсе не должна была этот URL включать в общий индекс. Пауки пауками, а метрика метрикой. Паук не нашел бы этот URL, т.к. его нет нигде кроме письма у пользователя.

                        Если я начну перечислять в своих robots.txt все секретные каталоги своего сервера (на всякий случай уж), то яндес-роботов это может и отвадит, зато других роботов наоборот привадит именно туда!

                        P.S. Есть еще один способ «сдачи» поисковикам секретных URL'ов, даже если там нет никакой метрики — рефереры. Если на секретной страничке была ссылка на другой сайт, то пользователь може туда сходить с выдачей этому сайту своего секретного урла. А если например статистика рефереров того сайта открыта, то роботы доберутся до секретной страницы и без метрики. Т.е. там должна быть зашита, даже если метрики нет (поэтому, кстати, трюк с редиректом не очень-то надежно поможет). Поэтому безусловная виновность яндекса не означает, что авторы шоп-скрипта не виновны. Они тоже виновны, но яндекс больше :)
                        • 0
                          Да в чём Яндекс виноват? В том, что «как-то» попавший к нему урл он попытался проиндексировать на общих (даже хуже — представившись конкретно собой) и сайт ему не отказал? Или в том, что урлы к нему «как-то» попали?
                • 0
                  Вы это Руперту Мёрдоку расскажите, а то он не в курсе.
        • 0
          Мешает. POST-форма может совершать критичные действия — удалять что-либо и так далее. И вообще, как вы себе это представляете: пришёл бот Яндекса и накрутил голосование? Оставил комментов? Зарегистрировал аккаунт? Подписался на рассылку?
          • +1
            Ну вообще говоря, яндекс-бар может(?) передать ботам яндекса, а те использовать, логин и пароль с целью проиндексировать содержание личной переписки для более полного и релевантного поиска :)
          • 0
            Будите смеятся, yandex проидексировал у меня post форму, примитивную конечно (по сколько на странице показвать результатов), но проиндексировал. Теперь в результатах полный бред, так как он проиндексировал все параметры, вы представялете? В индексе теперь фактически одинаковые страницы с разным кол-вом результатов на странице.
            Это конечно не есть хорошо. Скоро и на рассылку подпишется :)
            (кстати google такой фигней не страдает, пока)
            • 0
              Впервые слышу о том, чтобы некий поисковый бот сабмитил формы. Возможно, кривая индексация вашего сайта — следствие тех же факторов, что привели к многочисленным утечкам, т.е. Бара либо Метрики.
              • 0
                Может быть :)
  • –2
    Я бы все же смотрел в сторону яндекс-бара… слишком мало проиндексировалось страниц для метрики, и неравномерно
  • +1
    А вот и следующая «ласточка»: проиндексированы электронные билеты на поезда news.yandex.ru/yandsearch?cl4url=www.ria.ru%2Fsociety%2F20110725%2F407118103.html
  • +10
    Такая практика как минимум неэтична.

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

    Вдруг что-нибудь в боте сломается. Или бот будет не поисковым…

    Это причина, по которой вы решили не настраивать robots.txt и отдать приватные данные поисковикам без боя? ;) Хоть бы meta noindex поставили. Если robots — это элемент отчасти админозависимый, то выковыривать бы метатеги из кода вряд ли ко стал или по дороге потерял. Да и от физического расположения не зависит.
    • 0
      Очевидно, по-моему. Мы с вами сказали, ещё пара тысяч так же подумала.
    • 0
      Вы считаете, что индексировать ссылку, по которой вы пришли из письма, отправленного Вам лично по защищенному протоколу, не должно быть запрещено? — В таком случае не менее этично будет индексировать и пароли, полученные в письме (например, если Вы введете этот пароль на странице, на которой стоит некий скрипт, собирающий статистику).
      • 0
        Считаю это должно определяться администраторами сайтов. Запретили в роботс.ткст — запрещено, не запретили — разрешено.
        • 0
          Милиция не рекомендует ходить поздно вечером в одиночку по темным кварталам.
      • 0
        Считаю это должно определяться администраторами сайтов. Запретили в роботс.ткст — запрещено, не запретили — разрешено.
        • 0
          Нет, так защищать информацию нельзя. Подобная информация 100% должна быть недоступна никому без согласия владельца.

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

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

                А далее — либо эта ссылка является персональными данными и он сам без согласия пользователя отдаёт её третьим лицам, не заключая с ними соглашения о конфиденциальности, либо не является и тогда получается, что разработчик выложил персональные данные в паблик опять-таки без согласия пользователя. А если с согласия (где-то мелким шрифтом в оферте магазина это написано) то вообще сканадл на ровном месте.
      • +1
        Ни поисковый бот, ни метрика понятия не имеют ни о каком письме и не знают, что ссылка была получена в оном, равно как не имеют никакого доступа ни к паролями ни к какой-либо другой информации в этом почтовом сообщении. Они только знают, что пользователь X зашел на страницу Y, которая не запрещена к индексированию и, в рамках пользовательского соглашения, которое установивший метрику должен соблюдать, не содержит коммерческой тайны.
  • +4
    После слива МегаФона прошла целая неделя. Неужели этого срока недостаточно для того, чтобы подумать «Хм, а у моего могут вскрыться подобные дыры?», ответить себе утвердительно, сделать патч и разослать его клиентам?
    • +6
      У моего софта, дурак, у софта. Перечитывай комментарии перед тем, как отправлять.
  • 0
    Господа разработчики, у вас же наверняка есть кое-какая статистика. Так вот вопрос: какой % людей переходит по ссылке с уникальным хэшем из другого браузера, а не в котором сделал заказ? Мне какжется этот % будет не большой. Так почему не привязыть хэш к кукам? А если таки пользователь вошёл через другой браузер, то да — предлагать ввести фамилию для подтверждения.

    Спрашивается, почему это не было сделано изначально? И зачем сейчас предлагать всем клиентам вводить фамилию?
    • +3
      Кстати, лично я считаю, что указание обязательным для заполнения поля Имя, Фамилия снижает конверсию интенет-магазина. Может на несколько процентов, но снижает. Есть люди, которые не хотят светить свою фамилию, и правильнее делать один инпут «Представьтесь, пожалуйста» — а там человек сам решает, указать только имя или имя и фамилию.
      • 0
        При доставке по почте иначе никак.
        • 0
          А на безымянный «а/я номер такой-то» посылку не доставят? Как же, блин, теперь покупать запретные плоды? :)
          • 0
            При получении паспорт (или доверенность с паспортом) точно придётся предъявлять.
    • 0
      Нельзя к кукам :(. Люди пользуются компьютерами с работы, у друзей или просто несколькими компами и т.п.
  • +1
    Даже если проблема в метрике — почему страницы не были закрыты от поисковиков? Мета-теги религия не позволяет использовать? Да и robots.txt не просто так придуман же. Так что проблема именно в разработчиках, а не в поисковиках.
  • +16
    Огласите пожалуйста имя гения, который после такого факапа с индексацией приватных данных предложил
    Оперативное решение мы сделали следующее: прикрутили авторизацию пользователя по фамилии. Если пользователь перешел по ссылке из письма-уведомления о заказе, то сначала мы у него спрашиваем фамилию, и только если он ее ввел правильно, показываем информацию о заказе.


    • +2
      Это частный случай.
      Хотя да, я с Вами согласен, временное решение глупо выглядит.
      • +3
        :)

        Если у вас уже есть вся информация о заказе, полученная из кеша, то нет никакого смысла вводить фамилию — ведь вы увидите то же самое.
        • +2
          Спалённых уже не спасти, они о новых думают. На странице изначально не будет никаких данных, а только вопрос «ваша фамилия, гражданин», яндекс её не знает и дальше воровать не пойдет, соответственно ничего кроме вопроса в индекс не попадёт. Но туда будут ломиться спец-роботы, которые натаскали урлов про «твоё фамилиё» из яндекса, и далее атакой по словарю фамилий будет доиндексировать яндексовые недоработки. А может и яндекс наловчится подбирать — в борьбе за полную индексацию. Список фамилий — открытая информация, чо!
          • 0
            Главное фамилию GET-запросом не передавать=)
    • –2
      Феерично! Это не оперативное, а скорее оголтелое решение.
    • 0
      ну это заготовка на будущее как я понимаю, чтобы при следующем «факапе» контент не проиндексировался, думаю на странице с заказом и так есть вся остальная конф. информация, так что иного решения видимо и не существует
    • +4
      Я так понимаю, что смысл был в защите новых записей, старые все равно уже скомпроментированны. Соответственно они не проиндексированы и фамилии не известны.
  • +2
    robots.txt
    robots.txt
    robots.txt
    robots.txt
    • –1
      Кроме поисковиков есть еще и счетчики, которым robots.txt не указ…
      • +5
        Счётчики сливают информацию о существовании урла поисковикам. А robots.txt не даёт эти адреса индексировать.
        Кстати, к robots.txt — это не только полезно, но и весело.
        • 0
          Имеются ввиду счетчики рейтингов, которые могут в открытом доступе дать информацию о посещаемых на сайте страницах.
          • 0
            Я думаю, сравнивать счётчик, где, целенаправленно копая, могут найти ваши секретные урлы (как, интересно? я даже не знаю, как это сделать с открытой метрокой сайта, может lj позволяет?), и появление закрытой информации о клиентах в поисковике с дневной аудиторией 12 миллионов посетителей совсем некорректно.

            Всё-таки одно дело не соблюсти баланс между удобностью доступа к информации пользователем и сложностью её получения злоумышленником, и совсем другое — в следствие банального раздолбайства оставить эту информацию в открытом доступе.
            • 0
              Де-факто это информация не закрыта. То, что адрес не обнародован не значит, что информация не обнародована тоже.
              • 0
                В абстрактном случа или данном случае? Адрес с хешем, без хеша информации о заказе не получить — если адрес закрыт, закрыта и информация. Мой Круг года четыре авторизирует пользователей по ссылкам в своих письмах. Вы когда-нибудь слышали об утечке приватных данных типа личной переписки из Моего Круга? А о массовом взломе аккаунтов? Я — нет.
                • +2
                  В любом. URI, согласно RFC 2616, по умолчанию считается доступным третьим лицам. Точка.
                • +1
                  У моего круга, как я сегодня выяснил, ссылки одноразовые.
                  • +1
                    А у меня linkscanner avg :)))
                    Многие антивирусы имеют такие модули, которые проверяют ссылки перед «загрузкой» пользователя. Представили? ;) Т.е. перед тем как зайдет пользователь, зайдет антивирус и сбросит счетчик. И пользователь уже не попадет на нужную страницу.
                    Это я к тому, что это опять ошибка программеров, нельзя так делать. куки, куки и еще раз куки. Нет куки — регистрация и авторизация.
                    Программер круга, наступает на грабли.
              • +1
                Все таки страничку с никому неизвестным адресом нельзя считать обнародованной. И мой визит на секретную страничку тоже не «народует» её. Эдак можно до чего угодно договориться. Пароль на мой MySQL тоже не обнародован. Предупреждаю: если яндекс стащит откуда-нибудь мой пароль, то не читайте мои таблички :) Или, если хакер стащил мой пароль, а я не забанил чужие IP в конфиге MySQL, то тоже я виноват, а хакер белый и пушистый сидит в открытом интернете и ищет незапертые двери?
  • +3
    >PHP-редирект
    Это вы так переадресацию путём Location заголовка и указания соответствующего статуса HTTP ответа обзываете?
    • +1
      нет, видимо, страницу с ссылкой и кнопкой «продолжить», которая берёт get, кладёт его в put и сабмитит.
      • 0
        куда кладёт? :) в post может?
        • 0
          Пардон, в post.
  • +3
    Да, а ещё поисковики обычно поддерживают meta в заголовке для управления индексированием.
    • 0
      Верно. Только пока что Яндекс не особо акцентирует внимание на этом у пользователей метрики (если виновата все же метрика). Это раз. Два: какие будут предложения насчет 100 млрд (или сколько их там) уже существующих страниц? Перепроверять их на соответствие новым интересам яндекса? Ок, не ставить метрику на свои сайты. А если они завтра они начнут собирать урлы баром?
      • +1
        Они уже собирают. И не известно, чем больше собрали
      • +2
        Вообще-то акцентирует. Я всё это знал ещё когда был махровым нубом, сидел на модеме 14400 по баксу в час и юзал какие-то халявные хостинги для мелких страничек.

        С тех пор информации стало больше. Прочитать проблема?

        Кстати, вы не сильно обижаетесь на водителей, которые сбивают пешеходов на КАДе? А то создатели автобана не сильно акцентируют внимание пользователей на том, что из машины не надо выходить пока она на этом самом КАДе.
        • 0
          1. метрика появилась чуть позже, чем 14400 модемы вышли из обращения, а именно в 2009 году. так что во этой всей риторике уже есть некоторые неточности.

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

          3. прочитать не проблема. присылайте по крайней мере одну ссылку, где яндекс прямым текстом указывает, что зафиксированные урлы могут быть использованы для индексации, прочту. Предупрежу: ПС явных указаний не содержит.

          4. про автобаны это все отвлеченная риторика. ответ по существу см. в первых трех пунктах.

          5. чего так дерзко? ;)
          • +2
            При чём тут метрика? Я про robots.txt и запрет индексирования тех страниц, которые не подлежат публичному просмотру, включая /cgi-bin директорию сервера.

            Люди, которые делают сайты без настройки robots.txt, содержащие хоть какие-то приватные данные, просто профнепригодны.
            • 0
              а люди который открывают персональные данные на сайте и защищают их robots.txt???
              смех :)