Комментарии 520
Хм, думаю разработчикам yandex метрик следует добавить параметр dontIndex в их js api
Я думаю разработчикам магазинов нужно правильно делать архитектуру проекта.
Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?
Да просто разработчики наплевали на стандарты и спецификации, касающиеся разделения прав пользователей. Ответ мне напоминает стиль: «сам дурак».
Ребята, не надо отмазываться — это ошибка ваша и больше не чья. С такой архитектурой проекта только… сказал бы, но здесь и детей много.
Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?
Да просто разработчики наплевали на стандарты и спецификации, касающиеся разделения прав пользователей. Ответ мне напоминает стиль: «сам дурак».
Ребята, не надо отмазываться — это ошибка ваша и больше не чья. С такой архитектурой проекта только… сказал бы, но здесь и детей много.
Да какая архитектура в данных конкретных «фэйлах Яндекса» — robots.txt было бы достаточно.
Скрытый разработчик Webasyst, или бывший разработчик )))
Ну вот, прокуратура теперь будет разбираться
Опять прикрываемся robot.txt, это привязка к конкретному случаю. Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую. Я уверен что разработчики и сами понимают в душе, что виноваты они. Просто теперь пытаются сохранить хорошую мину при плохой игре.
Я к тому, что в данных случаях («неделя Яндекса») не нужно было привлекать гуру архитектуры или суперспецов по криптографии — пары строчек в одном файле хватило бы. Другие уязвимости остались бы, но не эта. А все уязвимости закрыть вроде невозможно — вроде как все современные методы аутентификации базируются на теории вероятности и комбинаторике, что не исключает «благоприятного» исхода при первом же испытании.
Доверять «авторизацию» по одной строке get — дилетантская ошибка, согласитесь. А взломать можно любую систему, любым алгоритмом, на крайний случай социальным (методы бывают разные — начиная от троянов секретарше, заканчивая силовыми) :)))
Не хватало только, чтобы авторизацию доверяли. Аутентификацию вот доверили и уже скандал, а прикиньте, если авторизацию? если Яндекс начнёт контент на сайте менять или сообщения пользователям рассылать? O_o
Называем вещи своими именами (назовите хоть х, как на заборе (хотя это ж не х, а забор)) — это и есть фактически частная авторизация, которую решили разработчики сделать через один get запрос.
Фактически это идентификация, а что разработчики решили на её основе проводить авторизацию…
Ну опять вы начинаете демагогию.
Пользователь получил «права», право на то, что он может проследить заказ, и только он и админы. Так как он получил какие-то права, значит он должен быть авторизирован, путь хоть временно, но авторизирован, а авторизация под собой подрузомевает, что? ;) Но уж не как по одному запросу get. Я написал про забор, как его не называй и что на нем не пиши — он забор.
Пользователь получил «права», право на то, что он может проследить заказ, и только он и админы. Так как он получил какие-то права, значит он должен быть авторизирован, путь хоть временно, но авторизирован, а авторизация под собой подрузомевает, что? ;) Но уж не как по одному запросу get. Я написал про забор, как его не называй и что на нем не пиши — он забор.
>Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую
да, давайте все будем умными и красивыми, будем писать правильный код с первого раза и не допускать дыр.
да, давайте все будем умными и красивыми, будем писать правильный код с первого раза и не допускать дыр.
Знаете, сарказм, признак примитивного юмора. Представьте, вас послушают и будут писать код, который никто кроме «него» не прочтет, от этого «ему» легче будет? Сомневаюсь.
Есть основопологающие принципы, которых надо придерживаться изначально, тогда легче жить будет, особенно другим, как мы видим.
Всегда, и везде будут дыры, но млин, не такие примитивные и детские. Если бы не забывали изначально про принципы построения, то такой фигни бы не было.
Я как разработчик считаю, что дыра была детская. Называя вещи своими именами вы предоставили авторизацию (да, да если пользователю предоставили какие-то права — это уже авторизация, пусть и временная), через один get запрос.
Есть основопологающие принципы, которых надо придерживаться изначально, тогда легче жить будет, особенно другим, как мы видим.
Всегда, и везде будут дыры, но млин, не такие примитивные и детские. Если бы не забывали изначально про принципы построения, то такой фигни бы не было.
Я как разработчик считаю, что дыра была детская. Называя вещи своими именами вы предоставили авторизацию (да, да если пользователю предоставили какие-то права — это уже авторизация, пусть и временная), через один get запрос.
>Представьте, вас послушают и будут писать код, который никто кроме «него» не прочтет, от этого «ему» легче будет?
извините, я сейчас пьян, можете объяснить проще, что за зайню вы несете?
>Если бы не забывали изначально про принципы построения, то такой фигни бы не было.
да-да, а если при написании кода на сишечке не забывать про то, что на каждый malloc() должен быть свой free(), то больше половины дыр в софте вообще бы не было.
еще раз извините за переход на личности, но мне кажется, что вы не понимаете, что такое разработка ПО, откуда в нем берутся дыры и почему они вообще бывают.
аутентификация гет-запосом — вынужденная мера, один из сайд-эффектов которой не был учтен. это выглядит глупо (как и большинство дыр) исключительно потому, что уже найдено.
извините, я сейчас пьян, можете объяснить проще, что за зайню вы несете?
>Если бы не забывали изначально про принципы построения, то такой фигни бы не было.
да-да, а если при написании кода на сишечке не забывать про то, что на каждый malloc() должен быть свой free(), то больше половины дыр в софте вообще бы не было.
еще раз извините за переход на личности, но мне кажется, что вы не понимаете, что такое разработка ПО, откуда в нем берутся дыры и почему они вообще бывают.
аутентификация гет-запосом — вынужденная мера, один из сайд-эффектов которой не был учтен. это выглядит глупо (как и большинство дыр) исключительно потому, что уже найдено.
> но мне кажется, что вы не понимаете, что такое разработка ПО
Ну да 20 лет стажа и университет по профилю, мало.
Не обижайтесь: по вашей пьяни — это вы сейчас не понимаете что несете ;)
Ну да 20 лет стажа и университет по профилю, мало.
Не обижайтесь: по вашей пьяни — это вы сейчас не понимаете что несете ;)
> Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?
потому что ссылка из письма. ссылки из письма могут открываться на другом компьютере.
вообще, я видел нескольких разработчиков 45+ лет. у всех 20 лет стажа, всё знают, цикл написать не могут и inner join от left join не отличают. но на словах-то все линусы торвальдсы, эрики липперты и гвидо ван россумы.
потому что ссылка из письма. ссылки из письма могут открываться на другом компьютере.
вообще, я видел нескольких разработчиков 45+ лет. у всех 20 лет стажа, всё знают, цикл написать не могут и inner join от left join не отличают. но на словах-то все линусы торвальдсы, эрики липперты и гвидо ван россумы.
>вообще, я видел нескольких разработчиков 45+ лет.
Идиотов везде хватает и в 20 лет. Вы плохо думаете о разработчиках. Как раз архитектурное мышление приходит позднее.
>потому что ссылка из письма. ссылки из письма могут открываться на другом компьютере.
Причем здесь это ;)? Понятное дело могут, но в 90% открываются в том же браузере, а остальным 10% — пусть введут временный пароль (пока действует отслеживание заказа), который есть (разработчик должен об этом позаботиться) в письме.
Идиотов везде хватает и в 20 лет. Вы плохо думаете о разработчиках. Как раз архитектурное мышление приходит позднее.
>потому что ссылка из письма. ссылки из письма могут открываться на другом компьютере.
Причем здесь это ;)? Понятное дело могут, но в 90% открываются в том же браузере, а остальным 10% — пусть введут временный пароль (пока действует отслеживание заказа), который есть (разработчик должен об этом позаботиться) в письме.
Вы статью-то читали? ссылка принимается там, где авторизация недопустима.
Можно ссылки на стандарты и спецификации, на которые наплевать разработчикам?
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
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
Здесь же речь о формах. Подразумевается, что не стоит делать метод формы GET, если в ней передается номер кредитной карты :)
Это единственная придирка к букве текста, которую можно найти, да.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
В приведенном отрывке речь идет исключительно о формах. Примеры не смотрел.
Написано же
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 на серверной стороне не прочитав описание, то ССЗБ, жаль, что страдают от этого пользователи.
Вырвано из контекста ;)
Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
RFC 2616 не рекомендует (SHOULD NOT USE) передавать «чувствительные» данные в URI.
Также известный как robots.txt.
Достаточно сделать вывод информации о заказе, после ввода email клиента, например.
Согласен, но в данном случае мы решили сделать дополнительную идентификацию по фамилии клиента.
«Пароль» можно и в письме прислать. Тогда его совсем никто знать не будет.
Не поможет… не будем забывать на чьих серверах обрабатывается почта.
Кто сказал, что нельзя ссылки брать и из писем, раз уж они все равно парсятся для подбора релевантной рекламы.
Кто сказал, что нельзя ссылки брать и из писем, раз уж они все равно парсятся для подбора релевантной рекламы.
Кто говорил что какие-либо ссылки берутся из писем??
Имеется ввиду следующее:
Ваш заказ номер 745867 успешно добавлен.
Используйте свой емаил idtyc@tufv.ru для входа и управления заказами.
Пароль для входа: 76fgtfiu7i7f6tgy (Вы можете его сменить через профиль)
примерно так…
Имеется ввиду следующее:
Ваш заказ номер 745867 успешно добавлен.
Используйте свой емаил idtyc@tufv.ru для входа и управления заказами.
Пароль для входа: 76fgtfiu7i7f6tgy (Вы можете его сменить через профиль)
примерно так…
Все гораздо-гораздо проще. Генирить номара заказов не по порядку и для просмотра статуса заказов использовать этот номер.
Плюс к этому слать все обновления по емэйлу.
Плюс не показывать завершенные заказы.
Плюс анонимусам показывать минимум приватной инфы (как это кстати часто делается с трекингом). Детальная информация все равно должна приходить первым письмом. А тут оставить только адрес с детализацие до населенного пункта, сумму заказа, и статус.
Плюс к этому слать все обновления по емэйлу.
Плюс не показывать завершенные заказы.
Плюс анонимусам показывать минимум приватной инфы (как это кстати часто делается с трекингом). Детальная информация все равно должна приходить первым письмом. А тут оставить только адрес с детализацие до населенного пункта, сумму заказа, и статус.
Генирить номара заказов не по порядку и для просмотра статуса заказов использовать этот номер.
Как показывают последние скандалы — это не панацея.
Плюс не показывать завершенные заказы.
Не юзабельно — проверяю я статус заказа: «идёт», «идёт», «идёт», 404 нет такого заказа — и что мне думать?
> Как показывают последние скандалы — это не панацея.
Насколько я понимаю, последние скандалы показвают, что не разумно передавать идентификаторы пользователя в GET-параметрах. В моем случае, пользователь по ссыке из письма попадает на старницу с полем «Введите номер заказа» и post-формой.
> Не юзабельно.
В сочетании с email-нотификациями — вполне. Более того, при грамотных email-нотификациях (почти) никто вобще не пойдет в магазин проверять статус заказа.
В идеале — прятать заказ после подтверждения о доставке покупателю (после этого зачем покупателю возвращаться и проверять статус?). При нашем несовершенном шиппинге — через какой-то разумный таймаут. Можно подумать как это реализовать.
Просто все эти эти разговоры, что мы заботимся о вашем удобстве, сделали шоппинг без регистрации и поэтому показываем все ваши данные любому человеку так или иначе узнавшему ссылку выглядят неумелой отмазкой и попыткой сделать хорошую мину про плохой игре.
Показывать всю приватную инфу чуваку, пришедшему по ссылке — это верх корявости.
Насколько я понимаю, последние скандалы показвают, что не разумно передавать идентификаторы пользователя в GET-параметрах. В моем случае, пользователь по ссыке из письма попадает на старницу с полем «Введите номер заказа» и post-формой.
> Не юзабельно.
В сочетании с email-нотификациями — вполне. Более того, при грамотных email-нотификациях (почти) никто вобще не пойдет в магазин проверять статус заказа.
В идеале — прятать заказ после подтверждения о доставке покупателю (после этого зачем покупателю возвращаться и проверять статус?). При нашем несовершенном шиппинге — через какой-то разумный таймаут. Можно подумать как это реализовать.
Просто все эти эти разговоры, что мы заботимся о вашем удобстве, сделали шоппинг без регистрации и поэтому показываем все ваши данные любому человеку так или иначе узнавшему ссылку выглядят неумелой отмазкой и попыткой сделать хорошую мину про плохой игре.
Показывать всю приватную инфу чуваку, пришедшему по ссылке — это верх корявости.
Про пост-форму вы не упомянули, сорри.
Ну не знаю, за последние лет 5 мой режим использования почты сильно изменился, прежде всего перестал использовать десктопные клиенты, теперь уведомления о новой почте не появляются, захожу смотреть почту в основном на предмет просмотра рассылок или когда где-то зарегался. Заходить смотреть не изменился ли статус заказа будет неудобно.
Ну не знаю, за последние лет 5 мой режим использования почты сильно изменился, прежде всего перестал использовать десктопные клиенты, теперь уведомления о новой почте не появляются, захожу смотреть почту в основном на предмет просмотра рассылок или когда где-то зарегался. Заходить смотреть не изменился ли статус заказа будет неудобно.
> Про пост-форму вы не упомянули, сорри.
My bad. :)
> Заходить смотреть не изменился ли статус заказа будет неудобно.
Ну, тут у каждого свой кейз. Сейчас, имхо, тренд на мобильные клиенты, и email-нотификации гораздо более оперативная и удобная штука. Чтобы никуда не ходить и не проверть по 10 раз изменился ли статус.
Но мой главный поинт был даже не в том. Сейчас все ругаются, одни обвиняют Яндекс, что проиндексировал через метрику, другие — владельцев магазина (robots.txt, etc). Мой поинт, что главный фейл — в том, что все эти приватные данные были доступны по ссылке (не важно насколько она супер-секретная), без какого-либо процесса аутентификации. Хоп и все! Тыкнул и читаешь.
Это и есть криворукость разработчиков движка. Как, в каком виде это реализовать — это другой вопрос. Тут можно сесть командой в переговорке и за 2 часа придумать красивое изящное решение. Или сделать несколько и давать на выбор. По-разному можно сделать. Но не так.
А яндекс на сам деле так или иначе проиндексировал _публичные_ ссылки. От того, что о них никто не знает, они публичными быть не перестают.
My bad. :)
> Заходить смотреть не изменился ли статус заказа будет неудобно.
Ну, тут у каждого свой кейз. Сейчас, имхо, тренд на мобильные клиенты, и email-нотификации гораздо более оперативная и удобная штука. Чтобы никуда не ходить и не проверть по 10 раз изменился ли статус.
Но мой главный поинт был даже не в том. Сейчас все ругаются, одни обвиняют Яндекс, что проиндексировал через метрику, другие — владельцев магазина (robots.txt, etc). Мой поинт, что главный фейл — в том, что все эти приватные данные были доступны по ссылке (не важно насколько она супер-секретная), без какого-либо процесса аутентификации. Хоп и все! Тыкнул и читаешь.
Это и есть криворукость разработчиков движка. Как, в каком виде это реализовать — это другой вопрос. Тут можно сесть командой в переговорке и за 2 часа придумать красивое изящное решение. Или сделать несколько и давать на выбор. По-разному можно сделать. Но не так.
А яндекс на сам деле так или иначе проиндексировал _публичные_ ссылки. От того, что о них никто не знает, они публичными быть не перестают.
Это да, их фэйл. Но вот юридическую ответственность за то, что данные утекли несут всё же владельцы магазинов — пользователи пользовались их услугами и сообщали данные им, а не разработчикам. Владельцы сайтов могут попробовать обратиться к разработчикам с требованием возместить вред, включая недополученные доходы и урон деловой репутации, но сомневаюсь, что такое требование имеет судебную перспективу — наверняка «AS IS», «no warranty» и т. п.
Обычно в таких случаях просят ввести кодовое слово, может быть и ФИО. Ну нельзя чтобы без каких-либо ограничений открывалась страница с персональными данными просто при переходе по ссылке — это неправильно! Это нарушение любых понятий об ИБ.
как вариант можно сделать отправку пользователю на email ссылки с одноразовым токеном — он перешел 1 раз, авторизовался, смотрит свой заказ. если кто-то другой попробуйет перейти по той же ссылке — ему выдастся ошибка что токен уже использован.
При использовании токена пользователю сразу высылать новый чтобы потом он смог еще раз зайти. Получается система без дополнительных требований что-то ввести, без лишних редиректов и т.д.
При использовании токена пользователю сразу высылать новый чтобы потом он смог еще раз зайти. Получается система без дополнительных требований что-то ввести, без лишних редиректов и т.д.
Ок. А если токен оказался скомпрометирован еще до того, как по нему перешел пользователь 1 раз?
Надеемся на почту? На то, что ссылки из писем не ставятся в очердь на индексирование?
Надеемся на почту? На то, что ссылки из писем не ставятся в очердь на индексирование?
если авторы надоумились писать в один хеш все данные пользователя для входа и не спрашивают пароль(который могут поставить сами на время пока пользователь не поставит свой) — это большая ошибка.
Перейдя не только на поисковик, но на сайт недобросовестного вебмастера счастливый обладатель заказа может пострадать.
Думаю или из писем или из других источников проявились эти дырки — обязательно выяснят.
Перейдя не только на поисковик, но на сайт недобросовестного вебмастера счастливый обладатель заказа может пострадать.
Думаю или из писем или из других источников проявились эти дырки — обязательно выяснят.
Одноразовый токен не годится. Есть почтовые антивирусы (или антиспамы), которые при получении почты еще до доставки её в ящик ходят по указанным в письме ссылкам на предмет «не раздаёт ли она зловреды» или «не спамные ли страницы» (если в письме ничего кроме ссылки нет, то антиспам анализирует страницу по ссылке), т.е. фильтр съест такой счетчик, не оставив пользователю.
У меня альтернативное предложение, как не сдавать роботам закрытые страницы, если нужно отдавать их без авторизации: подгружать «секретную часть» страницы ajax'ом. Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят. И яндекс.бар не спалит.
У меня альтернативное предложение, как не сдавать роботам закрытые страницы, если нужно отдавать их без авторизации: подгружать «секретную часть» страницы ajax'ом. Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят. И яндекс.бар не спалит.
Выход один — куки, или авторизироваться :)
>Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят
да лаааадно, не запускают…
да лаааадно, не запускают…
Неужто запускают? А я такой трюк с подгрузкой применял, страницы попали в индекс без подгружаемого блока — почему тогда?
Яндекс и гугл очень неплохо научили запускать 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.
У меня движок заточен под 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.
НЛО прилетело и опубликовало эту надпись здесь
Сопутствующий вопрос — зачем на странице трекинга заказа показывать персональные данные получателя и содержимое заказа?
С этой страницы клиент может перейти к оплате заказа и получить данные об оплаты: например, распечатать счет или квитанцию. Эти действия предполагают вывод информации о клиенте и составе его заказа. Поэтому вся эти информация показывается. Это такой маленькие «личный кабинет», ограниченный всего одним заказом (так как пользователь не зарегистрирован с постоянным логином-паролем, других связанных данных у него нет — только заказ).
Вся ответственность, безусловно, лежит на разработчиках движка.
Дело тут не в поисковике, даже если он не должен был что-то-там индексировать. Проблема в том, что личные данные были в открытом доступе, авторизации не было предусмотрено.
Дело тут не в поисковике, даже если он не должен был что-то-там индексировать. Проблема в том, что личные данные были в открытом доступе, авторизации не было предусмотрено.
Мы и не снимаем с себя ответственности. Конечно, следовало делать дополнительную идентификацию клиента (что и внедрили сегодня в виде патча), однако, стоит обратить внимание и на поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс. На наш взгляд, эту практику необходимо менять, иначе подобные проблемы в рунете могут (и будут) происходить еще со многими сайтами и скриптами.
Не факт, что виновата Метрика. Вполне может быть виноват какой нибудь аддон|плагин к броузеру.
Но факт, что разработчики часто забывают про robots.txt. И про мета тег noindex.
так как robots.txt — это всего лишь инструкции рекомендательного, а не директивного характера. Хорошо, что robots.txt принимают во внимание поисковые боты сегодня, однако, как это будут обрабатываться в будущем — вопрос открытый. Вдруг что-нибудь в боте сломается
Если сломается, то это уже будет не ваша вина. И будьте уверены Гуглу или Яндексу придется оплачивать приличные суммы если утечет приватная информация.
Но факт, что разработчики часто забывают про robots.txt. И про мета тег noindex.
так как robots.txt — это всего лишь инструкции рекомендательного, а не директивного характера. Хорошо, что robots.txt принимают во внимание поисковые боты сегодня, однако, как это будут обрабатываться в будущем — вопрос открытый. Вдруг что-нибудь в боте сломается
Если сломается, то это уже будет не ваша вина. И будьте уверены Гуглу или Яндексу придется оплачивать приличные суммы если утечет приватная информация.
В действительности яндекс очень четко следует robots.txt и пока у нас нет в известности ни одного случая его нарушения. Так что действительно, попытка перекинуть все на Яндекс авторами движка как-то очень криво смотрится.
Неужели нельзя было добавить учитывающий это robots.txt в стандартную поставку? Я уверен что можно.
Неужели сейчас нельзя признать свою ошибку? Мне кажется, это тоже следовало бы сделать.
Неужели нельзя было добавить учитывающий это robots.txt в стандартную поставку? Я уверен что можно.
Неужели сейчас нельзя признать свою ошибку? Мне кажется, это тоже следовало бы сделать.
Более того, ваш скрипт мог бы отдавать:
Почему это не заложено в движке? Тоже кривая метрика виновата?Не знаком с движком, но есть подозрение, что скрипт только выводит данные в шаблоны, созданные веб-мастерами/верстальщиками на основе шаблонизатора типа Smarty.
В таком случае помог бы robots.txt. Плюс в движке можно завести переменную, что страница приватная, по которой шаблон должен выводить этот мета-тег. Это в любом случае полезно, т.к. пользователи с барами, хромами и прочими троянами были есть и будут, и если не яндекс, так гугл, бинг или яху — все равно бы это сделал, т.к. давайте будем честными — авторы пренебрежительно относились к этой угрозе.
Если действительно используется шаблонизатор в режиме включения вывода движка в шаблон (я бы сделал так), а не наоборот, то ни один тег без явного указания в шаблоне не выведется. То есть угроза того, что данные «утекут» (будут проиндексированы честным поисковиком) мета-тегом в общем случае не устраняется — максимум в мануал можно включить рекомендацию этот тег ставить для таких страниц.
Хабрапарсер съел HTML:
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
Ошибка не в робот.txt она более глобальная, на уровне наплевательства на стандарты безопастности.
прекратите клеймить и нагнетать. проебали, пофиксили, бывает.
я вот сейчас подумал и вспомнил, что в одном проекте мы такой же способ применяли. потомучто это удобно. и ссылка там не может быть одноразовой. шо делать, повеситься?
я вот сейчас подумал и вспомнил, что в одном проекте мы такой же способ применяли. потомучто это удобно. и ссылка там не может быть одноразовой. шо делать, повеситься?
Пофиксить! :)
Ну разработчик ошибку то не признал ;) И начинает отмазываться, а здесь не все великие программисты, начинают верить отмазкам, потом все это начинают рассказывать своим друзьям, потом ламерить и т.п. Вот к чему я.
Пусть напишет как вы сказали: мы прое… ли, бывает. Пофиксили.
Не вешаться не надо. Если вы делали проект на основе своего движка, совет: ни в коем случае не вешаться, и второй: ping-update (если интересно что это, могу написать в личку) прикрутить к движку.
Пусть напишет как вы сказали: мы прое… ли, бывает. Пофиксили.
Не вешаться не надо. Если вы делали проект на основе своего движка, совет: ни в коем случае не вешаться, и второй: ping-update (если интересно что это, могу написать в личку) прикрутить к движку.
Скажите пожалуйста, о каких стандартах вы говорите? Вы можете привести ссылку на какие-то материалы освещающие эти стандарты?
RFC 2616
Спасибо!
Из рекомендаций RFC по использованию протокола HTTP можно сделать два вывода:
1) В GET параметрах нельзя передавать частную и чувствительную информацию,
2) Программы которые раскрывают ссылки, которые не предназначены для публики, занимаются сливом персональных данных.
Согласны?
Из рекомендаций RFC по использованию протокола HTTP можно сделать два вывода:
1) В GET параметрах нельзя передавать частную и чувствительную информацию,
2) Программы которые раскрывают ссылки, которые не предназначены для публики, занимаются сливом персональных данных.
Согласны?
По-моему 2 противоречит 1. Раз нельзя в GET параметрах передавать ничего важного, значит в ссылке нет ничего важного и её можно публиковать.
В самой ссылке нет ничего важного, но на странице на которую она ведет — может быть важное. И если программа показывает содержимое страницы, не предназначенное для всех, потому что она смогла увидеть это содержимое, используя своих «жучков» — это слив. Помоему так.
А по-моему нет. То, что не предназначено для всех должно быть защищено аутентификацией и авторизацией. А раз показывается любому, знающему адрес, то эта информация считается (законом) общедоступной.
Согласно законодательству РФ:
1. К общедоступной информации относятся общеизвестные сведения и иная информация, доступ к которой не ограничен.
Персональные данные хранились на странице, ссылка на которую выдавалась только владельцу — вот такое ограничение. С другой стороны RFC говорит, что ссылка не может быть ключом, потому что она везде светится — логируется, передается в реферере и прочее. В общем, defected by design, как тут уже кто-то сказал.
Остается вопрос — насколько это порядочно со стороны Яндекса, брать ссылки из всяких странных мест. Ведь не все знали, что их может найти поисковый бот — на сайте-то на них ссылки нет. Это похоже на то, как если бы кто-то копался в моей сумке, пока я отвернулся. Но это лично мое мнение, а не мнение общественности. А мнение общественности здесь как раз и имеет определяющее значение.
Вы ошибаетесь.
В самой ссылке есть важное.
Сама ссылка — это authentication credentials. Аналог логина и пароля.
Которые нельзя передавать ГЕТом.
В самой ссылке есть важное.
Сама ссылка — это authentication credentials. Аналог логина и пароля.
Которые нельзя передавать ГЕТом.
> поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс.
Чем страница /a/b/c отличается от страницы /d/e/f с точки зрения поискового бота? ничем. То, что страница /d/e/f приватная известно только вам
Чем страница /a/b/c отличается от страницы /d/e/f с точки зрения поискового бота? ничем. То, что страница /d/e/f приватная известно только вам
Что значит в открытом доступе? По сути, страница с персональными данными возвращается при предъявлении уникального хеша, известного только пользователю. Яндекс эти хэши тупо п*здит. Этот примерно то же самое, как если бы яндекс п*здил вводимые пароли и индексировал, например, почту.
Не забывайте, что это всего лишь бот. Он кушает всё, что ему дают.
О том и разговор, что адреса посещаемых сайтов, не говоря уже про передаваемые в адресной строке параметры — персональные данные. Яндекс как минимум не должен их публиковать, а по-хорошему не должен их вообще собирать. Тогда и вопроса о том, что именно нельзя индексировать не возникнет. Ещё раз, речь идёт о данных, получаемых яндексом с помощью клиентских скриптов и браузерных плагинов с компьютеров пользователей.
Вопрос в том, кто скармливает ссылки боту?
Если он их находит на просторах интернета — это одно, а если он их получает из метрики, то тут пускай уж удосужится проверить ссылку на общедоступность (хотя бы просто поискав эту ссылку в своей же базе)
Если он их находит на просторах интернета — это одно, а если он их получает из метрики, то тут пускай уж удосужится проверить ссылку на общедоступность (хотя бы просто поискав эту ссылку в своей же базе)
Вот именно. Боту дают ссылку из приватного имейла. Это нормально?
Не примерно. Как минимум общепринято («обычай делового оборота» — есть такой термин в юриспруденции), что секретные/конфиденциальные/персональные/личные/… данные не передаются в GET запросах по HTTP протоколу.
Увы, это не так. Ссылка с ключем авторизации в параметре это слишком удобно, чтобы от этого отказываться, и ее используют довольно многие (в том числе Мой Круг, кстати). Поэтому хорошо бы решить эту идеологическую проблему.
Сделать её одноразовой (МойКруг, кажется, именно так её использует)? Пока пользователь не перейдёт по ней в браузере о ней никто не узнает (кроме хакеров и индексаторов почты), а когда узнает, то смысла знать её уже не будет!
Надо посмотреть. А если пользователь захочет по ней пройтись дважды из своего письма?
В момент перехода выслать ему вторую уникальную ссылку.
Действительно, у МоегоКруга они одноразовые.
Ага, и забить ему почтовый ящик :)
Ага, и забить ему почтовый ящик :)
В какой мемент перехода высылать вторую ссылку? В первый раз или каждый раз.
Как только одноразовая ссылка использована — высылать новую, если уж так не хочется аутентифицировать по кукам и/или паролю.
А при повторном обращении по уже использованной ссылке, что должно происходить?
Что делать, если отправленная новая ссылка не получена адресатом?
Что делать, если отправленная новая ссылка не получена адресатом?
если отправленная новая ссылка не получена адресатом
то же самое, что делают если первая ссылка не была получена, никакой разницы. Ну т.е. каждый сервис решает эту проблему по-совему, самый простой способ — телефон техподдержки.
при повторном обращении по уже использованной ссылке
выводить сообщение «ваша ссылка устарела, зайдите пожалуйста на почту и перейдите по новой».
Ну и в рамках одной сессии подразумевается что человек может кликать по «использованной» ссылке сколько влезет — она будет работать верно т.к. человек уже авторизован. Когда кончается сессия чтобы снова авторизоваться он переходит по новой ссылке.
Сделать авторизацию как сделали авторы (по фамилии) можно по почте, по фамилии, по чертче чему еще кто знает, букву в почте присылать которую нужно вставлять, и все эти данные уже будут защищены на порядок выше.
Угу, а что будет, если по этой ссылке первым перейдет индексатор, а не пользователь?
А что будет если ваш трафик снифают или кейлоггер у вас сидит? Афаик, нет ни одного случая умышленной передачи персональных данных или переписки из почты третьим лицам известными почтовыми сервисами, если они не обязаны были это сделать по закону или пользователь явно не выразил такого желания.
Механизм, которым «непубличные» URLы попали в индексаторы до сих пор неизвестен и никаких официальных комментариев, насколько я знаю, до сих пор не было сделано. В качестве одной из версий — называлось то, что индексируются URLы, найденные в почте.
То, что туда ходят краулеры — я сам прекрасно знаю, неоднократно наблюдал в логах своих веб-серверов — когда ссылки, которые упоминались только в почте, внезапно посещали клиенты с чудесными словами Yandex и Google в user-agent. На вопрос — попадали ли в итоге посещаемые страницы в публичный поисковый индекс — я пока ни однозначного утвердительного, ни однозначно опровергающего ответа не знаю.
То, что туда ходят краулеры — я сам прекрасно знаю, неоднократно наблюдал в логах своих веб-серверов — когда ссылки, которые упоминались только в почте, внезапно посещали клиенты с чудесными словами Yandex и Google в user-agent. На вопрос — попадали ли в итоге посещаемые страницы в публичный поисковый индекс — я пока ни однозначного утвердительного, ни однозначно опровергающего ответа не знаю.
Да найдены они могут быть где хочешь. Вопрос в том, что разработчики наплевали на нормы и стандарты безопасности, если бы они их соблюдали изначально, такого бы не было.
Вы уверены, что только в почте? Что пользователи (или вы) по этим ссылкам не переходили до их визита краулером?
URLы достаточно персонализированы. Пользователи — достаточно инертные работники бюджетных организаций, ходят с рабочих компьютеров в рабочее время.
Наблюдал развитие по примерно следующему сценарию:
Наблюдал развитие по примерно следующему сценарию:
- Письмо со ссылкой отправляется в ~20:00 MSD (нерабочее время рабочего дня)
- В ~23:00 MSD приходит робот
- В ~10:00 MSD следующего рабочего дня приходит легитимный пользователь — получатель этого письма и начинает свою сессию работы с системой
Это да, серьёзный повод задуматься. А почта была у одного почтовика?
Почта рассылалась автоматически из скрипта, запускаемого вечером по cron через собственный smtp-сервер. Адресатов порядка нескольких десятков, ссылки у каждого уникальные и персонализированные. Прямой корреляции типа «послал на gmail => придет Googlebot», «послал на yandex => придет Yandex» не строил, но подозреваю в первую очередь все-таки индексацию URL из почты.
Собственно, сейчас посмотрел на то, что выдает Google и Яндекс при поиске по обозначенному сайту, ситуация, прямо скажем, странная. Сайт состоит из:
А интересно и странно то, что Google честно показывает для этого сайта в индексе только одну открытую морду, а Яндекс зачем-то и откуда-то заиндексировал еще 3-4 очень странных внутренних URL, причем отрубив у них query; для внешнего человека без авторизации они и так в любом случае нерабочие, но без query — они даже с авторизацией будут выдавать внутренние ошибки системы. Эти внутренние URL (особенно в таком обрезанном виде) вряд ли когда-либо пересылались через почту, зато вполне вероятно, что какой-то из пользователей имеет Яндекс.Бар.
Никаких внешних счетчиков и javascript'ов на сайте не стоит.
Собственно, сейчас посмотрел на то, что выдает Google и Яндекс при поиске по обозначенному сайту, ситуация, прямо скажем, странная. Сайт состоит из:
- одна страничка dashboard-style морды — доступна свободно, на ней список URL подсистем
- n подсистем, каждая из которых закрыта авторизацией
- открытая «публикующая» часть внутри каждой подсистемы, обеспечивающая отображение подготовленной в системе информации по ряду открытых URL — частично они рассылались упомянутым выше cronjob'ом
А интересно и странно то, что Google честно показывает для этого сайта в индексе только одну открытую морду, а Яндекс зачем-то и откуда-то заиндексировал еще 3-4 очень странных внутренних URL, причем отрубив у них query; для внешнего человека без авторизации они и так в любом случае нерабочие, но без query — они даже с авторизацией будут выдавать внутренние ошибки системы. Эти внутренние URL (особенно в таком обрезанном виде) вряд ли когда-либо пересылались через почту, зато вполне вероятно, что какой-то из пользователей имеет Яндекс.Бар.
Никаких внешних счетчиков и javascript'ов на сайте не стоит.
ну вот например, если отправить в gtalk ссылку на ютуб, то умный клиент на андроиде быстренько загрузит превьюшку.
что мешает ему в какой-то момент решить подгружать любую страницу, чтобы вместо длинной дурацкой ссылки показывать содержимое тега «title»?
что мешает ему в какой-то момент решить подгружать любую страницу, чтобы вместо длинной дурацкой ссылки показывать содержимое тега «title»?
Ну нельзя делать их одноразовыми вам уже кажется писали. Антивирусы проверяют, сбрасывая счетчик, расширения ит.п.
Только куки или авторизация — это в принципе, то, основная концепция авторизации, но уж ни как не через get (а это именно в конкретном случае и была авторизация — будем называть вещи своими именами) запрос (ну просто детская ошибка).
И не надо делать вид разработчикам что они здесь не при чем, всё они знают как лоханулись, только надож хоть немного «кармы» продукта сохранить, только вот на карму хабра можно наплевать, а вот от «кармы» продукта зависит фактически жизнь компании. Поэтому и не признают, и не признают. Но для специалистов — виновник известен, рассказывайте басни дальше и другим.
Только куки или авторизация — это в принципе, то, основная концепция авторизации, но уж ни как не через get (а это именно в конкретном случае и была авторизация — будем называть вещи своими именами) запрос (ну просто детская ошибка).
И не надо делать вид разработчикам что они здесь не при чем, всё они знают как лоханулись, только надож хоть немного «кармы» продукта сохранить, только вот на карму хабра можно наплевать, а вот от «кармы» продукта зависит фактически жизнь компании. Поэтому и не признают, и не признают. Но для специалистов — виновник известен, рассказывайте басни дальше и другим.
Я имел в виду «условно одноразовые»: приходит пользователь с кукой — даём ему доступ один раз. Приходит без куки (или второй раз?) — даём 401 (403?) и просим пароль, высланный в том же письме, что и ссылка. Где-то в комментах расписывал подробнее.
Достаточно привязать первый запрос к ip пользователя.
Так не надо делать, на одном ip могут сидеть тысячи пользователей :) куки и еще раз куки
У меня динамический IP от нескольких мобильных провайдеров, а статический расшарен чуть ли не со всем районом (НАТ).
Одно дело прикрывать ключиком фоточки, другое дело прикрывать, таким вот ключиком, личные данные, включая полное имя/отчество, мыло и адрес доставки!
Тот же амазон 10 раз переспросит логин пароль, пока я доберусь до смены адреса.
Тот же амазон 10 раз переспросит логин пароль, пока я доберусь до смены адреса.
Круто, а, то что любой провайдер/снифер/проксисервер/другое так же спокойно как и яндекс могут парсить эти get запросы, создателей движка не должно волновать?
Вы так говорите, что все, что находится в интернете, должно передаваться только безопасным путем. А как быть с людьми, которые работают в небезопасной Wifi и кто-то начнет собирать пароли и индексировать, что находится внутри. Или при аутентификации открытым токеном, который передается в HTTP Property. А уникально сгенерированный ключ в запросе слабая, но все-таки защищенная ссылка.
Даже Гугл, который относится к безопасности очень ревностно, позволяет расшарить фотографии и документы только на основе ссылки.
Даже Гугл, который относится к безопасности очень ревностно, позволяет расшарить фотографии и документы только на основе ссылки.
Даже Гугл, который относится к безопасности очень ревностно, позволяет расшарить фотографии и документы только на основе ссылки.
Ключевое слово «позволяет расшарить».
Кстати да, Гугл документы расшариваются по ссылке. (если вноват яндекс бар или другой плагин) Похоже можно пробовать искать в Яндексе и эти приватные документы.
Долгое время механизм уникального урл, известного только пользователю, де-факто являлся авторизацией. Создав Метрики, Бары и т.п., поисковые системы поломали этот механизм. Механизм, который используется везде.
Конечно, Яндекс может прикрыться законом о персональных данных и сказать — «теперь защита от нашего бота — это ваша проблема», но очевидно, что данную ситуацию Яндекс просто проворонил.
Я согласен насчет robots.txt: поисковым системам он не указ и на половину параметров в нем они просто плюют.
Конечно, Яндекс может прикрыться законом о персональных данных и сказать — «теперь защита от нашего бота — это ваша проблема», но очевидно, что данную ситуацию Яндекс просто проворонил.
Я согласен насчет robots.txt: поисковым системам он не указ и на половину параметров в нем они просто плюют.
Вы счас это серьезно про механизм, который используется *везде*?
/me Взглянул на дату; нет, не `96-й на дворе…
Расшаривание ссылки гуглом — отдельная история, она, во-первых, передается человеку лично (по емэйлу, Im и т.д), во-вторых, предполагается, что она выдается на короткое время.
К слову, даже в древние времена де-факто авторизацией являлась Basic Auth, описанная в rfc1945.
Да, и яндекс предоставляет свой сервис бесплатно, а в условиях использования ясно сказано:
Пункт 11. Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные данные [...] и в автоматическом режиме передаёт их Яндексу [...] доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.
/me Взглянул на дату; нет, не `96-й на дворе…
Расшаривание ссылки гуглом — отдельная история, она, во-первых, передается человеку лично (по емэйлу, Im и т.д), во-вторых, предполагается, что она выдается на короткое время.
К слову, даже в древние времена де-факто авторизацией являлась Basic Auth, описанная в rfc1945.
Да, и яндекс предоставляет свой сервис бесплатно, а в условиях использования ясно сказано:
Пункт 11. Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные данные [...] и в автоматическом режиме передаёт их Яндексу [...] доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.
Именно используется. Именно везде. В условиях, когда магазины борются за клиентов, в приоритете всегда будет максимально простой сервис.
«Вы счас это серьезно про» «анонимные данные»?
собирает анонимные данные
«Вы счас это серьезно про» «анонимные данные»?
расскажите-ка, как робот должен отличать «анонимные» get-параметры от «неанонимных»?
Спросите об этом людей, персональные данные которых скриптами скопировали все, кому не лень.
Кстати, я смотрю на проблему несколько шире. Роботы роботами, а за выдачу Яндекс все-таки должен отвечать, как ни крути.
За всех говнокодеров никто ответить не в состоянии, кроме их самих. Может хоть уволят кого…
Это им удалось проигнорировать элементарные правила безопасности, robots.txt и свойство ut:'noindex' специально для метрики, куда уж тут шире смотреть?
Это им удалось проигнорировать элементарные правила безопасности, robots.txt и свойство ut:'noindex' специально для метрики, куда уж тут шире смотреть?
За что увольнять-то?!
Это все местечковые «правила безопасности». Google noindex не учитывает, Яндекс начал учитывать nofollow только недавно, а завтра возьмет, и опять перестанет. Появится другая ПС — вообще на все наплюет. То, что в robots.txt учитываются не все директивы, похоже, неизвестно только вам. Т.е. robots.txt изначально учитывается частично. Все подобные меры просто смехотворны.
Да, согласен, смехотворны, но это были бы хоть какие-то попытки что-то прикрыть.
А вообще, ниже много на эту тему написано, можно толкать куку, которая бы аутентифицировала по ссылке.
Без куки был бы виден только статус заказа и список товаров, с кукой — фио, адрес, контакты, и прочее, что сейчас выставлено всем на обозрение.
А вообще, ниже много на эту тему написано, можно толкать куку, которая бы аутентифицировала по ссылке.
Без куки был бы виден только статус заказа и список товаров, с кукой — фио, адрес, контакты, и прочее, что сейчас выставлено всем на обозрение.
Да, можно было бы сделать много чего. Только когда придумывали механизм уникального урла, никому и в голову не могло прийти, что вебмастера будут добровольно ставить на сайты троянов. :)
Вы представляете себе, сколько сайтов сейчас нужно переделывать? Т.е. сколько народу Яндекс и другие гипотетически поставили на деньги?
Вы представляете себе, сколько сайтов сейчас нужно переделывать? Т.е. сколько народу Яндекс и другие гипотетически поставили на деньги?
да кто вообще суёт в УРЛ хеши????
какой век на дворе???
какой век на дворе???
Какие деньги? Три-четыре (ну всяк не больше десятка) строчки на PHP и одну колонку в БД добавить, чтобы закрыть свою безалаберность и, извиняюсь, похуизм к отношению персональным данным клиента?
Что значит троянов, не пойму? Никто не скрывал, что метрика индексирует страницы, для этого есть параметр, предотвращающий это.
Ну да, куча народу, а что делать? Или «миллионы мух не могут ошибаться»? )
Общеизвестно, что в этой стране любят заказать магазин за 15к руб., а потом жаловаться что «ниработаит», ну сами виноваты, че.
Ну да, куча народу, а что делать? Или «миллионы мух не могут ошибаться»? )
Общеизвестно, что в этой стране любят заказать магазин за 15к руб., а потом жаловаться что «ниработаит», ну сами виноваты, че.
Без куки нужно просить пароль, высланный в том же письме, что и ссылка. Сам факт, что сделан заказ (а тем более список товаров) может быть неприятен клиенту, если о нём узнают третьи (особенно близкие) лица, даже если клиент почистит куки.
как не крути — эта информация была доступна всем людям в сети…
ещё чуть шире, попробуйте, поразмышлять
ещё чуть шире, попробуйте, поразмышлять
Вы вообще о чем?
Доступна всем, когда Яндекс сделал ее доступной всем?
До этого она была доступна только клиенту, получившему ссылку.
Доступна всем, когда Яндекс сделал ее доступной всем?
До этого она была доступна только клиенту, получившему ссылку.
Почему Вы забываете о возможности просмотра «HTTP referer»???
Или этого мало???
Или этого мало???
Она была доступна до этого любому, «догадавшемуся» набрать нужный урл. Среди «догадавшихся»: правоохранительные органы, сотрудники провайдеров многих уровней, сотрудники администрации прокси-серверов, сотрудники создателей браузеров и, главное, расширений (добровольно установленных пользователем) к ним, сотрудники сайта, а также «тупым» брутфорсерам или просто людям, которым сопутствует удача. В стандарте http написано — нефиг передавать «чувствительные» данные гет-запросом — их пишут (а занчит и могут прочитать) все кому не лень!
Есть три основных понятия в данной сфере: идентификация, аутентификация и авторизация. Первое, грубо говоря, является процессом представления клиентом серверу «Я такой-то» (логин, ник, ФИО и т. п.). Второе — то же плюс доказательство, что клиент действительно «такой-то» (пароль, сертификат и т. д.). Третье — проверка сервером, что представившийся клиент (идентифицированный или аутентифицированный) имеет право на то действие, что запросил. Согласно духу и букве 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.
> данные были в открытом доступе, авторизации не было предусмотрено.
Ну, секретный URL тоже ведь можно считать своего рода паролем…
Ну, секретный URL тоже ведь можно считать своего рода паролем…
У Яндекса — Метрика, а у Гугля — что?
Об этом написано поста:
3. Яндекс проиндексировал именно такие страницы. Точнее, страницы, которые посещали покупатели (переходили по ссылкам из писем-уведомлений).
4. Гугл и другие поисковики проиндексировали эти же страницы уже после того, как информация об этом появилась в новостных лентах, на Хабре и стала «достоянием общественности».
3. Яндекс проиндексировал именно такие страницы. Точнее, страницы, которые посещали покупатели (переходили по ссылкам из писем-уведомлений).
4. Гугл и другие поисковики проиндексировали эти же страницы уже после того, как информация об этом появилась в новостных лентах, на Хабре и стала «достоянием общественности».
Вот только в трекинге не отображается адрес получателя и содержимое его отправления.
Суммируя: разработчики скрипта обвиняют Яндекс, Яндекс обвиняет создателей сайтов, те, кто поумнее, обвиняют оленей-веб-мастеров, веб-мастера молчат в тряпочку, прочие журналисты просто пишут «Ололошеьки Яндекс слил вашу приватную информацию».
Единственное, чего я не понимаю в данной ситуации — это что такое «Смазка с эффектом «Узкий вход».
Единственное, чего я не понимаю в данной ситуации — это что такое «Смазка с эффектом «Узкий вход».
Мы не обвиняем Яндекс — мы обращаем внимание на вопрос этичности и легитимности добавления любых адресов, которые нашел Яндекс с помощью своих сервисов, в общий публичный индекс.
а что Яндексу посадить миллион негров и азиатов и пусть они ручками каждый линк проверяют, что ли? Яндекс сделал то, что должне был сделать. Нашел ЛЮБУЮ ИНФУ, которая была в ОТКРЫТОМ доступе.
Вопрос этичности к вам, товарищи разрабы.
Вопрос этичности к вам, товарищи разрабы.
Так в том и дело, что в данном случае доступ НЕ открытый.
открытость в инете априори. все что не скрыто, кушается ботами.
Боты кушают все, некоторые из них подбирают пароли и создают ботнеты, пользуясь принципом, что ненадежно защитили — ваши проблемы.
Угу, Вы пошли в лес голышом, даже без трусов, по-вашему, то, что Вас искусали комары и за причинное место клещ вцепился это вина комаров и клещей? А вот и нет: нехуй нудизмом заниматься в лесу полном кровососов.
Или, ходя бы, репеллентом не помазаться (роботс.ткст не прописать нормально).
Вот, наконец, и вывод дискуссии: поисковые машины — кровососы, паразиты и хищники? Яндексов бояться — в Сеть не ходить :)
Всё таки Яндекс в данной истории стащил URL НЕ СО СТРАНИЦЫ В ИНТЕРНЕТЕ, а скриптом на странице стащил адрес страницы или яндекс.бар'ом в браузере стащил адрес посещаемой страницы. В первом случае он без ведома пользователя запущенным у пользователя скриптом стащил приватные данные, во втором — вроде как с ведома (пользователь сам установил бар), но все равно приватные.
Если Яндекс в этой истории будет оправдан, то в будущем писатели кейлоггеров будут иметь прецедент-отмазку «а нефиг было пароль на клавиатуре набирать, она в открытом доступе (моему шпиону)». Может Яндекс.Бар кроме урлов и пароли сливает? Где его исходники? И что, он потом скажет, что надо было в robots.txt написать «яндекс, не используй мой пароль»?
Программисты шопа, конечно, виноваты, но это не значит, что Яндекс не виноват. И Яндекс виноват намноооого больше.
Всё таки Яндекс в данной истории стащил URL НЕ СО СТРАНИЦЫ В ИНТЕРНЕТЕ, а скриптом на странице стащил адрес страницы или яндекс.бар'ом в браузере стащил адрес посещаемой страницы. В первом случае он без ведома пользователя запущенным у пользователя скриптом стащил приватные данные, во втором — вроде как с ведома (пользователь сам установил бар), но все равно приватные.
Если Яндекс в этой истории будет оправдан, то в будущем писатели кейлоггеров будут иметь прецедент-отмазку «а нефиг было пароль на клавиатуре набирать, она в открытом доступе (моему шпиону)». Может Яндекс.Бар кроме урлов и пароли сливает? Где его исходники? И что, он потом скажет, что надо было в robots.txt написать «яндекс, не используй мой пароль»?
Программисты шопа, конечно, виноваты, но это не значит, что Яндекс не виноват. И Яндекс виноват намноооого больше.
В первом случае он вроде как стащил с сайта данные с ведома владельца сайта. Пользователь (вернее его браузер, выполняющий скрипт) — лишь средство передачи этих данных.
Только кейлогерам нужно будет при инсталляции «заставить» пользователя принять EULA с пунктом типа: «все нажатия клавиш передаются на сервер Авторов и могут быть использованы ими по своему усмотрению».
Только кейлогерам нужно будет при инсталляции «заставить» пользователя принять EULA с пунктом типа: «все нажатия клавиш передаются на сервер Авторов и могут быть использованы ими по своему усмотрению».
Ага, ну-ну. «Мы шли мимо, дверь открыта была, ну подёргали, открылаксь, зашли и начали выносить всё, ну а что добру пропадать, на предметах же не было табличек „Собственность Пети“ — значит ничьё»…
Так это, по-вашему, выходит?
Так это, по-вашему, выходит?
Это абсолютно разные вещи. То что у вас могут спереть чемодан в камере хранения не ваша проблема, а камеры хранения и ответсвтенность несут они. Примерно, так!
Никто же с вашего компьютера ничего не индексировал и в паблик не выложил.
Никто же с вашего компьютера ничего не индексировал и в паблик не выложил.
В данном случае URL (как ключ к секретной странице) был ТОЛЬКО на пользовательском компьютере в адресной строке его браузера. Не на сайте («камере хранения») каком-нибудь, и даже не в реферере. Натурально стащил из-за незапертой двери.
Если этот ключевойURL был в открытом доступе — то пусть Яндекс в свою защиту приведёт URL страницы, на которой он увидел этот «открытодоступный» ключевойURL! Тогда все претензии к Яндексу снимаются, и виновными остаются авторы шопа в одиночку.
Если этот ключевойURL был в открытом доступе — то пусть Яндекс в свою защиту приведёт URL страницы, на которой он увидел этот «открытодоступный» ключевойURL! Тогда все претензии к Яндексу снимаются, и виновными остаются авторы шопа в одиночку.
Ну никак он не мог быть только там. Прежде всего он был сгенерирован на сервере, потом был передан по открытым каналам открытым текстом, никаких мер для его сокрытия не предпринималось, что по сути означает, имхо, что данная информация не относится к информации с ограниченным доступом или конфиденциальной. А даже если относится, то согласно нормам права конфиденциальную информацию владельцев сайта (ссылка никак пользователю принадлежать не может, это владельцы сайта ему её сообщают) разгласил либо пользователь, выполнив у себя программу «Яндекс.Бар», либо сам владелец сайта, «заставив» пользователя выполнить программу «Яндекс.Метрика».
Мы не знаем, по какому каналу пришло письмо тем пользователям. Вполне возможно, что на MX оно пришло по SMTP со STARTTLS (на своём сервере вижу, что многие отправители его используют, т.к. видят анонс его поддержки в EHLO), и с большой вероятностью пользователь прочел его по httpS или imapS. Т.е. нигде от очереди исходящих на почтовом сервере шопа и до почтовой программы у пользователя открытым текстом оно не шло.
Да и какая разница — сниффинг паролей вряд ли законное дело. А тут как раз полная аналогия (не с открытого сайта стащен URL, а с промежуточных «технических средств»).
Да и какая разница — сниффинг паролей вряд ли законное дело. А тут как раз полная аналогия (не с открытого сайта стащен URL, а с промежуточных «технических средств»).
кстати, неплохой пример!
камера хранения, конечно, тоже будет виновата, если чемодан сперли. Но это не снимает ответственности с того, кто спёр, правда?
камера хранения, конечно, тоже будет виновата, если чемодан сперли. Но это не снимает ответственности с того, кто спёр, правда?
401 или 403 ошибку не выдало? Не выдало, значит доступ санкционирован создателями сайта или они используют протокол HTTP ничего о нём не зная. Грубо говоря, сложили вещи на тротуаре и надолго ушли, понадеявшись, что их никто не унесёт. И то, эта аналогия в пользу веб-мастеров.
То есть, если во внутреннем кармане пиджака, лежащего на тротуаре, не было зеленой бумажки формата Letter с разборчивой надписью чернилами на русском языке «брать запрещено», то человек, взявший мой пиджак с тротуара, в случае поимки избежит ответственности?
Более развернутая аналогия с изъятием материальных ценностей, с учетом общего тренда комментариев:
Так как в день получки, когда Петя нёс зарплату домой, у Пети при себе не было в нагрудном кармане бумажки с надписью:
жуликос.txt
на которой было бы написано:
жулики *
карманы не выворачивать /
то мы вывернули карманы и забрали всё, что упало, и, согласно общепринятым поговоркам — пропало (а раз пропало — то уже не принадлежало Пете).
А Петя сам виноват — он когда входил в переулок, читал соглашение, и принял его, соглашение висит на 4-м фонарном столбе перед переулком и пункт 5.1 его гласит:
Вошедший полностью и безоговорочно соглашается с тем, что лица, стоящие в переулке, имеют права вывернуть карманы, если нет записки с содержанием…
Более развернутая аналогия с изъятием материальных ценностей, с учетом общего тренда комментариев:
Так как в день получки, когда Петя нёс зарплату домой, у Пети при себе не было в нагрудном кармане бумажки с надписью:
жуликос.txt
на которой было бы написано:
жулики *
карманы не выворачивать /
то мы вывернули карманы и забрали всё, что упало, и, согласно общепринятым поговоркам — пропало (а раз пропало — то уже не принадлежало Пете).
А Петя сам виноват — он когда входил в переулок, читал соглашение, и принял его, соглашение висит на 4-м фонарном столбе перед переулком и пункт 5.1 его гласит:
Вошедший полностью и безоговорочно соглашается с тем, что лица, стоящие в переулке, имеют права вывернуть карманы, если нет записки с содержанием…
Не путайте ситуации, когда мы в наглую вывернули карманы пиджака на Пете (ст. 161 УК РФ, а если угрожали оружием или насилием — ст. 162 УК РФ) и когда мы вывернули карманы на пиджаке, брошенном Петей (ст. 226 ГК РФ).
Здесь именно вывернули карманы пиджака (браузера) на Пете (компьютере пользователя). Никуда этот секретный URL не падал — ни на какой открытый сайт его авторы шопа не выкладывали. Яндекс стащил его из браузера пользователя — кармана на живом Пете. Без угрозы насилием, конечно, а незаметно для него. Какая там статья для карманных воров?
Ох. Вот представим себе: я родом из ЮАР, из какого-нибудь дикого племени. В моем племени убивать людей — не является чем-то плохим. Волею судеб, я попал в Россию. Читать вообще не умею (из дикого племени же). Соответственно, что такое УК РФ — понятия не имею, что это уголовно (щито O_o, для вождя-то?) наказуемо — так же.
Прибил я на улице табельным томагавком прохожего. Через 5 минут меня схватили полицейские, и пытаются посадить на 10 лет.
А теперь проведем аналогию с 4-м фонарным столбом — ведь то же самое, получается?
Не знание закона не освобождает от ответственности. Любые спорные моменты (применительно к данной ситуации) описаны в пользовательском соглашении. Почему же паника-то?
Хоть убейте, не понимаю.
Прибил я на улице табельным томагавком прохожего. Через 5 минут меня схватили полицейские, и пытаются посадить на 10 лет.
А теперь проведем аналогию с 4-м фонарным столбом — ведь то же самое, получается?
Не знание закона не освобождает от ответственности. Любые спорные моменты (применительно к данной ситуации) описаны в пользовательском соглашении. Почему же паника-то?
Хоть убейте, не понимаю.
Нет, здесь вопрос в том, что почему яндекс добавляет в индекс все страницы с метрикой, а гугл adwords — нет?
adwords и метрика разные вещи. Учите матчасть!
ок — analytics.
вообще вопрос чисто гипотетический, а как вы точно знаете что виновата метрика, что она собирает такие данные?
Ну по-моему статья как раз об этом. Паук ходит по ссылкам. Если страница unreachable пауком, то вариантов попадания немного — webmaster tools (ну или что там у яндекса) плюс скрипты трэкинга, которые сообщают адрес недостижимой страницы.
так ссылки эти нужно исключить путем nofollow и robots.txt
Все просто! Разрабы в этом случае виноваты, но все наезжают на ПС
Все просто! Разрабы в этом случае виноваты, но все наезжают на ПС
Да как раз это не так. Во-первых, robots.txt — это рекомендация. Она не является никаким стандартом или еще что. Более того, любой может прийти и скачать этот robots.txt, провести анализ и сделать выводы, мол вот тут будут лежать вкусности.
Потом, очень интересно, что в правилах Яндекс.Метрике:
Т.е. как бы странновато получается — вроде как в открытом доступе не выставлены, доступ сам не предоставлял, просто сессию записал с содержимым страницы — а тут нате — все в паблике. WTF?
Потом, очень интересно, что в правилах Яндекс.Метрике:
Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам, за исключением тех, доступ которым к таким записям Пользователь предоставил самостоятельно.
Т.е. как бы странновато получается — вроде как в открытом доступе не выставлены, доступ сам не предоставлял, просто сессию записал с содержимым страницы — а тут нате — все в паблике. WTF?
Сессию он не записывал — он сам зашёл по урлу и сайт открыл (скорее попытался открыть) боту Яндекса новую сессию.
Так а урл-то он откуда взял?
Какая разница? Сессию он не размещал? Не размещал. Её запись предоставлял? Не предоставлял. Он в открытом доступе показывает адрес по которому пользователь может начать свою сессию.
Разница принципиальная. Все те секретные URL'ы, по которым прошелся Яндекс НЕ БЫЛИ в публичном доступе (или где тот сайт, откуда он их взял?).
Поэтому и возникает вопрос — где он их взял? Либо через метрику — скрипт метрики стащил урл из адресной строки в пользовательском браузере (ваша адресная строка — открытый доступ?), либо через яндекс.бар, который тоже берет адрес из браузера, а не с открытого доступа.
В следующий раз он стащит не URL из браузера, а пароль, который вы ввели в том же браузере, но в другом поле — это тоже ему прощать?
Поэтому и возникает вопрос — где он их взял? Либо через метрику — скрипт метрики стащил урл из адресной строки в пользовательском браузере (ваша адресная строка — открытый доступ?), либо через яндекс.бар, который тоже берет адрес из браузера, а не с открытого доступа.
В следующий раз он стащит не URL из браузера, а пароль, который вы ввели в том же браузере, но в другом поле — это тоже ему прощать?
Да почему стащил? Вы соглашения Бара и Метрики читали?
Да. У меня на всех сайтах и метрика, и аналитикс. И нигде я не видел в соглашениях моего согласия на индексацию тех урлов, которые я передаю метрике. Я их Метрике передаю, чтобы он мне статистику считал, а не поисковому индексу на публикацию. Это ведь разные сервисы.
P.S. От того, что понижением кармы вы не даете мне отвечать чаще 5 минут, моё мнение не изменится :) Приводите более убедительные аргументы.
P.S. От того, что понижением кармы вы не даете мне отвечать чаще 5 минут, моё мнение не изменится :) Приводите более убедительные аргументы.
Полностью согласен. Яндекс просто взял ПРИВАТНУЮ ссылку из адресной строки броузера (через бар или метрику).
Некоторые пишут, что аутентификация должна быть не по GET, но сие есть полный бред. В будущем никто не помешает тому же скрипту метрики слить Ваш пароль, который вы вводите в форму авторизации. По сути бар.метрика — это трояны, которые кроме выполнения своих основных функций еще и сливают приватную информацию.
В связи с этим еще весной начали переходить на Piwik для сбора статистики по своим проектам. Доверять это стороннему сервису может быть очень опасно!
Некоторые пишут, что аутентификация должна быть не по GET, но сие есть полный бред. В будущем никто не помешает тому же скрипту метрики слить Ваш пароль, который вы вводите в форму авторизации. По сути бар.метрика — это трояны, которые кроме выполнения своих основных функций еще и сливают приватную информацию.
В связи с этим еще весной начали переходить на Piwik для сбора статистики по своим проектам. Доверять это стороннему сервису может быть очень опасно!
Я с вами согласен. Поисковик использовал средства, которые не являются нормальными для сбора урлов. Это больше похоже на шпионаж.
Можете процитировать пункт соглашения, согласно которому вы их передаёте исключительно для подсчёта статистики?
Минусую комменты я крайне редко, если только там открытые оскорбления, а карму, кажется, никогда.
Минусую комменты я крайне редко, если только там открытые оскорбления, а карму, кажется, никогда.
Могу: «Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам»
Ссылка != Сессия
Ну как же — если покупатель посетил одну страницу с данными о заказе, то вся его сессия из этой ссылки и состоит. И см. ниже, там яндекс указывает, что адрес страницы (т.е. ссылка) тоже персональная информация.
И еще, в тексте соглашения ссылка на политику конфиденциальности, в которой к персональным данным яндекс относит в частности: «1.1.2 Данные, которые автоматически передаются Сервисам Яндекса в процессе их использования с помощью установленного на устройстве пользователя программного обеспечения, в том числе IP-адрес, информация из cookie, информация о браузере пользователя (или иной программе, с помощью которой осуществляется доступ к Сервисам), время доступа, адрес запрашиваемой страницы.»
Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные (без привязки к персональным данным посетителей сайта) данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.
Фактически это явное разрешение веб-мастером Яндексу использовать анонимные данные о посещения сайта, в том числе индексировать посещенные страницы.
Ничуть. Явно написано, что для статистики. Никакого индекса, никакой публикации не подразумевается. Под Яндексом здесь имеется в виду не поисковик, а сторона договора, т.е. мою статистику могут смотреть сотрудники яндекса и я. Всё. Никакой сдачи никуда не предусмотрено, что явно указано в политике конфиденциальности.
Как использовать статистику вы Яндекс не ограничиваете. Сотрудники Яндекса смотрят статистику и адреса из неё вбивают в «адд урл». Использование? Использование. Запрещено такое использование соглашением? Нет! Используются персональные данные? Нет! Используются данные статистики: «на сайте 100500 таких-то урлов, 500 таких-то из них посещаются часто, т. к. есть в индексе, а вот 100 000 — по одному разу, добавим-ка мы их в индекс, сделаем вебмастеру приятное, тем более они точно не секретные раз в роботс не запрещены». Соглашением это не запрещено, персональными данными не пахнет
И наконец: «данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.»
Посетители поиска не являются ни Пользователем (вебмастером, установившим Метрику), ни Яндексом.
Посетители поиска не являются ни Пользователем (вебмастером, установившим Метрику), ни Яндексом.
Яндекс использует анонимную статистику о посещениях страниц для предоставления услуг посетителям своего поиска. По-моему, он вправе это делать, в соглашении варианты использования не ограничиваются.
А о разрешении индексации посещенных страниц по-прежнему ничего. Разрешение дается только на статистику.
О, пока мы тут спорим, Яндекс уже решил исправить Метрику (приравняв её к Яндекс.Бару, который по их уверению ссылки не палит) — webmaster.ya.ru/replies.xml?item_no=11122
Забавно, что цитируют они при этом те же пункты соглашения, что и мы здесь разобрали.
В общем, вопрос исчерпан, Яндекс исправился, магазины тоже исправляются, пользователи могут спать спокойнее :)
Забавно, что цитируют они при этом те же пункты соглашения, что и мы здесь разобрали.
В общем, вопрос исчерпан, Яндекс исправился, магазины тоже исправляются, пользователи могут спать спокойнее :)
к тому же adwords имеет трэкинг целей, так что его тоже можно туда отнести, так как устанавливается он как раз там где достигается цель, что может быть страницой с результатом заказа и приватной инфой
Если уж сравнивать, то с Google Analitycs…
Адреса доступны публично? Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так? Или у вас приняты двойные стандарты?
Защитить данные пользователей — ваша забота. Сделать хороший поиск — забота Яндекса.
Вы (или админы сайтов) когда ставили метрику соглашались с лицензионным соглашением? Соглашались. Какие потом вопросы-то?
Защитить данные пользователей — ваша забота. Сделать хороший поиск — забота Яндекса.
Вы (или админы сайтов) когда ставили метрику соглашались с лицензионным соглашением? Соглашались. Какие потом вопросы-то?
> Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так?
Если ЛЮБОМУ, то так. Но шоп выслал секретный URL (как если бы выслал пароль) ОДНОМУ человеку, ни на какой сайт «для всех» этот URL не помещал, а без этого никто бы его «случайно» не подобрал. Т.е. фактически никакого отличия от пароля. И Яндекс, взяв этот URL из адресной строки пользовательского браузера (а не с открытого сайта) выдал его всем.
Точно также он может стащить на пользовательском браузере (яндекс.баром) и параметры POST-запросов, и пароли. И стащит когда-нибудь, если его на первых кражах не остановить.
Если ЛЮБОМУ, то так. Но шоп выслал секретный URL (как если бы выслал пароль) ОДНОМУ человеку, ни на какой сайт «для всех» этот URL не помещал, а без этого никто бы его «случайно» не подобрал. Т.е. фактически никакого отличия от пароля. И Яндекс, взяв этот URL из адресной строки пользовательского браузера (а не с открытого сайта) выдал его всем.
Точно также он может стащить на пользовательском браузере (яндекс.баром) и параметры POST-запросов, и пароли. И стащит когда-нибудь, если его на первых кражах не остановить.
Что такое «секретный URL», в каком стандарте обозначено такое понятие?
URL не может быть секретным, URL не является объектом авторского права, URL не является персональными данными. Равно как и любой другой (IP, адрес дома и др.) адрес.
Исходить нужно их этих предпосылок.
URL не может быть секретным, URL не является объектом авторского права, URL не является персональными данными. Равно как и любой другой (IP, адрес дома и др.) адрес.
Исходить нужно их этих предпосылок.
Все, что прислано мне на email (и больше никуда) являются моими секретными персональными данными. Почтовый клиент тоже мог бы выдавать мои письма яндексу «для более полной индексации», однако он этого не делает. С какой стати мои URL'ы имеют какой-то пониженный приоритет в сравнении с другими словами из той же почты?
Пусть яндекс индексирует то, что его паук найдет по ссылкам на других сайтах. А то, что выдаётся Метрике — выдается только для статистики, доступной только владельцу сайта (такую же статистику он мог бы и из своих секретных логов сервера собирать), а не для индексации и публичного показа.
Пусть яндекс индексирует то, что его паук найдет по ссылкам на других сайтах. А то, что выдаётся Метрике — выдается только для статистики, доступной только владельцу сайта (такую же статистику он мог бы и из своих секретных логов сервера собирать), а не для индексации и публичного показа.
Еще раз — URL не может быть секретным, просто по определению. И понятия «мои URL» в RFC тоже нет.
Все методы авторизации по ссылке в письме основаны на предположении, что адрес это ссылки не знает никто, кроме получателя письма. Это предположение неверно, можно сказать — defected by design. Что в итоге и показали нам поисковики.
Впрочем при уточнениях «ссылка действует в течении X времени» и «ссылка действует только один раз» система авторизации получается достаточно надежно, но кто знает…
Все методы авторизации по ссылке в письме основаны на предположении, что адрес это ссылки не знает никто, кроме получателя письма. Это предположение неверно, можно сказать — defected by design. Что в итоге и показали нам поисковики.
Впрочем при уточнениях «ссылка действует в течении X времени» и «ссылка действует только один раз» система авторизации получается достаточно надежно, но кто знает…
Вы как-то однобоко смотрите на проблему. Давайте на секуду представим, что Яндекс бы вдруг признал свою вину и резко отказался от индексации страниц, поступивших через метрику/бар. А разработчики Shop-Script не писали бы патч, закрывающий страницу заказа хотя бы на фамилию.
Мы бы тогда имели:
1) Отсутвие в выдаче Яндекса страниц с заказами в будущем
2) Знание, что есть некий урл, при переходе на который я получаю некие персональные данные.
Что остановит плохих дядек имея знание о втором пунке от написания своих ботов/пауков, которым глубоко класть как на robots.txt, так и на этику как таковую.
Вам бы понравилась такая ситуация?
Мы бы тогда имели:
1) Отсутвие в выдаче Яндекса страниц с заказами в будущем
2) Знание, что есть некий урл, при переходе на который я получаю некие персональные данные.
Что остановит плохих дядек имея знание о втором пунке от написания своих ботов/пауков, которым глубоко класть как на robots.txt, так и на этику как таковую.
Вам бы понравилась такая ситуация?
1) и нечего им делать в яндексе
2) Каким образом (кроме перебора) плохие дяденьки получат этот самый «секретный» урл? Вот у яндекса таких способа целых два — бар и метрика.
По сути форма авторизации — это тот же самый секретный урл, и передана она по POST или GET для желающих получить Вашу информацию не так уж важно.
2) Каким образом (кроме перебора) плохие дяденьки получат этот самый «секретный» урл? Вот у яндекса таких способа целых два — бар и метрика.
По сути форма авторизации — это тот же самый секретный урл, и передана она по POST или GET для желающих получить Вашу информацию не так уж важно.
2) Прокси/снифер/открытый Wifi, можно еще пяток способов придумать, передавать личные данные пользователя в открытом виде, плохой тон, а передавать их в get запросе это вообще верх маразма.
«Прокси/снифер/открытый Wif» таким же способом может и пароль скушать, особой разницы post или get здесь нет.
Никто не говорит, что разработчик молодец. Но яндекс эту ссылку УКРАЛ и выложил в паблик.
Никто не говорит, что разработчик молодец. Но яндекс эту ссылку УКРАЛ и выложил в паблик.
Каким же интересно образом яндекс УКРАЛ ссылки?:) Веб мастера сами их отдали яндексу, или вы утверждаете, что по подобным ссылкам никто и никогда не вешает другие счетчики? Эти ссылки принесли яндексу на блюдечке с голубой каемочкой, а потом кричат что яндекс их украл :) Классно.
Я вообще не могу себе представить как кому то в голову пришло держать личные данные пользователей в открытом доступе, без банальных методов аундификации, хотя бы как здесь по фамилии, имени, полу, году рождения етк… это вообще не должно укладываться в голове у любого нормального итишника.
Я вообще не могу себе представить как кому то в голову пришло держать личные данные пользователей в открытом доступе, без банальных методов аундификации, хотя бы как здесь по фамилии, имени, полу, году рождения етк… это вообще не должно укладываться в голове у любого нормального итишника.
Если в соглашении явно написано о том, что все ссылки индексируется, вопросов нет. Но я такого пункта там не нашел.
А там явно написано, что она не будет индексироваться? Передача любого адреса (в том числе урла) предполагает, что по этому адресу тот, кому его передали, может спокойно обратиться: ответят-не ответят, пустят-не пустят, пошлют-не пошлют, выдадут 200 и инфу или 401/403 и предложение аутентифицироваться — дело владельца даже не адреса (адрес это чистой воды информация), а ресурса, на который этот адрес указывает.
А вот это уже довольно скользкий момент. Через прокси сервера тоже проходят кучи урлов…
RFC не рекомендует передавать «чувствительные» данные через GET-формы.
Я в прошлом топике описывал метод компроментаци таких урлов через referer.
Например, вам на почту пришла секретная ссылка, по которой вы можете посмотреть список заказов. Вы заходите в список заказов и оттуда переходите на страницу какой-нибудь заказанной вами вещи. Вполне реальная ситуация, правильно?
Теперь все скрипты на этой странице (товара) знают вашу секретную ссылку через document.referer. Думаю не надо объяснять что кроме метрики часто владельцы магазинов вставляют еще разные скрипты от рекламодателей и т. д.
Кто будет гарантировать что рекламодатель не плохой дядька который купил рекламу только ради того чтобы тырить секретные урлы пользователей сервиса?
Например, вам на почту пришла секретная ссылка, по которой вы можете посмотреть список заказов. Вы заходите в список заказов и оттуда переходите на страницу какой-нибудь заказанной вами вещи. Вполне реальная ситуация, правильно?
Теперь все скрипты на этой странице (товара) знают вашу секретную ссылку через document.referer. Думаю не надо объяснять что кроме метрики часто владельцы магазинов вставляют еще разные скрипты от рекламодателей и т. д.
Кто будет гарантировать что рекламодатель не плохой дядька который купил рекламу только ради того чтобы тырить секретные урлы пользователей сервиса?
Далеко не все магазины вешают на такие страницы баннеры и прочие внешние скрипты. И если таковых нет, то сам механизм «секретной» ссылки безопасен (приведите пример компроментации, если не согласны с этим аргументом). Но скрипт на странице был и им оказалась Яндекс метрика.
Если клиент ходит в сеть через прокси, то прокси имеет доступ к подобным ссылкам. Но так же прокси может сохранять и POST запросы. Поэтому единственным надежным решением будет https
Если клиент ходит в сеть через прокси, то прокси имеет доступ к подобным ссылкам. Но так же прокси может сохранять и POST запросы. Поэтому единственным надежным решением будет https
Далеко не все магазины вешают на такие страницы баннеры и прочие внешние скрипты
С этим не согласен — на страницы товара и другие страницы сайта всякие баннеры вешают довольно часто.
А я и не говорил что на страницу просмотра заказа (с секретным url) кто-то что-то вешает. Я говорю если человек со страницы просмотра заказа переходит по прямой ссылке на страницу товара, да даже просто на главную страницу магазина — «секретная» ссылка будет видна в document.referer всем банерам и остальному контенту, размещенному на главной странице магазина или странице товара
Такой софт и пишут. Трояны называется. Жалко в данной истории яндекс сам выступает трояном :(
А быстрое удаление из индекса данных об смс — это признание чужой вины?
Пауки не найдут эти секретные урлы без помощи Метрики, т.к. этих секретных урлов нет нигде кроме почтовых сообщений.
Разработчики шопа тоже виноваты, конечно, но это не отменяет вины Яндекса, спалившего урлы, которые были предназначены для статистики, а не для индексации и публикации.
Разработчики шопа тоже виноваты, конечно, но это не отменяет вины Яндекса, спалившего урлы, которые были предназначены для статистики, а не для индексации и публикации.
Да и вообще, я думаю, что будь такое в Америке, там бы уже гугл местный бы последние портки бы продавал чтобы выплаты по искам раздать
Там владельцы сайтов бы последнее продавали…
По крайней мере, «гугл местный» постарался бы избавиться от персональных данных в своей базе. Какой скандал поднялся, когда обнаружилось, что Гугл собирает данные по открытым (!) точкам вай-фая с помощью своих гугломобилей. И гугл пообещал так больше не делать и удалить собранные персональные данные.
А Яндекс может себе позволить посмеиваться — «обнаружили, что можно искать» — над глупыми людишками, у которых персональные данные оказались в публичном доступе.
Две ситуации: персональные данные в общем доступе. Два подхода: этичный и неэтичный.
А Яндекс может себе позволить посмеиваться — «обнаружили, что можно искать» — над глупыми людишками, у которых персональные данные оказались в публичном доступе.
Две ситуации: персональные данные в общем доступе. Два подхода: этичный и неэтичный.
единственный нормальный вопрос за весь топик. сразу видно что вы детально проработали ситуацию.
специально для глубоко вдумчивых профессионалов отвечаю на ваш вопрос:
сужающие смазки -это такие которые повышают трению и способствуют сужению пилотного входа так сказать путем стимулирования оттока крови от наружнго шлюза…
и не спрашивайте откуда я это знаю.
специально для глубоко вдумчивых профессионалов отвечаю на ваш вопрос:
сужающие смазки -это такие которые повышают трению и способствуют сужению пилотного входа так сказать путем стимулирования оттока крови от наружнго шлюза…
и не спрашивайте откуда я это знаю.
А почему вы куки какие-нибудь особые не можете класть клиенту, когда он оформляет заказ, а потом, когда приходит по get-запросу на сайт, проверять их? Конечно, он может зайти из другого браузера/компьютера, и вот тогда вы можете просить вбить пароль/фамилию/и тп. То есть в типичном случае пользователю не придется ничего вводить.
Еще идея: по ссылке отправлять пользователя на промежуточную страницу, с простеньким яваскриптом, который будет к исходному урлу дописывать какой-нибудь маркер (и оставлять хэш), а потом перенаправлять на страницу заказа. И уже на странице заказа вы будете проверять этот маркер. Тогда, когда бот будет индексировать исходный линк, яваскрипт не сработает, страница заказа маркер не прочитает и бота не пустит). Это решение вообще без ограничений, кажется.
Еще идея: по ссылке отправлять пользователя на промежуточную страницу, с простеньким яваскриптом, который будет к исходному урлу дописывать какой-нибудь маркер (и оставлять хэш), а потом перенаправлять на страницу заказа. И уже на странице заказа вы будете проверять этот маркер. Тогда, когда бот будет индексировать исходный линк, яваскрипт не сработает, страница заказа маркер не прочитает и бота не пустит). Это решение вообще без ограничений, кажется.
Сначала пользователеь переходит mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, его авторизует скрипт и пересылает на mysexshop.com/order/4222
да, это похожая схема, но не такая же. И, судя по этому описанию, с недостатками.
Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.
Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.
То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.
Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.
То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
Пропустил ваш комментрарий. Сразу пришла та же мысль на счёт кук. C javascirpt — хорошая идея.
Разработчики Shop-script, примите во внимание.
Разработчики Shop-script, примите во внимание.
Проще (и надёжнее) отправлять на страницу с формой из одной кнопки «Нажмите эту кнопку, если вы не поисковый робот», отправляющей POST-запрос. Их поисковики не отрабатывают, насколько мне известно.
Им ничто не запрещает их начать обрабатывать. А вот Meta robots и robots.txt — вполне проверенные решения.
В принципе им также ничто не мешает игнорировать мета и роботс…
Для чего? У Яндекса нет цели выведать какой фаллоимитатор вы купили накануне, его цель — предсотавить максимально широкий и релевантный поиск. Если страница не должна находиться в поиске, то нет резона ее туда включать.
Мне казалось цель Яндекса (как и любого ООО) — зарабатывать деньги :)
Да. Только если яндекс начнет обрабатывать все подряд, не учитывая robots.txt и прочие способы указать, что индексировать, а что нет, то его сервисами — метрикой, яндекс баром, и прочим перестанут пользоваться, и яндекс начнет эти деньги терять. И авторитет он тоже начнет терять. А он еще на IPO вышел, акции же могут падать.
Вот потому он не будет обрабатывать и пост-запросы своим баром, хотя возможность, вроде бы, есть, даже по https.
Так как он встроен в браузер, конечно есть возможность.
И кстати говоря, способов запретить считывать определенные страницы куча. Например выдавать обфусцированный код, который будет собираться JavaScript'ом, использовать капчу, делать проверки, бот это или нет. После перехода по ссылке ставить куку(бот куки не принимает и не отправляет, как я полагаю), и редиректить на страницу заказа, которая будет доступна только при наличии именно этой куки с определенным значением. Можно придумать кучу способов. Но все же самый простой — robots.txt.
А еще яндекс метрика вдруг может начать брать все содержимое страницы и отправлять постом в яндекс, мало ли? Это же JS, подгружаемый на Вашу страницу.
Просто нужно четко разделять зоны безопасности на сайте, и использовать разный подход. В общем, заботиться о своих пользователях.
И кстати говоря, способов запретить считывать определенные страницы куча. Например выдавать обфусцированный код, который будет собираться JavaScript'ом, использовать капчу, делать проверки, бот это или нет. После перехода по ссылке ставить куку(бот куки не принимает и не отправляет, как я полагаю), и редиректить на страницу заказа, которая будет доступна только при наличии именно этой куки с определенным значением. Можно придумать кучу способов. Но все же самый простой — robots.txt.
А еще яндекс метрика вдруг может начать брать все содержимое страницы и отправлять постом в яндекс, мало ли? Это же JS, подгружаемый на Вашу страницу.
Просто нужно четко разделять зоны безопасности на сайте, и использовать разный подход. В общем, заботиться о своих пользователях.
Что нужно заботиться — полностью согласен. В последних событиях (неделя Яндекса не то, что на Хабре или даже в Рунете, а в масштабах страны — про фэйл Мегафона в газетах уже читал) владельцы сайтов явно не позаботились… Паранойя про чтение браузером или его сторонними расширениями данных post-запросов https сессий и передачей их куда-то на сторону — это одно, выкладывать конфиденциальные данные по публично доступной (даже ботам!) ссылке — совсем другое.
Эти данные не были публично доступны ботам, пока метрика не стащила секретный URL в пользовательском браузере.
Она (метрика) конечно не могла не узнать этот URL из реферера (и админ шопа ей это явно разрешил), но вовсе не должна была этот URL включать в общий индекс. Пауки пауками, а метрика метрикой. Паук не нашел бы этот URL, т.к. его нет нигде кроме письма у пользователя.
Если я начну перечислять в своих robots.txt все секретные каталоги своего сервера (на всякий случай уж), то яндес-роботов это может и отвадит, зато других роботов наоборот привадит именно туда!
P.S. Есть еще один способ «сдачи» поисковикам секретных URL'ов, даже если там нет никакой метрики — рефереры. Если на секретной страничке была ссылка на другой сайт, то пользователь може туда сходить с выдачей этому сайту своего секретного урла. А если например статистика рефереров того сайта открыта, то роботы доберутся до секретной страницы и без метрики. Т.е. там должна быть зашита, даже если метрики нет (поэтому, кстати, трюк с редиректом не очень-то надежно поможет). Поэтому безусловная виновность яндекса не означает, что авторы шоп-скрипта не виновны. Они тоже виновны, но яндекс больше :)
Она (метрика) конечно не могла не узнать этот URL из реферера (и админ шопа ей это явно разрешил), но вовсе не должна была этот URL включать в общий индекс. Пауки пауками, а метрика метрикой. Паук не нашел бы этот URL, т.к. его нет нигде кроме письма у пользователя.
Если я начну перечислять в своих robots.txt все секретные каталоги своего сервера (на всякий случай уж), то яндес-роботов это может и отвадит, зато других роботов наоборот привадит именно туда!
P.S. Есть еще один способ «сдачи» поисковикам секретных URL'ов, даже если там нет никакой метрики — рефереры. Если на секретной страничке была ссылка на другой сайт, то пользователь може туда сходить с выдачей этому сайту своего секретного урла. А если например статистика рефереров того сайта открыта, то роботы доберутся до секретной страницы и без метрики. Т.е. там должна быть зашита, даже если метрики нет (поэтому, кстати, трюк с редиректом не очень-то надежно поможет). Поэтому безусловная виновность яндекса не означает, что авторы шоп-скрипта не виновны. Они тоже виновны, но яндекс больше :)
Вы это Руперту Мёрдоку расскажите, а то он не в курсе.
Мешает. POST-форма может совершать критичные действия — удалять что-либо и так далее. И вообще, как вы себе это представляете: пришёл бот Яндекса и накрутил голосование? Оставил комментов? Зарегистрировал аккаунт? Подписался на рассылку?
Ну вообще говоря, яндекс-бар может(?) передать ботам яндекса, а те использовать, логин и пароль с целью проиндексировать содержание личной переписки для более полного и релевантного поиска :)
Будите смеятся, yandex проидексировал у меня post форму, примитивную конечно (по сколько на странице показвать результатов), но проиндексировал. Теперь в результатах полный бред, так как он проиндексировал все параметры, вы представялете? В индексе теперь фактически одинаковые страницы с разным кол-вом результатов на странице.
Это конечно не есть хорошо. Скоро и на рассылку подпишется :)
(кстати google такой фигней не страдает, пока)
Это конечно не есть хорошо. Скоро и на рассылку подпишется :)
(кстати google такой фигней не страдает, пока)
Почему находится всё: ответ Яндексу от разработчиков Shop-Script