Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
В такой большой статье нужна картинка для привлечения внимания
Открою маленький секрет.
Можно эмулировать работу настоящего браузера при помощи Selenium :)
Можно эмулировать работу настоящего браузера при помощи Selenium :)
Прошу прощения, может не совсем вник в суть проблемы, но что мешало между вызовами CURLOPT_COOKIEFILE и CURLOPT_COOKIEJAR сделать fwrite и дописать в файл необходимые куки?
JavaScript (или non-HTTP) cookies
Сам придумал?
Я долго искал упоминание про это. Уж думал, что что-то пропустить успел в этой жизни.
я прошу прощения за то что ввел всех в заблуждение этим термином. но я не знал как это назвать по другому, не заморачиваясь. а какой термин вы предложили бы в этом случае?
Если развернуто, то это кукисы устанавливаемые веб-приложением на стороне клиента.
Вообще-то я просил указать термин, а не определение. К тому же ваше определение неверное по сути: куки в любом случае устанавливаются на стороне клиента. Если уж давать определение, то имхо лучше всего подойдет такое: non-HTTP (или JavaScript) cookies устанавливаются во время загрузки содержимого веб-страницы (чаще всего через JavaScript), тогда как HTTP cookies — во время чтения/парсинга HTTP-заголовка ответа.
Это как же кукисы устанавливаются в любом случае на стороне клиента? Разве не для того нужна функция setcookie, чтобы установить их на стороне сервера? Или вы хотите сказать что, если вы пишите http-клиент на питоне, то он использует python-cookie, java — java-cookie, а c++ — cpp-cookie? А сервер использует php-cookies? Суть лишь в том, что эти кукисы необходимы, для корректной работы приложения, но устанавливаются клиентом, а не сервером, хотите термин, пожалуйста — client defined cookies.
Просто мы с вами говорим на разных языках, потому и не понимаем друг друга. Я привык считать, что если говорят «устанавливается на чем-то», то это «что-то» обозначает цель, а не источник. В этом смысле ваше определение неверно, т.к. целью (местом хранения) cookies всегда является клиент, а источником — сервер.
HTTP — транспортный протокол, он вообще ничего не устанавливает, лишь передает от клиента, серверу.
Cookie — технология хранения данных на клиенте. Кукисы могут устанавливать как клиент, так и сервер.
non-HTTP — обычно называются средства передачи каких-либо данных с помощью недокументированных заголовков, либо использующиеся поверх HTTP-протокола (заверните JSON в заголовок X-JSON-COOKIE, разверните на клиенте, вот вам non-HTTP).
Создать кукис вы можете хоть с помощью js, хоть из консоли ручками. Вы все-равно будете использовать HTTP для их передачи. Серверу все равно как вы установили кукис, главное что пришел он в корректном виде в соответствующем HTTP-заголовке.
Так что не вводите людей в заблуждение, новыми терминами, смысл которых сами придумали, да еще из непонимания технологии.
Cookie — технология хранения данных на клиенте. Кукисы могут устанавливать как клиент, так и сервер.
non-HTTP — обычно называются средства передачи каких-либо данных с помощью недокументированных заголовков, либо использующиеся поверх HTTP-протокола (заверните JSON в заголовок X-JSON-COOKIE, разверните на клиенте, вот вам non-HTTP).
Создать кукис вы можете хоть с помощью js, хоть из консоли ручками. Вы все-равно будете использовать HTTP для их передачи. Серверу все равно как вы установили кукис, главное что пришел он в корректном виде в соответствующем HTTP-заголовке.
Так что не вводите людей в заблуждение, новыми терминами, смысл которых сами придумали, да еще из непонимания технологии.
Имхо «non-HTTP cookies» — самый подходящий для данного случая термин. Он и встречается в тексте поста.
HTTP Заголовки можно смотреть в фаербаге.
JavaScript cookies — вы так говорите, будто серверу есть разница каким образом пользователь получил их, через Javascript или нет.
Вы так говорите, словно уверены что владеете вопросом лучше автора, при этом поленившись даже проверить в гугле свою собственную компетентность. В целях повышения безопасности можно действительно разрешить лишь http only cookie, www.php.net/manual/en/function.setcookie.php
Серверу всё равно откуда получены куки. А опция, про которую вы говорите, для браузеров.
Данный флаг отсылается СЕРВЕРОМ, значит серверу таки " есть разница каким образом пользователь получил их, через Javascript или нет". Ну, а верификацию изменения кук можно делать двумя строчками кода.
if ($_SEESION['cookieCheck'] != $_COOKIE) die('bla bla'); проверяем.
$_SEESION['cookieCheck'] = $_COOKIE; привязываем к сессии. (сессии, как известно могут быть не только на куках)
if ($_SEESION['cookieCheck'] != $_COOKIE) die('bla bla'); проверяем.
$_SEESION['cookieCheck'] = $_COOKIE; привязываем к сессии. (сессии, как известно могут быть не только на куках)
Серверу нет разницы откуда пользователь взял куку, что ему прислали то и принял. А флаг httponly лишь не дает доступ к куки с ява-скрипта. Вот.
я привёл пример каким образом сервер может попросить клиента не трогать куки и код, который позволяет серверу не обрабатывать запрос с модифицированной кукой.
Да, браузер может вовсе не поддерживать данной технологии, да, запрос можно сформировать руками, но я программист или где? Я могу на сервер сайд коде проверить модификацию данных и блочить негодяев.
Да, браузер может вовсе не поддерживать данной технологии, да, запрос можно сформировать руками, но я программист или где? Я могу на сервер сайд коде проверить модификацию данных и блочить негодяев.
Зачем отсылать в куках данные, которые лежат в сессии?
Какое отношение ваш вопрос имеет к тезису habrahabr.ru/blogs/php/133191/?reply_to=4420881#comment_4420609
Если интересно, то этот приём я использовал когда делал сессии в обход стандартного php обработчика сессий, просто хранил данные в шифрованной сессии, а для контроля модификаций дополнительно ставили куку с чексумой. Часть скриптов проекта была на си и perl, так что техника была вынужденной мерой.
Если интересно, то этот приём я использовал когда делал сессии в обход стандартного php обработчика сессий, просто хранил данные в шифрованной сессии, а для контроля модификаций дополнительно ставили куку с чексумой. Часть скриптов проекта была на си и perl, так что техника была вынужденной мерой.
Хорошо.
Покажите мне разницу между проведениями вашего приложения, при получении запроса от пользователя, в следующих случаях:
а. у кук пользователя флаг httponly = true
б. у кук пользователя флаг httponly = false
Покажите мне разницу между проведениями вашего приложения, при получении запроса от пользователя, в следующих случаях:
а. у кук пользователя флаг httponly = true
б. у кук пользователя флаг httponly = false
Выше я показывал пример, просто запрещал доступ к функционалу, если куки изменены. А флаг позволяет защититься от случайных кук на клиенте, которые могут поставить js скрипты.
Переформулирую вопрос, на этот вопрос надо ответить «Да» или «Нет»: ведёт ли себя сервер по-разному в выше перечисленных случаях? Да/Нет
Вы занимаетесь софистикой и меняете тему обсуждения. Я отвечаю на тезис на который изначально писал коментарий.
>>вы так говорите, будто серверу есть разница каким образом пользователь получил их, через Javascript или нет.
Ответ однозначен. ДА, для сервера может иметь большую разницу каким образом пользователю установлена кука. А то что в серверном языке имеется специальная опция, показывает что это не только моя фантазия.
>>вы так говорите, будто серверу есть разница каким образом пользователь получил их, через Javascript или нет.
Ответ однозначен. ДА, для сервера может иметь большую разницу каким образом пользователю установлена кука. А то что в серверном языке имеется специальная опция, показывает что это не только моя фантазия.
Погодите. Вы высказали мысль. В качестве доказательства вы привели пример, используя его как аргумент в пользу своего довода.
Я, в свою очередь, пытаюсь показать, что ваш пример как раз и иллюстрирует наш довод: «серверу всё равно как куки попали». Поясню почему я так думаю:
Что сделает сервер, если получит куки, которые сформированы ява скриптом? — Проверит их валидность.
Что сделает сервер, если получит куки, которые пользователь отправил вручную? — Проверит их валидность.
Что сделат сервер, если получит куки, которые отправлял сам до этого?
— Проверит из валидность.
Т.е. как бы куки не были сформированы они будут обработаны одинаково.
Может ли сервер различить то как были установлены куки (вручную, ява скриптом или действительно пришли с сервера)? — Нет.
Таким образом Ваш пример и показывает, что «Серверу всё равно как были сформированы куки».
Я, в свою очередь, пытаюсь показать, что ваш пример как раз и иллюстрирует наш довод: «серверу всё равно как куки попали». Поясню почему я так думаю:
Что сделает сервер, если получит куки, которые сформированы ява скриптом? — Проверит их валидность.
Что сделает сервер, если получит куки, которые пользователь отправил вручную? — Проверит их валидность.
Что сделат сервер, если получит куки, которые отправлял сам до этого?
— Проверит из валидность.
Т.е. как бы куки не были сформированы они будут обработаны одинаково.
Может ли сервер различить то как были установлены куки (вручную, ява скриптом или действительно пришли с сервера)? — Нет.
Таким образом Ваш пример и показывает, что «Серверу всё равно как были сформированы куки».
Я думаю вам стоит почитать не только про куки, а и как вообще идет обмен в http протоколе, потом закурить и подумать.
И ещё вопрос:
Я злостный извращенец. Мне открылась страница, я удалил все куки, потом написал скрипт, которые создаёт эти же куки с такими же значениями. Затем я отправил всё на сервер. Приложение просто проверит контрольную сумму как и всегда или будет вести себя по-другому?
Я злостный извращенец. Мне открылась страница, я удалил все куки, потом написал скрипт, которые создаёт эти же куки с такими же значениями. Затем я отправил всё на сервер. Приложение просто проверит контрольную сумму как и всегда или будет вести себя по-другому?
Установка данного флага, грубо говоря, делается «для красоты» (или для того, чтобы у пользователя не смогли украсть эти куки). Т.е. установка такого флага сама по себе является указателем для браузера и только (и то не для всех — по словам документации).
Такое поведение сравнимо с тем, что мы для текстового поля установили максимальную длину в 10 символов(/>). Да, браузер не даст вводить больше, но при получении данных с браузера серверу будет всё равно какой он там атрибут отослал в тэге. Если, конечно, не будет дополнительных проверок, которые и будут фактически ограничивать что-то.
Кстати, по поводу дополнительных проверок. Вы сделали хранение данных сессии в куках, но, чтобы проверить, что они те, что были Вы храните их в сессии.…
P.S. опция httponly — не для того, чтобы куку не могли изменить, а скорее для того, чтобы куку не могли украсть.
Такое поведение сравнимо с тем, что мы для текстового поля установили максимальную длину в 10 символов(/>). Да, браузер не даст вводить больше, но при получении данных с браузера серверу будет всё равно какой он там атрибут отослал в тэге. Если, конечно, не будет дополнительных проверок, которые и будут фактически ограничивать что-то.
Кстати, по поводу дополнительных проверок. Вы сделали хранение данных сессии в куках, но, чтобы проверить, что они те, что были Вы храните их в сессии.…
P.S. опция httponly — не для того, чтобы куку не могли изменить, а скорее для того, чтобы куку не могли украсть.
Скорее всего вы ошиблись топиком.
Скорее всего я ошибся ресурсом, всё никак не привыкну, что на хабре не положено говорить на технические темы, а в комментариях нужно либо лажать автора, либо постить фото Джимми Уэйлса и демотиваторы.
Вы не правы, куки лишь строка, где они были добавлены и как серверу на самом деле плевать, потому что это лишь очередная строчка в заголовке. И та опция что Вы указали легко обходится.
Чукча — не читатель, Чукча — писатель. Я прекрасно знаю что опцию можно не только обойти, но и она может быть тупо не поддерживаемой клиентом. Но проверить модификацию куки на сервере — не проблема, с помочью полного сравнения с копией на сервере, либо записью чексумы. Выше всё это уже писал и привёл пример из практики, когда проверка кук на серере использовалась.
А в итоге за то что поделился знаниями и опытом, ещё и должен оправдываться. Тьфу.
А в итоге за то что поделился знаниями и опытом, ещё и должен оправдываться. Тьфу.
Тут не в знаниях дело, просто куки добавлялись на клиенте и человек хотел эти же куки вставить курлом и столкнулся с проблемой дозаписи своих куков к существующим. Никто ведь не говорил что Вы не знаете чего-то, просто Вы не о том говорили.
Я НЕ комментировал сам пост, а комментировал конкретный комментарий к этой записи. Не нужно тащить свои глобальные переменные в этот неймспэйс.
Ну так серверу на самом деле без разницы =) Он получает строку независимо от того как куки ставили. Человек просто поправил в терминологии, не более.
Ок. Вы правы, но но мне кажется что за демагогией и софистикой вы где-то теряете истинный смысл. Я мог бы продолжить вашу цепочку, вель в реальности куку посылаются не с сервера на сервер, а их отсылает отсылает клиент, коим обычно является браузер. Да и кук никаких нет, это всего-лишь дополнительный заголовок. Да и заголовков нет, это набор байтов, да и байтов нет, это набор битов нулдей и единиц, да и нулей их нет, на самом деле это состояния есть сигнал, нет сигнала, да и сигналов нет, это ток, да и тока нет, это движение электирческих зарядов… Причём каждый термин можно оспорить и представить в нужно виде.
Но если мои куки изменил на клиенте и это может повлиять на логику серверного приложения, то мне плевать как это называется, потому что я знаю как это на сервере проверить и какой оптицей рекомендовать клиенту не трогать присланное сервером.
Но если мои куки изменил на клиенте и это может повлиять на логику серверного приложения, то мне плевать как это называется, потому что я знаю как это на сервере проверить и какой оптицей рекомендовать клиенту не трогать присланное сервером.
А не проще в сесии хранить данные которые не хотите чтоб были изменены? Всеравно ведь храните копию кук в сесии. А получается что Вы всеравно храните копию и пишете куки лишь для того (!) чтоб просто проверить «а не изменились ли они». Если это для передачи данных на клиент, так через JavaScript их проще и удобней передавать.
Ну ёлки ж. Я выше писал об этом. Сессии это внутриязыковая сущность, если используешь разные языки, то куки являются более универсальным средством, но приходится их шифровать и проверять целостность. Вот у человека возникла проблема, что нужно учитывать изменения куки посредством js, бывает обратная задача, когда нужно защититься от изменения посредством js. Причём не от злонамеренного, а случайного плагина, который может переписать нужную переменную. Здесь приходит на помощь столь полезный флаг. Мы в своё время писали под обёртку на php4 и не знали о нём, слава богу тогда js-а было мало и мы всё контролировали.
Понятно, что http — протокол без состояния и фактически каждый запрос делается с нуля, а восстановить состояния можно лишь по токену. Но знать о защите «кук» от дурака полезно, даже если с этим сталкивается 1 из тысяч разработчиков.
Понятно, что http — протокол без состояния и фактически каждый запрос делается с нуля, а восстановить состояния можно лишь по токену. Но знать о защите «кук» от дурака полезно, даже если с этим сталкивается 1 из тысяч разработчиков.
<?php
echo 'var jsVar = " '. addslashes($_SESSION['data_for_js']). ' " ';
?>
И не стоит совать в куки данные которые не хотите чтоб изменили.
echo 'var jsVar = " '. addslashes($_SESSION['data_for_js']). ' " ';
?>
И не стоит совать в куки данные которые не хотите чтоб изменили.
Хотя, может я чего-то не понимаю, приведите мне один пример когда нужно записать в куки _неизменяемое_ значение. Может с примером пойму что Вы имеете ввиду.
Там проблема, что они работают в разных языках одновременно(PHP, c, perl). А хранить сессии так, чтобы они были легко доступны из любого языка не получилось. Поэтому решили хранить всё в куках. Но потом появилась мысль в том что куки всё же могут изменить и стали думать над защитой. И придумали хранить контрольную сумму, которую можно получить из любого языка. И всё же научились получать контрольную сумму из разных языков, а эта сумма является тоже данными сессии… а класть данные туда где хранится контрольная сумма ещё не догадались.
а не… с суммой я ошибся… сумма передаётся в куках тоже. Поэтому только первая часть моего сообщения истинна.
1. Делаем общую папку и храним данные в JSON
2. Бд придумали тоже не для хранения данных
3. NOSQL бд очень быстры и для таких задач идеальны
4. (и главное) КАК Вы в perl узнаете что я в браузере не менял куки которые Вы поставили в PHP?
2. Бд придумали тоже не для хранения данных
3. NOSQL бд очень быстры и для таких задач идеальны
4. (и главное) КАК Вы в perl узнаете что я в браузере не менял куки которые Вы поставили в PHP?
Да хоть саму сессию можно делать только на куках, если у вас используется несколько разных языков. программирования. Функцию упаковки-распаковки такой сессии можно написать на любом языке.
Сейчас, конечно, проще хранить токен и поместить сессию на сервере в каком-нить memcached, который быстр и клиенты для работы с которым есть на другом языке.
Сейчас, конечно, проще хранить токен и поместить сессию на сервере в каком-нить memcached, который быстр и клиенты для работы с которым есть на другом языке.
> мои куки изменил на клиенте
В точку Ваше приложение не занимается проверкой того как были сформированы куки, оно проверяет те ли эти куки.
В точку Ваше приложение не занимается проверкой того как были сформированы куки, оно проверяет те ли эти куки.
это название в терминах бота на curl'е, т.к. бот может получить куки только от сервера и только в заголовках.
Вы правы, серверу все равно каким образом пользователь получает cookies: из заголовков ответа или из JS-кода. но мне (как боту а не как пользователю) не все равно. если в первом случае я могу все свалить на CURL и не париться, то во 2-м — придется делать вот такие костыли.
Мне кажется надо уже всем сделать API или прямо выкладывать SQL с дампом базы данных. Что бы можно было не утруждать одних придумывать других ломать.
P.S. Странно, что вы еще на баг с путями к JAR файлу не наткнулись…
P.S. Странно, что вы еще на баг с путями к JAR файлу не наткнулись…
За Live HTTP Headers, спасибо, будем знать.
До этого пользовался Wireshark для анализа HTTP-трафика.
Возникало ощущение, что как пушкой по воробью.
До этого пользовался Wireshark для анализа HTTP-трафика.
Возникало ощущение, что как пушкой по воробью.
HTTP Analyzer Standart попробуйте. Значительно мощнее и можно тестировать свои запросы «не отходя от кассы».
а разве фаербаг во вкладке «Net» уже не показывает заголовки запросов/ответов? там все должно быть, и даже в более красивом виде…
одно неосторожное движение, и все запросы очищаются
Насчет красоты фаербага спорить не буду, а вот насчет удобства… В фаербаге все приходится делать онлайн, а сохранить текущие результаты в файле для последующего изучения не так просто, если не невозможно. В Live HTTP Headers сохранение выполняется одной кнопкой. В этом плане он для меня незаменим. А фаербаг имхо больше всего подходит для анализа и отладки JS/AJAX.
Столкнулся с тем же при «автоматизации работы» с порталом на IBM WebSphere, как раз на последнем-предпоследнем шаге он добавляет cookie в js.
Я так понимаю под термином JavaScript cookie подразумеваются куки которые были положены через JavaScript? Потому что реально термина JavaScript Cookie я лично не встречал…
лепру парсили или что-то похожее? там очень хорошо с авторизацией, вроде
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция JavaScript cookies в CURL-запросы