Находятся под я рискую нападений на CSRF в форме POST, которая не требует, чтобы пользователь был зарегистрирован?
Я, вероятно - общий новичок здесь, но я все еще не уверен в том, что CSRF (Подделка Запроса перекрестного Сайта) нападение точно. Так позволяет взгляду на три ситуации...
1) У меня есть форма POST, которую я использую для редактирования данных по моему сайту. Я хочу, чтобы эти данные были отредактированы только пользователями, которые зарегистрированы.
2) У меня есть сайт, который может быть использован обоими пользователями, которые зарегистрированы, а также гости. Части сайта для зарегистрированных пользователей только, но существуют также формы POST, которые могут использоваться всеми пользователями - анонимный и не (например, стандартная форма контакта). Контакт должен сформироваться быть гарантированным против нападений на CSRF?
3) У меня есть сайт, который не имеет системы аутентификации вообще (хорошо, возможно, это нереалистично, поэтому позволяет, говорят, что это имеет администраторский сайт, который является отдельным от остальной части его, и администраторская часть правильно гарантирована). Основная часть сайта только используется анонимными пользователями. Формы POST на нем должны быть гарантированы?
В случае 1) ответа ясно да. Но в случае 2 и 3 я не знаю (и различие между 2 и 3 даже значительный?).
1 ответ
Есть средства CSRF всякий раз, когда вредоносный HTML или JavaScript, нацеленный на ваш веб-сайт, встроен в другая HTML-страница (или сообщение электронной почты), которое было успешно выполнено.
Примером может служить следующая страница, размещенная на другой веб-странице, которая невинно запрашивает ваше имя и возраст перед продолжением:
<form action="http://yoursite.com/transferfunds" method="post">
Your name: <input type="text"><br>
Your age: <input type="text"><br>
<input type="submit">
<input type="hidden" name="amount" value="1000">
<input type="hidden" name="toaccount" value="12345678">
</form>
Обратите внимание, что действие указывает на ваш веб-сайт и что скрытые входные данные содержат необходимую POST-информацию. В этом примере будет предпринята попытка перевести фонд в размере 1000 (в любой валюте) на счет номер 12345678. Если вам требуется логин в вашей форме и вы действительно проверяете его, то вышеуказанное, конечно, будет успешно выполнено только в том случае, если неосведомленный пользователь Вы недавно вошли на ваш сайт, но еще не вышли из него, или сеанс еще не истек.
Чтобы этого не произошло, лучше всего добавить в форму токен на основе запроса и проверить его на стороне сервера. Т.е. генерировать длинную, уникальную и непредсказуемую случайную строку, которую вы сохраняете в сеансе и вставляете как элемент формы .Когда форма отправлена, сравните отправленное значение токена с тем, которое уже находится в сеансе (и немедленно удалите то, что находится в сеансе). Чтобы сделать следующий шаг, используйте CAPTCHA .
В вашем конкретном случае, я думаю, вас больше беспокоит XSS , который является противоположностью CSRF, но, в свою очередь, также может быть источником для CSRF. Примером XSS является то, что пользователь вводит следующее в поле ввода, которое рано или поздно будет повторно отображено на том же веб-сайте:
<form name="delete" action="admin/deleteusers" method="post"></form>
<script>document.form.delete.submit();</script>
Всякий раз, когда вы, будучи администратором, просматриваете страницу с комментарием с (невидимым !) и скрипт внутри, то он будет успешно выполнен.
Предотвратить XSS на самом деле довольно просто. Просто HTML-экранирование любого управляемого пользователем ввода (т. Е. URL-адреса запроса, заголовков запроса, параметров запроса и тела запроса) до их отображения на веб-странице. В PHP для этого можно использовать htmlspecialchars () , а в Java / JSP - JSTL fn: escapeXml () . Таким образом, под каждым тегом < будет преобразовано в < и > в > , что приведет к тому, что любой введенный HTML / JS будет отображается буквально как есть и поэтому не может быть выполнен.