Можно ли доверять HTTP_REFERER (предварительно прочитайте вопрос)?

Question

[krs]

Конечно, его стоит фильтровать при получении, т.к. нет проблем подделать его при прямом участии злоумышленника (тот же самый telnet и т.д.), но мой вопрос не об этом. Есть статья «Подделка заголовков HTTP запроса с помощью Flash ActionScript» (www.securitylab.ru/analytics/271169.php), в которой показан наглядный пример подделки HTTP_REFERER прозрачно для пользователя в определенной версии броузера с включенным flash плеером. Собственно вопрос к специалистам, можно ли доверять данному заголовку для идентификации страницы — инициатора запроса с поправкой на то, что перед нами обычный пользователь. Может ли злоумышленник подделать запрос в современном броузере (броузеры чей процент на данный момент хотя бы выше 1 из общей посещаемости интернета). Или все таки лучше подписывать каждый подобный запрос?

Answer 1

[Никита Гусаков]

Конечно нет. Это то, что передает клиент.
Самый простой способ это проверить — одна из опций curl:
-e, --referer Referer URL (H)

Comments

[krs]

В начале вопроса я пишу об этом, вопрос о честном пользователе

[Никита Гусаков]

Ну знаете ли, честный пользователь == браузер, тогда вопрос ни о чем, смотрите спецификации браузеров на которые вы расчитываете. И все таки вы лукавите о «честных пользователях», ибо затем вы спрашиваете о злоумышлинниках, а это явно не обычные пользователи. Вообще все вопросы безопасности касаются всегда необычных пользователей, не будет же среднестатистический пользователь вам скрипты пытаться вставлять?

[krs]

«не будет же среднестатистический пользователь вам скрипты пытаться вставлять?»

В этом и есть суть вопроса, среднестатистический пользователь переходит на сайт злоумышленника, а тот соответственно подменяет запросы от его имени

Я все таки решил реализовать подпись каждого запроса

[Никита Гусаков]

Это как так происходит? Вы же пользователя по сессионной куке авторизуете, а не по http_referer?

[krs]

Основной проект авторизует сторонний сайт, сайт проверяет, что запрос на установку куки авторизации пришел от головного проекта по рефереру, буду переделывать на токен

[Никита Гусаков]

на мой взгляд самым правильным решением будет сохранять в базу токен и передавать его в запросе, а другим сервером проверять этот токен, http_referer для этого точно не подходит

[krs]

Спасибо, я тоже так считаю. Пока не могу представить полную модель подобной системы, просто у меня еще есть задача ставить куку на более низкий домен, нежели запрашивающий ее, сейчас вся проверка только на реферере идет, но это так — наброски. Меня он смущает и вы подтвердили мои опасения, если подводить вопрос к концу, то скажем так — в пределах сессии среднестатистического пользователя рефереру доверять можно, но и то не на 100 процентов, ведь была возможность в свое время его подменить, следовательно она может сложиться и при определенной конфигурации в будущем. Вы согласны?

[Никита Гусаков]

Самое простое решение — вообще забить на сессию, есть id юзера, есть токе(хеш), ну и select… where id=$id and auth_token=$token
http_referer может быть дополнительной проверкой

[krs]

Дак в этом и проблема, что второй сайт, который у головного запрашивает токен не имеет доступа ни к бд ни к чему, только аякс запросы

[krs]

Попробую на головном создать таблицу всех возможных второстепенных серверов, у каждого задать открытый ключ, а на данные сервера соответственно поместить закрытые ключи, и каждый запрос на авторизацию к головной системе подписывать

[Никита Гусаков]

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

[krs]

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

[Никита Гусаков]

серверы еще могут и между собой общаться:)

[krs]

Моя задача — сделать так, чтобы авторизовавшись на головном проекте пользователь а автоматическом режиме получал токен и на всех второстепенных сайтах, про openid пойду повнимательнее еще почитаю

[krs]

Общаться между собой они могут и общаются, но вот кук пользователя в этом общении нет =)

[Никита Гусаков]

Это тот случай, когда стоит создать свой обработчик сессий

[krs]

Можно поподробнее вашу мысль? Сессии вообще не использую на текущий момент, только токены

[Никита Гусаков]

Ну что такое сессия? Это возможность сохранить данные о пользователе, его последних действиях, о том что он зашел и тд. Чтобы индетифицировать пользователя можно например брать его ip+юзер-агент. В вашем случае подобные данные можно заранее получить. Если на одном из серверов кто-то авторизировался, этот сервер отсылает сообщения всем остальным, они создают токен этой сессии у себя, и в дальнейшем распознают пользователя.

