Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Разные веб-сервера шлют дату в разных форматах, иногда не в стандартных. Соответственно браузерам нужно под их формати подстраиватся, а это не только геморно но и не всегда возможно (т.к. для одной строки могут подходить больше одного стандарта). Думаю проблемку нужно на уровне спецификация протокола решать…
Спека, правда, уже говорит об этом:
А HTTP-date обозначен тут: www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
То есть, в теории, все уже заспецифицировано и запротоколировано по самое не хочу. Но как всегда, все на спецификации глубоко наплевать :)
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
Last-Modified = "Last-Modified" ":" HTTP-date
А HTTP-date обозначен тут: www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
То есть, в теории, все уже заспецифицировано и запротоколировано по самое не хочу. Но как всегда, все на спецификации глубоко наплевать :)
HTTP-date допускает три разных формата, плюс время указывается с точностью до секунды, итого в одних сутках содержится 259 200 различных уникальных идентификаторов. Учитывая, что на реальное значение Last-modified нам плевать, и мы можем хоть прошлый год там выставить — ситуация не намного лучше, чем с произвольной строкой.
Это тоже верно. Как автор и указал, это — только частичное решение, а полного, увы, нет
Ну, можно в некоторых разумных пределах fuzzing поля делать.
15 секунд туда-сюда при каждом запросе. Чем более старая дата — тем больше допустимая амплитуда отклонения.
Процент ложных запросов мимо кеша вырасти особо не должен в подавляющем большинстве случаев, а у идентификации возникнут очевидные проблемы.
15 секунд туда-сюда при каждом запросе. Чем более старая дата — тем больше допустимая амплитуда отклонения.
Процент ложных запросов мимо кеша вырасти особо не должен в подавляющем большинстве случаев, а у идентификации возникнут очевидные проблемы.
Браузер должен парсить дату чтобы определить формат используемый сервером, а потом в If-modified-since выставлять её по системным часам клиента, а не тому что отдал сервер. :]
И чем это усложняет идентификацию?
Действительно, чем усложнит идентификацию тот факт, что мы выдаём клиенту один идентификатор, а он возвращается с другим?
Если мы указываем часовой пояс, то ничего не изменилось — конвертнули в нужное время, получили тот же токен.
Если мы не указываем часовой пояс, то рушим работу с нормальными серверами.
Если мы не указываем часовой пояс, то рушим работу с нормальными серверами.
У меня два предположения, что вы подразумеваете под фразой «выставлять её по системным часам клиента»: либо менять часовой пояс, либо посылать текущее время. Второй случай не несет в себе смысла.
Цитата> Метод, основанный на ETag'ах работает не всегда, особенно если на пути стоят web-проки, а вот метод, основанный на Last-Modified срабатывает всегда. <Цитата
Нет, тоже не всегда. Только что проверил — мой прокси в запросе If-Modified-Since указывает тот момент времени, когда он поместил этот объект в кэш, а не ту строку, которую сервер выдавал в тот момент.
Нет, тоже не всегда. Только что проверил — мой прокси в запросе If-Modified-Since указывает тот момент времени, когда он поместил этот объект в кэш, а не ту строку, которую сервер выдавал в тот момент.
Занятно, спасибо за перевод.
В Опере пример не работает, Last-Modified не ставится.
Как-то сомнительно использование этого трюка для идентификации, ведь браузер пошлет If-Modified-Since только на тот же самый url, на другие он слать не будет.
Как-то сомнительно использование этого трюка для идентификации, ведь браузер пошлет If-Modified-Since только на тот же самый url, на другие он слать не будет.
В Эксплорере тоже. «Срабатывает во всех основных браузерах» вызывает сомнение.
Трюк нужен для сайтов, ставящих отслеживающие куки. То есть достаточно поставить img href=«tracker-site/url/», чтобы получать информацию о том, куда и как ходит пользователь
А как вы получите информацию, куда он ходит? По рефереру?
Можно по рефереру. Можно по дополнительному токену в url'е.
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.
И кто же будет менять этот url?
Вы, раз собираетесь в url добавлять токен с информацией о текущей странице.
Блин. Я захожу на страницу site.url, на нем есть
<img url="site2.url">. site2.url и есть сайт, который отслеживает ваши перемещения. Что и как вы собираетесь менять?Как он отслеживает перемещения? Каким образом, кроме реферера, он может узнать, на какой странице стоит тег
<img url="site2.url">? Вы упомянули про тукен в url, где он здесь?Что ему мешает узанть из referer'а?
Что мешает автору сайта site1.url добавить токен в урл?
Какой это отношение имеет к вопросу «И кто же будет менять этот url?»?
Что мешает автору сайта site1.url добавить токен в урл?
Какой это отношение имеет к вопросу «И кто же будет менять этот url?»?
> Что ему мешает узанть из referer'а?
Ничего не мешает узнать по рефереру, просто вы упомянули второй способ, который я у вас выпытываю.
> Что мешает автору сайта site1.url добавить токен в урл?
В какой url? В site2.url?
Ничего не мешает узнать по рефереру, просто вы упомянули второй способ, который я у вас выпытываю.
> Что мешает автору сайта site1.url добавить токен в урл?
В какой url? В site2.url?
Да. В site2.url.
Начнем с начала.
Вы — пользователь. Вы открыли бразуер по адресу site.url, на нем есть
Без разницы, что находится в site2.url.
Вы задаете вопрос:
Кто будет менять этот самый site2.url?
Начнем с начала.
Вы — пользователь. Вы открыли бразуер по адресу site.url, на нем есть
<img url="site2.url">. site2.url и есть сайт, который отслеживает ваши перемещенияБез разницы, что находится в site2.url.
Вы задаете вопрос:
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.
Кто будет менять этот самый site2.url?
Дальше, пожалуйста. «Xтобы получать информацию о том, куда и как ходит пользователь». Я захожу на site.url/info/, что там?
Блин. Такое ощущение, что я разговариваю со стенкой.
Заходите туда, там есть страница, на которой в самом низу есть картинка размером 1x1, которая берется с сайта site2.url. Хоть с токеном, хоть без токена — без разницы.
Дальше. Куда применять ваше
?
Заходите туда, там есть страница, на которой в самом низу есть картинка размером 1x1, которая берется с сайта site2.url. Хоть с токеном, хоть без токена — без разницы.
Дальше. Куда применять ваше
В том то и дело — изменяем url, браузер больше не шлет If-Modified-Since.
?
Ага, в данном случае стенка — вы.
Если адрес картинки на сайте site2.url будет точно такой-же как на странице site.url/, то сайт site2.url получит возможность идентифицировать пользователя, но он никак не узнает, на какую страницу попал пользователь. Все что он сможет сказать — сколько раз каждый пользователь дернул url.
Если же мы передаем в url для site2.url какой-то тукен с зашифрованных url первого сайта, то site2 сможет сказать, какие урлы открывались на первом сайте. Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.
Если адрес картинки на сайте site2.url будет точно такой-же как на странице site.url/, то сайт site2.url получит возможность идентифицировать пользователя, но он никак не узнает, на какую страницу попал пользователь. Все что он сможет сказать — сколько раз каждый пользователь дернул url.
Если же мы передаем в url для site2.url какой-то тукен с зашифрованных url первого сайта, то site2 сможет сказать, какие урлы открывались на первом сайте. Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.
> но он никак не узнает, на какую страницу попал пользователь
referer'ы у нас уже отменили?
> Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.
это тож решаемо. Более того, полезно для сбора статистики
referer'ы у нас уже отменили?
> Но вот беда, он не сможет определить, один и тот-же это был пользователь, или нет, потому что урлы-то разные.
это тож решаемо. Более того, полезно для сбора статистики
ах. и да. url/ и url/?token=xxxx — это один и тот же URL
?
OMG!
dmitriid> Трюк нужен… чтобы получать информацию о том, куда… ходит пользователь
homm> А как вы получите информацию, куда он ходит?
dmitriid> по дополнительному токену в url'е
homm> В том то и дело изменяем url, браузер больше не шлет If-Modified-Since — а это, по мнению homm`а противоречит Вашему первому утверждению! После чего, как я понимаю, Вы полностью запутались выясняя что и как
dmitriid> Трюк нужен… чтобы получать информацию о том, куда… ходит пользователь
homm> А как вы получите информацию, куда он ходит?
dmitriid> по дополнительному токену в url'е
homm> В том то и дело изменяем url, браузер больше не шлет If-Modified-Since — а это, по мнению homm`а противоречит Вашему первому утверждению! После чего, как я понимаю, Вы полностью запутались выясняя что и как
Бл*ть.
КТО будет изменять URL?
КТО будет изменять URL?
Вы — пользователь. Вы открыли бразуер по адресу site.url, на нем есть . site2.url и есть сайт, который отслеживает ваши перемещения
Без разницы, что находится в site2.url.
Кто будет менять этот самый site2.url?
> site2.url и есть сайт, который
> отслеживает ваши перемещения
Как он их отслеживает без реферера? Как он для этого использует упомянутый вами токен?
> отслеживает ваши перемещения
Как он их отслеживает без реферера? Как он для этого использует упомянутый вами токен?
http://site2/url?token="/any/token/" |________1______||_________2_______|
1 = RFC 3986. Uniform Resource Identifier. Section 3.3. Path
2 = токен
Вы уже бред несете.
> referer'ы у нас уже отменили?
Но вы же хотели рассказать способ без реферерров!!!111
Но вы же хотели рассказать способ без реферерров!!!111
> это тож решаемо.
Но решаемо не с помощью уязвимости, о которой вы сделали перевод. Да?
Но решаемо не с помощью уязвимости, о которой вы сделали перевод. Да?
На site1.com/page1 стоит картинка 'site2.com/tracker.png?urlhash=' +md5('site1.com/page1'). Так мы будем знать и куда конкретно заходил, а не только факт захода.
Ну и каким макаром в запрос на адрес
'site2.com/?'+md5('/page1') попадет заголовок If-Modified-Since из заголовка ответа Last-Modifed от запроса на 'site2.com/?'+md5('/page2'), если это разные урлы?
'site2.com/?'+md5('/page1') попадет заголовок If-Modified-Since из заголовка ответа Last-Modifed от запроса на 'site2.com/?'+md5('/page2'), если это разные урлы?
В первый раз сервер установит «этот клиент первый раз посетил эту страницу», а во второй уже можно будет отслеживать сколько раз он её посещал, а если будет уходить и на другие уже посещенные страницы, то и маршруты отслеживать. Не столь универсально как куки, токены и реферы, но лучше чем ничего, если клиент параноидальный и всё это отключил, а про кэш забыл.
а если будет уходить и на другие уже посещенные страницы, то и маршруты отслеживатьКак? Нет — КАК??!!! У вас не будет данных, что человек, зашедший по md5('/page1') и md5('/page2') — один и тот же, или это разные люди. Браузер не пошлет заголовки одного адреса по другому.
Я допускаю, что я чего-то очевидного в упор не замечаю, но что-то пока никто на это очевидное указать не может.
Да, тут я что-то ступил. Параметры в URL являются тоже частью «идентификатора» ресурса (в отличии от якоря). Отслеживать получится только как часто какой-то пользователь возвращается на конкретную страницу, но он ли посещает соседнюю страницу сказать нельзя будет без анализа других заголовков и служебной инфы типа айпишника.
это — не разные URL'ы. Читайте спеки, они рулят.
Парсер съел собки, поэтому приведу-ка я:
После чего надо все же читать про URI тут: tools.ietf.org/html/rfc3986 особенно секцию 3.3 path:
An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
После чего надо все же читать про URI тут: tools.ietf.org/html/rfc3986 особенно секцию 3.3 path:
The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.
Если браузер очищает кеш после закрытия, то и заголовки эти отправлять нет смысла.
Заголовок «Cache-Control: no-cache» заставляет фаерфокс и хром не отсылать If-Modified-Since и If-None-Match. В других браузерах не проверял.
вот все почему-то думают, что это плохо, один я не понимаю, почему, и как разработчик веб-приложений мне очень надо возможность отслеживать посетителей. в том числе и для того, чтобы этим же посетителям сделать жизнь на сайте лучше и комфортнее.
Благими намерениями выстлана дорога в… индекс Яндекса и Гугла :)
капитан подсказывает, что решение, отслеживать себя или нет, должен принимать все-таки пользователь
вам же в реале не понравилось бы, если бы за вами по пятам ходил дядька и записывал все, что вы делаете, пусть даже вам от этого была какая-то польза?
вам же в реале не понравилось бы, если бы за вами по пятам ходил дядька и записывал все, что вы делаете, пусть даже вам от этого была какая-то польза?
Известный гик Chris Siebenmann ответил на это в своём блоге:
I feel that changing Last-Modified is basically impossible for the browser to do in a way that is both safe and useful.
Обновите статью. На автора исследования никто иск не подавал — Смотреть «Note» внизу статьи.
Кстати… а сами сервера парсят даты? Или просто формируют новую строку для Last-Modified и сравнивают её на равенство с переданной клиентом?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Постоянные неблокируемые cookie с использованием HTTP-заголовков