Насколько опасно использовать HTTP-REFERER ?

Я знаю, что данным клиента доверять нельзя. Знаю про токены, т.д.
Если делается POST, то URL запроса будет представлять собой HTTP-REFERER этого запроса. Понятно, что этот заголовок можно легко подменить. Но, ведь тогда на сервер придет уже ДРУГОЙ запрос, а не тот, который был изначально.
Например, если подменить домен, то запрос пойдет вообще на другой домен, т.е. сервер о нем даже не узнает.
Если подменить параметры POST-запроса - тогда сервер получит другие параметры. И если они будут противоречить друг другу - значит, сервер выдаст ошибку и всё.
Т.е., скажем, если пароль/логин пользователя противоречит другим POST-параметрам (действиям), то они просто не будут выполнены, да и все.

Есть ли изъян в этих рассуждениях?

0

Сообщение от Htext Пожалуйста, поясните. Лично я пока не нахожу никакой опасности. Потому и задал вопрос.

Тут надо понимать суть проекта. Но в общем случае у вас странное поведение. Т.е. на одной странице я могу удалить сообщение, а на другой это же самое не могу. Т.е. Если я удалю на первой, на второй оно точно так же пропадет.


Представьте ваш проект расширился, стала работать целая команда. И вот Васе поручают вывести на странице статистики самые популярные сообщения (или самые последние сообщения). А на этой странице имеет права удалять некий Петя... И вот этот Петя начинает грохаоть сообщения, которые по хорошему не должен..

0

Сообщение от Htext Их можно подделать, даже проще, чем HTTP-REFERER.

В том же сообщении дописано:

Сообщение от estic POST-обработчик, конечно, выполняет проверку этих параметров. Хотя иногда такой проверкой можно пренебречь.

Добавлено через 3 минуты
Обычные параметры более надежные в том смысле, что их сложнее "потерять".

0

Сообщение от estic POST-обработчик, конечно, выполняет проверку этих параметров.

И каким же образом вы при помощи такой проверки докажете, что поступило сообщение именно с надлежащего URL? Если не принимать во внимание HTTP-REFERER и не верить POSТ-параметрам.

Сообщение от voral на одной странице я могу удалить сообщение, а на другой это же самое не могу. Т.е. Если я удалю на первой, на второй оно точно так же пропадет.

Вы сможете удалять сообщения на любой странице, на которой ваши права доступа к сайту (и иные POST-параметры, поступившие от вас) не противоречат политике доступа.

Если вы удалите сообщение на 1-й странице, на 2-й оно не пропадет, т.к. находится совсем в другом месте. Там может быть уже другая политика. Это нужно будет делать еще один запрос - для удаления 2-го сообщения.

Сообщение от voral И вот Васе поручают вывести на странице статистики самые популярные сообщения (или самые последние сообщения). А на этой странице имеет права удалять некий Петя... И вот этот Петя начинает грохаоть сообщения

Значит, у Васи и Пети имеется одинаковый набор прав (совпадают параметры доступа). Тогда решение: ограничить пользователям аля Петя возможность удаления сообщений.

0

Сообщение от Htext именно с надлежащего URL

Если это принципиально важно - добавляйте в формы csrf-токены. Не 100% защита, конечно, но существенно усложнит жизнь исследователям.

0

Сообщение от Htext Если вы удалите сообщение на 1-й странице, на 2-й оно не пропадет, т.к. находится совсем в другом месте

Ну т.е. вы будет копировать это сообщение (если потребуется сделать на главной блок последних сообщений) т.по факту у вас будет сообщение храниться в нескольких экземплярах?

Т.е. потенциально при разрастании сайта, вы должны будете:
1. копировать сообщения столько сколько потребуется
2. Постоянно бдить за правами на каждой странице


Повторюсь, теоретически в каком то специализированно проекте такое может и оправдано, но в "общем случае" крайне странная система прав.

0

Сообщение от liris Если это принципиально важно - добавляйте в формы csrf-токены. Не 100% защита, конечно, но существенно усложнит жизнь исследователям.

