Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Пришел неавторизованные клиент без сессионной куки. Ушел GET запрос на картинку /path/image?id=NNNN, который в ответ сгенерировал ID сессии...
Извините, так и не понял эту ахинею. Во-первых, отдача картинок (если это не персональные картинки) должна происходить независимо от наличия сессии и создавать её не нужно. Во-вторых, разве сессия не создаётся только после успешной авторизации?
Отвечу с конца. Сессия не обязана создаваться ТОЛЬКО после успешной авторизации. Приведу конкретный пример. Корзина неавторизованного пользователя. Это уже сессия, в рамках которой существует корзина. Уже после регистрации (или авторизации, если это старый пользователь) в сессию добавляется информация о конкретном пользователе.
Отдача картинок происходит независимо от сессии. Тут важно, что картинка отдается не как статика, а как результат работы скрипта на Backend. Это равноправный код, как и весь остальной, который автосоздает (если её еще не было) новую сессию, что по сути представляет собой генерацию ID сессии и отправки её в качестве куки.
Вроде как стандартный механизм сессий. Если что-то непонятно, могу еще подробней описать про сессии или дать ссылки где почитать.
Отдача картинок происходит независимо от сессии. Тут важно, что картинка отдается не как статика, а как результат работы скрипта на Backend. Это равноправный код, как и весь остальной, который автосоздает (если её еще не было) новую сессию, что по сути представляет собой генерацию ID сессии и отправки её в качестве куки.
Вроде как стандартный механизм сессий. Если что-то непонятно, могу еще подробней описать про сессии или дать ссылки где почитать.
Как выше написал автор, именно в этом месте ахинеи то как раз и нет. Подавляющее большинство адекватных сайтов работают по той же схеме, т.е. при любом запросе генерируют сессию (это не обязательно означает что пользователь был авторизован для каких либо действий, даже существует сессия анонимного пользователя). Тем более как вы себе представляете аутентификационный запрос с CSRF токеном, если этот токен не будет привязан к ID сессии?
Другой вопрос, что все нормальные сайты после этой самой аутентификации должны генерировать новый ID сессии. А вот это делают далеко не все, и сами выстреливают себе в ногу, т.к. потенциально порождают сессионные уязвимости типа Session fixation.
Вообще OWASP довольно хорошо об этом говорит здесь:
Другой вопрос, что все нормальные сайты после этой самой аутентификации должны генерировать новый ID сессии. А вот это делают далеко не все, и сами выстреливают себе в ногу, т.к. потенциально порождают сессионные уязвимости типа Session fixation.
Вообще OWASP довольно хорошо об этом говорит здесь:
A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.
Очень верное замечание про новый ID сессии.
После пули в ногу команда сделала выводы и в плане будет ряд задач как улучшить эту часть проекта.
После пули в ногу команда сделала выводы и в плане будет ряд задач как улучшить эту часть проекта.
Уязвимость вида Session fixation существует только на тех платформах где ID сессии передается через URL.
В большинстве случаев так и есть, но тут речь не об этом.
Во-первых, я не зря написал потенциально порождают, т.к. обычно фиксация сессии через URL с последующим захватом аккаунта происходит именно в аутентификационном запросе (иначе атакующий просто залогинит жертву под своим аккаунтом). Таким образом, сгенерив новый ID после аутентификации мы уже на корню предотвратим такой класс уязвимостей.
Во-вторых, фиксация сессии возможна и через другие сценарии. Самый простой пример — через XSS, когда сессионные куки имеют флаг httpOnly и напрямую их не угнать, тут и придет на помощь session fixation. Опять же, OWASP в помощь.
Во-первых, я не зря написал потенциально порождают, т.к. обычно фиксация сессии через URL с последующим захватом аккаунта происходит именно в аутентификационном запросе (иначе атакующий просто залогинит жертву под своим аккаунтом). Таким образом, сгенерив новый ID после аутентификации мы уже на корню предотвратим такой класс уязвимостей.
Во-вторых, фиксация сессии возможна и через другие сценарии. Самый простой пример — через XSS, когда сессионные куки имеют флаг httpOnly и напрямую их не угнать, тут и придет на помощь session fixation. Опять же, OWASP в помощь.
Зашёл в интернет кафе. На свой любимый сайтик. Залогинился. Опа, тебе досталась сессия предыдущего посетителя (который злоумышленник и уходя, записал её себе в блокнотик).
мне кажется, есть еще способ решенич проблемы. Подавить автосессию при отдаче картинок. она там не нужна. только ресурс мал-мал кушает. Пусть автосессию генерят странички.
Кстати, а если картинки статичны и не зависят от сессии — почему их нельзя отдавать файлами? зачем вообще в данном случае скрипт и что он делает?
Кстати, а если картинки статичны и не зависят от сессии — почему их нельзя отдавать файлами? зачем вообще в данном случае скрипт и что он делает?
Возможно, картинки, например, ресайзятся прежде чем закешироваться, либо на них добавляется какой-то водяной знак.
Скорее всего уменьшает по размеру. Загрузили HD картинку, а показываем 100 на 100.
IMHO, конечно же, но мне кажется, что лучше всего было бы переписать код модуля, отдающего картинки. Как минимум убрать оттуда сессии, а еще лучше — делать ресайз и прочие операции после загрузки (один раз) и отдавать как статику.
Хотя, я, возможно, не вижу какого-то очевидного кейса, зачем картинки отдавать скриптом. Разве что там авторизация какая-то — одним можно, другим нельзя.
Хотя, я, возможно, не вижу какого-то очевидного кейса, зачем картинки отдавать скриптом. Разве что там авторизация какая-то — одним можно, другим нельзя.
Хотя, я, возможно, не вижу какого-то очевидного кейса, зачем картинки отдавать скриптом. Разве что там авторизация какая-то — одним можно, другим нельзя.
Конечно же это, но и еще, бывают такие ситуации, что файл на диске сервера хранится в виде случайно последовательности символов, а скрипт, отдающий этот файл пользователю уже задает ему нужное имя и MIME-тип. Это бывает нужно, когда есть необходимость хранить массу не имеющих отношения друг к другу файлов в одном месте и важно, чтобы при загрузке двух файлов с одинаковым именем файлы не перезаписывались
Возможно не каждую картинку нужно ресайзить. Пришел запрос — отресайзили, второй раз отдаем уже готовый файл. Можно периодически всё удалять, менять размеры или добавлять новые без массовой перегенерации, ну и авторизацию проще добавить.
Разве что там авторизация какая-то — одним можно, другим нельзя.
Ну, во-первых, для этого. Никто не будет рад, если фотки из личного альбома вконтактике будут доступны кому угодно по прямому URL (хотя бы потому, что URL-ы сохраняются в истории браузера).
Навскидку еще пара вариантов.
* Отдавать картинку, которую пользователь редактирует онлайн — добавляет надписи, рамочки, эффекты и т.п.
* Картографический сервер, который рендерит участок карты в соответствии с параметрами в GET (координаты центра, масштаб, разрешение...)
Архитектурные ошибки на лицо))) Но самое печальное, что такие ошибки есть почти в каждом проекте…
Мораль. Нужно быть внимательнее к предвестникам (очевидно они должны быть при игнорировании заголовков бэкенда), если что-то пошло не так, разбираться до конца. Явно были проблемы с кэшированием статики.
Когда прочитал анонс и увидел хаб nginx сразу вспомнил наблы и куроводство про кешиование nginx'ом от Дмитрия Котерова :)
Статику вообще лучше держать на отдельном домене, это еще и экономно по энергии.
Не стоит привязывать сеанс к IP. На одном IP сидят разные клиенты, поэтому такая привязка ничему не помогает. Но самое главное — у многих клиентов IP меняется на ходу. Представляете, как расстроится пользователь, если у него корзина вдруг пропадет или сайт попросит заново логин с паролем ввести?
Спасибо за рассказ о граблях. Постараемся учесть и не наступить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как можно взломать свой же Web проект?