[krs]

Дак на одном Ip целая страна может крутиться — это раз, а во вторых я считаю, что головной сервер не должен рассылать что то второстепенным, он в идеале о них даже знать не должен, чтобы в любой момент можно было подключить еще один-другой второстепенный сервер

[Никита Гусаков]

Ну точку синхронизации вы должны сами продумать, это может быть sql-сервер, к которому все коннектятся, это может быть просто api-сервер, это могут быть независимые сервера которые знают друг о друге.
www.php.net/manual/ru/class.sessionhandler.php — есть кстати такая штука, судя по всему позволяет создавать новые сессии самостоятельно, без запроса, могу ошибаться.
Я не знаю точно что берется за базу для идентификации сессии, вы можете выбрать себе все, что угодно. Но вы никогда не сможете однозначно определить одного и того же пользователя с разных доменов. С поддоменами история другая.

[krs]

«Но вы никогда не сможете однозначно определить одного и того же пользователя с разных доменов»

Именно этим и занимаюсь, готов с вами поспорить =) Давайте через пару дней вам отпишусь и расскажу о результате, договорились?

[Никита Гусаков]

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

[krs]

Я же говорю, что все работает, пока что только в идентификации инициатора запроса проблема, стоит реализовать подписывание запросов и все, а пока что через реферер работает, но я считаю это ненадежным

Answer 2

[Максим Дьяченко]

для XSRF лучше использовать токены.
Даже если все комбинации юзерского софта будут защищать реферер, то никто не знает какую уязвимость найдут завтра.
Когда я последний раз этим интересовался (давно) возможность атаки имела место.

Comments

[krs]

Спасибо, к этому и склонялся, но что, если злоумышленник выполнит запрос под собой, а пользователь посредством какой либо уязвимости выполнит его запрос с его токеном? Привязка токена к ip? А если у злоумышленника и пользователя один и тот же ip?

[Пума Тайланд]

А если злоумышленник засунет пользователю в задницу паяльник?
Не впадайте в бред.

[krs]

Паяльник в задницу можно засунуть одному-двум пользователям, а XSRF можно провести массово. И паяльник в жопу скажем крайне проблематично засунуть администратору, а вот XSRF…

[Максим Дьяченко]

В формах на сайте добавляется скрытое поле с токеном.
Токен генерируется на основе конкатенации идентификатора сессии (которая и так привязана к пользователю и айпи), и некоего секрета который не известен злоумышленнику. Сюда же можно добавить еще время или страницу или еще что-то, хранить некие секретные ключи в сессии и т.п., но это уже не так критично. В результате сгенерировать токен злоумышленик не может, ибо ему нужен наш секрет + сессия пользователя. Подставить свой токен он не может — для сессии жертвы он не будет работать.

[krs]

Спасибо за совет, подобно вашему и реализовал

Answer 3

[Sergey Belov]

На данный момент актуальных способов подделки referer в браузере пользователя нет, если требуется конкретный ответ на вопрос.

Comments

[krs]

Спасибо, вы практически единственный человек, кто прочитал вопрос =)

Answer 4

[egorinsk]

Если вы делаете игры с кроссдоменной авторизацией, ставьте подпись. Некоторые плагины к браузерам и прокси вырезают referer, вы получите то, что у части пользователей реферер работать не будет, и потратите кучу времени на выяснение, почему.

Comments

[krs]

Спасибо, на этом и остановился, но все же проверку на реферер также оставил, мб уберу ее в дальнейшем

Answer 5

[Андрей Буров]

Никаким данным пришедшим от пользователя доверять нельзя!
(PS: это же вообще основы WEB разработки)

Comments

[krs]

Вопрос был не о фильтровании, а о возможности подделать данные по средствам XSRF

[Степан]

@krs Вам и дали ответ не о фильтровании а о том, что подделать любые данные которые отправляет юзер можно. Доверять им само собой нельзя!

Answer 6

[rozhik]

Если проблема в том, чтобы на стандартном не модифицированном браузере, без privacy фильтров не дать:
1 3 тьей стороне вставить hotlink на контент
2 пользователю перейти непосредственно на страницу
3 XHR с сайта 3тьей стороны
То можете.
Но я рекомендую подписывать серьёзные запросы. Ибо более чем у трети пользователей старый браузерный софт. А к нему можно найти много дырок во флэше, джаве или еще в чем, которые позволили бы третьей стороне сэмулировать переход с неверным реферором.