Ну, да, согласен. Понятно, что при использовании токенов уже просто так не направишь эффективный POST-запрос на произвольный URL - будет отбой, да и все. Потому что в запросе не будет правильного токена. Но, ведь токен присылается с сервера в ответ на действие (например, GET-запрос на получение контента страницы) клиента. Злоумышленник может сымитировать такое действие и получить этот самый токен. И направить следующий запрос уже правильный, с токеном. Поэтому особой разницы в данном случае нет. Вот то, что осложнится жизнь исследователя - это да.
По крайней мере, сервер будет знать, что если уж от пользователя пришел правильный токен, значит, он недавно делал запрос по конкретному URL и у него в браузере открыта страница именно с этим URL, и именно с нее пришел следующий (уже POST) запрос. Но, еще раз: для получения токена достаточно сделать запрос контента страницы (ну, и авторизоваться, конечно). Т.е. сымитировать соответствующее действие клиента (браузера).

И в этом смысле токен практически не отличается от куки. Которые получает пользователь, авторизовавшись на сайте. Даже иногда рекомендуется записывать этот токен в дополнительную куку.
csrf-токен более актуален для того, чтобы предотвратить отправку данных (и куки) с другого домена. Но, мой вопрос немного не об этом.

Судя по всему, узнать URL запроса сервер может, теоретически:
1. По HTTP-REFERER
2. По соответствующему параметру в POST-запросе, если такой параметр будет
3. По REQUEST_URI (но это - примерно то же, что и п.1)
4. Из куки (если он там будет содержаться).
Иных вариантов, вроде бы, нет?
Можно, конечно, передавать URL в дополнительном пользовательском заголовке и т.д. - но это примерно аналогично.

А вот подтвердить URL повторных запросов сервер может при помощи токена.

Добавлено через 13 минут

Сообщение от voral у вас будет сообщение храниться в нескольких экземплярах?

Видимо, я вас не так понял. Если речь шли об одном и том же сообщении, но присутствующем на РАЗНЫХ страницах - тогда, конечно, оно будет удалено на обоих страницах (если на обеих пользователь имеет права на это).

Сообщение от voral 2. Постоянно бдить за правами на каждой странице

Но мне так кажется надежнее. Да, при отправке сообщений каждый раз проверяются права пользователя для каждой страницы.
Где-то проверок поменьше (для общих страниц), где-то - много.

Сообщение от voral вы должны будете: 1. копировать сообщения столько сколько потребуется

Ну, да. Если страниц с последними сообщениями несколько - сохранение их в отдельном файле, который затем подключается к этим страницам.
А как должно быть правильнее? Запрос в БД - вывести столько-то последних сообщений?

0

Сообщение от Htext Ну, да. Если страниц с последними сообщениями несколько - сохранение их в отдельном файле, который затем подключается к этим страницам. А как должно быть правильнее? Запрос в БД - вывести столько-то последних сообщений?

Одно сообщение хранится только в одном месте. А дальше на разных страницах оно может появиться если попадет под соответствующий фильтр. Например (конечно же очень условный): страница всех сообщений - отображает все сообщения, блок последних сообщений - последние Н сообщений, страница моих сообщений - сообщения где являюсь автором я

Конечно есть еще понятие кеширования. Каждый раз при заходе посетителя запрос в базу не выполняется. Выполняется только если кеш уже устаревший или его нет.Таким образом при грамотном подходе, данные будут получены быстрее.

Соответственно, к примеру, я как автор решил , что поспешил написать сообщение могу удалить его на страница моих сообщений и оно удаляется везде (так же может быть сброшен и кеш, в котором это сообщение может быть)

0

Сообщение от liris Использовать его не опасно, но доверять ему не стоит. При отправке запроса можно указать произвольное значение в этом поле.

А как указать?
По идее, это в запросе делается с курл,

но не работает, сервер все равно видит правильный реферер. Что я делаю не так и как нужно ? Я не злоумышленник, просто задачка чуток спарсить...

0

Сообщение от Htext И если они будут противоречить друг другу - значит, сервер выдаст ошибку и всё.

Я как-то делал отдачу ключа для шифрованного потокового видео для защиты от скачивания.
Делал проверку прав доступа заодно и проверял реферер, как доп. защита чтоб видео проигрывалось только на конкретной странице.
Но все это было в качестве "защиты от дурака", так как нельзя защититься от банальной записи экрана.

Добавлено через 40 минут
Htext, Для начала вы должны определиться от какого типа атаки вы хотите защититься.
Если это CSRF, то с учетом того, что через обычную форму нельзя добавлять заголовки, и как правило по умолчанию блокируются аякс запросы на чужой домен () - то это имеет некоторый смысл. Безусловно вы не первые, кто об этом задумался, и существуют множество статей на эту тему.

0