Правильно ли я понимаю, что если я авторизуюсь на сайте с поддержкой cookies и потом зайду на этот же сайт с другого браузера, используя тот же самый cookie, то меня автоматически авторизует?
>>192844754Отдельным скриптом на сайте. Куки это просто переменная с определенным значением, можно хоть свое написать даже
>>192844754А сам браузер в хедере передается да. Там еще много чего передается по чему теоретически задетектить можно было бы конкретного человека
>>192844798То есть скрипт сервера видит cookie http header, затем сравнивает его с user-agent http header, и если последняя авторизация с этим cookie проводилась с этим user-agent, то тебя логинит на сайт, в противном случае - просит заново вести логин/пароль, так?
>>192845067Лучше, блядь, пусть моя собственная сессия протухнет вместе с арендой ойпи, чем пижженые куки утекут.>>192845113Пояс ни
>>192844888Какие еще headers могут передаваться, по которым можно определить пользователя? Вот у двача всего 4 request header'а, как и у большинства сайтов. В данном случае, все, что можно использовать в качестве подтверждения пользователя - это браузер и ОС. Однако, как мы видим из скринов, у меня хром посылает request header на все популярные браузеры.
>>192845008В куках хранится значение(хэш), который от того, что задумал(и) использовать на сайте. Стандартно это УРЛ + ИП + ПК-клиента.
В общем, поясните, как реализована безопасность работы cookie. Потому что сейчас они хранятся в самой обычной папке, никак не шифруются. Теоретически я могу написать софтину, которая будет исполняться на компьютере жертвы, определяя его ip и забирая куки для авторизации на нужных сайтах. Да я могу даже перехватывать все request header'ы при загрузке сайта, чтобы потом имитировать пользователя у себя на компьютере.
>>192845664>В общем, поясните, как реализована безопасность работы cookie. Браузер ограничивает доступ к кукам сторонних.Сайт (на котором логинился) хранит ключ.
>>192845664>Теоретически я могу написать софтину, которая будет исполняться на компьютере жертвыЕсли у тебя что-то исполняется на компьютере жертвы, то нахуя тебе куки? Вкинь ей кейлоггер и собирай пароли прямо с клавы.
>>192845555Не важно, по какому алгоритму составляется cookie. Важно, то, что это за cookie, собственно. Допустим, имеем cookie "ud4iqd21j91", который получен хешированием на основе url + ip + pc_name. Так какая разница, как он получен? Я просто беру этот "ud4iqd21j91" и использую его как ключ авторизации
>>192845888>Я просто беру этот "ud4iqd21j91" и использую его как ключ авторизации>просто Сайт просто проверяет соответствие куков реальным данным. Чтобы все прошло нужно (как минимум) - такой же ИП, такая же ОС, тот же браузер.Ты не можешь использовать куки, для авторизации они пассивно используются другой стороной, в теории их можно подделать. Если захотеть и постараться.
>>192845888Ещё раз, в говносервисах такое прокатит. В нормальном мире - нет. Во-первых, хттпс сразу скажет, что трафик палится, во-вторых, сервер отдает с каждым ответом свежую куку, в-третьих, сервер проверит предыдущий ойпи и пошлет на авторизацию. Нету золотой пули, есть способы затруднить взлом сессии.
>>192845888>Я просто беру этот "ud4iqd21j91" и использую его как ключ авторизацииа сайт такой делает хеш еще раз и сравнивает с кукой, ой не совпадает иди нахуй
>>192845791Почитал на вики. Про хром нашел это. "В апреле 2013 было объявлено, что браузеры Chromium и Chrome, а также операционная система Chrome OS переходят на новый открытый движок Blink, являющийся форком WebKit. Первоначальной целью такого решения было доработать внутреннюю архитектуру движка и сократить объём его исходного кода."Blink настолько фундаментально похож (по факту и являлся) на WebKit, что его все равно определяет как WebKit даже спустя 7 лет изменений?
>>192846120>сервер отдает с каждым ответом свежую куку, в-третьих, сервер проверит предыдущий ойпи и пошлет на авторизацию
>>192846006Пишешь ты в бровзере 2ч.хкБровзер шерстит в своем хранилище чо есть из кук к этому домену и все чо найдет вместе с твоим запросом посылаетПока сайт не пошлет новый сет-куки
>>192846360Тот же SessionID не проверяется постоянно, только разово.Вообще весь механизм авторизации на сайтах абсолютно уязвим для MITM.
>>192846105>Сайт просто проверяет соответствие куков реальным даннымТо есть скрипт на сервере, видя cookie "ud4iqd21j91", которому, например, соответствуют url: http://2ch.hk + ОС: Windows 10 1251 + ip: 192.168.0.1 перепроверяет эти же данные? Зачем тогда вообще нужны куки, если нужно перепроверять те же самые данные, которые и содержит в себе этот cookie?
>>192846724потому что если одна эта проверочная куки совпала, значит можно считать валидными и остальные с этого же айпи и ос
>>192846724>Зачем тогда вообще нужны куки, если нужно перепроверять те же самые данные, которые и содержит в себе этот cookie?Для удобства пользователя не набирать каждый раз пароли.
>>192846912Большинство пользователей таких устройств не имеют.Так-то достаточно большой петли на кнопке.
>>192846120>хттпс сразу скажет, что трафик палитсяЧто значит трафик палится?>во-вторых, сервер отдает с каждым ответом свежую кукуно авторизует-то при следующем посещении сайта он по предыдущему cookie, который мы и возьмем>сервер проверит предыдущий ойпи и пошлет на авторизацию.ip подменить не намного сложнее, чем подсунуть нужный cookie в request http header
>>192847037В любом случае лучше все сжечь, нежели допустить, чтобы органы копались на соответствие УК.
>>192846189Подожжи, так браузеры все-таки шифруют cookies и отдают нужный cookie валидному домену, расшифровывая cookie соответствующим ключом? А эти ключи как и где хранятся?
>>192847116И чо?Вот ты открыл бровзер говнохром, зашел на сайт, ввел логин vasya и пароль qwerty и залогинился, сайт тебе прописал куку session_id=хуйсасайлалкаТы открыл на том же компе тормозиллу, зашел на тот же сайт и уже думал что ты залогинен, но ожидаемо соснул, т.к. куки у тебя нет.Тут ты подогнал хуй к носу и в говнохроме открыл приватное окно и там приватно соснул по той же причине.
>>192847188Что-то я не вижу биометрики на крупных сайтах с возможностью авторизации. В лучшем случае - 2FA с почтой или телефоном
>>192847230Да, шифруют.Браузер посылает все куки, которые может найти на сайт в надежде что на сайте их расшифруют.Какие куки сайт сможет расшифровать, те он посылает обратно. Потом браузер шлет расшифрованную куку, сайт тебя по ней авторизирует, потом шифрует эту куку и высылает обратно, чтобы никто не знал от какого она сайта.
>>192847251Очевидно, имелось в виду, что помимо нужного cookie>мы используем такую же ОС и такой же браузер с таким же ip
>>192847257Так если они не шифруются и где-то хранятся, значит, я могу спокойной их найти из спиздить украсть. Что помешает?Так же я могу, для получения нужного cookie, сделать так, чтобы браузер думал, что он обращается к валидному хосту, и он сам мне отдаст нужный cookie
>>192847612>Так если они не шифруются и где-то хранятся, значит, я могу спокойной их найти из спиздить украсть.C:\Users\Пользователь\AppData\Local\Google\Chrome\User Data\Default (или Profile 1)\файл "Cookies" без расширения>>192847612>Так же я могу, для получения нужного cookie, сделать так, чтобы браузер думал, что он обращается к валидному хосту, и он сам мне отдаст нужный cookie Подмени днс, если хост без хттпс, то возможно.
>>192847705>было бы весьма рационально шифровать ихОт кого? Он у тебя локально хранятся.А плюс к этому еще и срок протухания имеют, который сервер назначит. Хоть через час могут протухнуть, хоть через год.Точнее даже сессионная кука скорее всего в течение суток протухнет, а трекерная - будет жить годы.
>>192847818>Он у тебя локально хранятся.Я понимаю, поэтому и нужно их шифровать. Иначе любой софт может потенциально пиздить куки>А плюс к этому еще и срок протухания имеют, который сервер назначит. Хоть через час могут протухнуть, хоть через год.Это тоже понятно. Но ведь время для авторизации по старому cookie все-таки есть. Да и не так мало сайтов сбрасывают куки. Обычно достаточно авторизоваться один раз, а потом можно хоть через год зайти без ввода логина/пароля
>>192847879Знание особенности и необходимости двухфакторной подразумевает наличие знаний ненадежности "обычной" и ее непременимости для некоторых задач, в основном связанных с финансами.Отсюда следует, что ты понимаешь специфику незащищенности обычного использования, поэтому такой вопрос - Зачем? Ты и так знаешь больше, нежели большинство-большинство присутствующих ИТТ.
>>192848073>любой софт может потенциально пиздить кукиЛюбой кирпич потенциально может раскроить твою тупую башку.>Обычно достаточно авторизоваться один раз, а потом можно хоть через год зайти без ввода логина/пароляЩа тебе сервак будет сессии годами хранить.Одна история охуительней другой просто.
>>192848229Ты ебанутый?Это задается в конфиге.Для пыхи, например session.gc_maxlifetime =1440 секунд по умолчанию.А /tmp/ себе засирать годовасиками ни один сервер не будет.
>>192848076>и ее непременимости для некоторых задач, в основном связанных с финансами.ого, а тут ты в точку попал>Зачем? Ты и так знаешь больше, нежели большинство-большинство присутствующих ИТТ.Я начал изучать работу http, а затем по цепочке и всего связанного веб-стека. Потом пришел к выводу, насколько небезопасна вся эта система. Подумал, что, возможно, я что-то упускаю и все не может быть так просто, поэтому запилил тред, чтобы мои тезисы опровергли. На данный момент этого ни у кого ИТТ сделать не получилось, за исключение ссылки на вики про https. С ним я еще дел не имел, но пробежавшись сейчас по статье, понял, что там наконец-то начали экнрпитить ssl (вернее, tls). Сейчас сходу не могу придумать решения. Но стоит заметить, что повсеместно https начал применяться всего лишь лет 6 назад.
>>192848453>Но стоит заметить, что повсеместно https начал применяться всего лишь лет 6 назад.Правило 2/3.
>>192848169>Ща тебе сервак будет сессии годами хранить.Есть такие. Хотя, естественно, на серверах, где требуются повышенный уровень безопасности по тем или иным причинам, сессия обычно длится несколько минут.
>>192848525Бедные программеры используют куки для авторизации пользователя не учитывая конфиги.Это так, замечание.
>>192848768А в куках у тебя что, довен? Логин с паролем? А?Нет, блядь, там имя сессии. А в сессии на серваке уже хоть все твои данные хранятся, хоть просто фраза "{s:"я хуею с этих долбоебов"}"
>>192848685Сессия не используется для механизма авторизации, только потому что зависима от ИП, следовательно неудобна для пользователя, у которого динамический.Грубо - ставя галочку "запомнить меня на этом сайте", пользователь обоснованно считает, что всякие технические нюансы ему похую, для него важно чтобы когда онт следующий раз зайдет ему не пришлось бы заново вводить логин-пароль, ему незачем, ведь это его планшет, ПК, смарт и ему незачем постоянно заморачиваться. Поэтому хранится все в серверной БД годами, до следующей проверки. Места хватает.Исключение составляют корпоративные фишки с постоянным изменением ради безопасности, это совершенно другое.
>>192848874В куках - куки.Пара имя - значение (+ дата/время, с ограничением времени использования, но это вторично, можно не использовать).Технически протокол не предусматривает использования ничего кроме пары "имя-значение".
>>192849122Т.е. это дело сервера-сайта, использовать ли ему устаревший кук или нет. Клиент хранит дату/время кукисов "информативно".
>>192848973В таком дискурсе обоснованным считается авторизация через сторонние сайты (см. Веб 2.0), что приводит к правилу третей и большему распостранению взломов в соответствии с их упрощением.
>>192849247Что привело к обоснованному использованию той самой 2FA в задачах, которые связаны с финансами.