Защита форм входа и комментариев от CSRF
Я прочитал много статей о защите CSRF ( это хорошая статья ) и различные вопросы здесь, на SO, но ни одна из них не кажется достаточно информативной, чтобы ответить на мой вопрос.
Я разрабатываю свою собственную CMS и хочу защитить свои формы входа и комментариев. Я разрешу анонимным пользователям комментировать мой сайт.
Все формы на моем веб-сайте защищены с помощью токенов. Я уже знаю об этом подходе, но проблема в том, что он нуждается в активном сеанс (то есть после входа пользователя в систему). Проблема с формами входа и комментариев заключается в том, что они доступны практически любому пользователю и не требуют от вас входа в систему - что было бы лучшей защитой от CSRF в этом случае?
По ссылке выше я прочитал, что можно было бы создать "предсессионный", когда пользователь пытается войти в систему, а затем перейти к обычным методам защиты от CSRF (например, назначить токен сеансу пользователя), но у меня нет представления о том, как достичь этот.
Заголовок ссылки - слабое решение, поэтому, думаю, мне не стоит беспокоиться. Заголовок Origin, насколько я проверил, поддерживается только в Google Chrome. Как насчет пользовательских заголовков? XMLHttpRequest кажется возможным, однако я потратил буквально более трех часов на поиск в Google некоторой информации о том, как следует применять такую меру безопасности на их веб-сайте. Но даже если бы я мог использовать пользовательский заголовок, разве это не делает его бесполезным, поскольку заголовки HTTP могут быть полностью подделанным?
Итак, вопрос: как я должен защитить свои формы входа и комментариев от CSRF?
Редактировать: вот некоторая дополнительная информация по ссылке, которую я предоставил выше:
Мы рекомендуем строгую проверку референта для защиты от CSRF входа в систему потому что формы входа в систему обычно отправляются по протоколу HTTPS, где заголовок референта надежно присутствует для законных запросов. Если в запросе на вход отсутствует заголовок реферера, сайт должен отклонить запрос на защиту от вредоносного подавления.
И
Секретные токены проверки могут защитить от CSRF входа в систему, но разработчики часто забывают реализовать защиту, потому что перед входом в систему нет сеанса, к которому можно привязать токен CSRF. Чтобы использовать секретные маркеры проверки для защиты от CSRF входа в систему, сайт должен сначала создать "предварительную сессию", реализовать защиту CSRF на основе маркеров, а затем перейти к реальному сеансу после успешного завершения идентификация.
Я просто не могу положить конец этому аргументу после прочтения приведенных выше цитат. В одном из них упоминается использование заголовка ссылки, но я не совсем уверен, действительно ли это значительно повышает безопасность веб-приложения.
Редактирование 2: Как насчет использования капчи?
4 answers
Проблема CSRF связана с тем, что кто-то использует учетные данные зарегистрированного пользователя для отправки чего-либо. Это очень проблематично, так как вредоносный сайт может делать то же, что и любой, кто только что заглянул на ваш сайт. Если вы говорите о формах, которые можно использовать как анонимные, без входа в систему, риск CSRF намного меньше, так как значительно меньше пользы от публикации в форме с другого сайта - так как любой может сделать это напрямую и с теми же разрешениями.
Так что я не понимаю, почему защита требуется защита от CSRF для незарегистрированных форм.
Если вы действительно этого хотите, предсессионный токен может быть технически похож на реальный сеанс, но только более легкий. На самом деле он не будет содержать ничего, кроме сгенерированного токена.
РЕДАКТИРОВАТЬ: об использовании $_SESSION, предоставляемого PHP для предсессионного токена, это стандартный механизм сеанса PHPS. Если вы хотите использовать это, то да, примерно так.
Однако вас не заставляют делать это таким образом, и я лично я бы так не поступил, так как он потребляет память сервера для всех посетителей, а это на самом деле не нужно. Для более эффективного механизма в основном вам нужен а) файл cookie, идентифицирующий пользователя, и б) что-то, хранящееся на стороне сервера, сообщающее, что файл cookie действителен (и, если необходимо, для кого он действителен, то есть ip-адрес). Для более легкого подхода вы можете просто создать токен, сохранить его в файле cookie и создать что-то, соответствующее этому токену в форме скрытого поля, и сопоставить те, кто подчиняется (как объяснил Девеш). Последнее предотвратит отправку форм с другого сайта, первое предотвратит даже тот случай, когда вредоносный сайт выполняет поиск на вашем сайте и пытается установить любые файлы cookie для конечного пользователя. Итак, я могу придумать три подхода:
- просто предотвратите запросы изображений с других сайтов - использование сообщений предотвращает это
- запретить отправку формы с другого сайта - скрытое поле формы, соответствующее файлу cookie, предотвращает это
- запретить отправку форм с другого сайта, которые выполняют предварительный поиск на вашем сайте - для этого потребуется проверка IP-адреса, что-то, хранящееся на стороне сервера, например ip-адрес в базе данных, сопоставленный с файлом cookie
ПРАВКА2: В captcha их основным вариантом использования является предотвращение попыток автоматического (грубого) входа в систему. Они также устранили бы проблему с запросами CSRF в формах входа, но для этого это излишне. Для предотвращения атак с использованием грубой силы они могут потребоваться в некоторых случаях, хотя что-то более удобное для пользователя может быть для того, чтобы не слишком ухудшать удобство использования. Может быть, что-то вроде KittenAuth :)
Вы не можете реально защитить анонимную форму от CSRF. Просто потому, что другой сайт может действовать как обычный пользователь. Я могу просто создать сайт, который выполняет запрос curl в анонимную форму и хранит файлы cookie и токены в переменных. А затем сделайте второй запрос на публикацию формы.
Скрипт на самом деле не подделывает запрос, а просто публикует его автоматически.
Смысл CSRF заключается в том, чтобы запретить сценарию/пользователю выполнять действия от имени другого пользователя. Так что это был бы я пытаюсь писать как ты. Чтобы предотвратить это, сеанс/файл cookie с использованием токенов является хорошим решением. Потому что у меня нет возможности получить ваш сеанс и токен, если только ваш сайт не имеет недостатков в других областях. Я бы предложил прочитать руководящие принципы OWASP, чтобы получить некоторое представление о том, что вам следует искать.
Еще одна вещь, которую вы всегда должны делать, это убедиться, что "действия" всегда связаны с запросом POST, поэтому я не могу просто разместить изображение на вашем форуме, которое ссылается на 'http://www.yoursite.com/delete.php?id=10 '. Если вы разрешите запрос GET и откроете страницу, содержащую это изображение, я бы подделал запрос. Если вы разрешите только POST, это не даст никакого результата.
Я думаю, что вы можете решить проблему CSRF, объединив скрытое поле, добавленное в вашу форму, и в то же время добавить то же значение в файлы cookie и прикрепить к ответу пользователя. Когда пользователь отправит форму обратно, попытайтесь сопоставить значение скрытого поля и значение файла cookie, полученное из запроса, если оба они совпадают, вы можете идти...
Проблема CSRF связана с тем, что кто-то использует учетные данные зарегистрированного пользователя для отправки чего-либо. Это очень проблематично, так как вредоносный сайт может делать то же, что и любой, кто только что заглянул на ваш сайт. Если вы говорите о формах, которые можно использовать как анонимные, без входа в систему, риск CSRF намного меньше, так как значительно меньше пользы от публикации в форме с другого сайта - так как любой может сделать это напрямую и с теми же разрешениями.
Так что я не понимаю, почему защита требуется защита от CSRF для незарегистрированных форм.
Если вы действительно этого хотите, предсессионный токен может быть технически похож на реальный сеанс, но только более легкий. На самом деле он не будет содержать ничего, кроме сгенерированного токена.