У меня вопрос о прекращении подачи поддельных форм. Как насчет того, если с помощью $_SERVER['HTTP_REFERER'] я разрешаю отправлять только мои формы с моего сайта? Это поможет? Благодаря!
Это поможет, и это довольно легко добавить, но он не остановит целенаправленную атаку, ведь вы можете обмануть заголовок HTTP_REFERER .
Следует иметь в виду, что клиенту не требуется отправлять HTTP_REFERER , поэтому, если заголовок отсутствует, вы, возможно, захотите разрешить отправку. Если это невозможно, проверка HTTP_REFERER поможет вам.
Запустите поиск CAPTCHA «Полностью автоматизированный публичный тест Тьюринга, чтобы рассказать« Компьютеры и люди » , это то, что вы действительно ищете.
Давайте поясним: технически невозможно предотвратить подделку форм. Подводя итог в одном предложении:
Если ваш браузер может это сделать, каждый может это сделать.
Основные проблемы с подстановкой форм – это то, что вы не имеете никакого контроля над тем, что отправляет клиент. Пользователь может изменить любой параметр формы. Поэтому все, что отправляет клиент на отправку формы, необходимо проверить и проверить.
Это также означает, что чем меньше параметров вы предоставляете для отправки в форме, тем меньше вам нужно проверить и проверить. В частности, параметры, которые предварительно заданы и не подлежат изменению пользователем (то есть скрытые поля формы), не обязательно должны быть встроены в форму, если это действительно не необходимо. Вместо этого вы можете хранить их в контейнере в сеансе и только ссылаться на этот контейнер через скрытое поле. Если это не вариант, убедитесь, что вы, по крайней мере, можете обнаружить дефект целостности, выполнив заданные значения с помощью MAC .
Другая проблема заключается в том, что параметры формы, которые необходимо отправить для успешной подачи формы, вполне предсказуемы, чтобы злоумышленник мог отправлять повторно действительные формы. Если вам потребуется не предсказуемый параметр, который может быть выдан только вашим сервером и подтвержден при отправке формы, вы можете проверить, предоставлена ли форма.
Одним из решений было бы использовать случайный одноразовый токен, который генерируется в запросе формы и сохраняется в сеансе, а также помещается в форму в виде скрытого поля ввода. Затем при отправке формы вы проверяете, был ли предоставлен токен и равен ли он тому, который хранится в сеансе; если они равны, вы удаляете токен из сеанса и обрабатываете форму, иначе вы отказываетесь от обработки формы.
Честно говоря, этот механизм не идеален, поскольку вы все равно можете запросить форму сначала, а затем отправить данные поддельной формы. Здесь вы можете использовать дополнительные Captchas или другие механизмы, которые предотвращают автоматические запросы.
Лучше всего было бы использовать комбинацию всех мер, упомянутых выше:
Кроме того, эти контейнеры форм на основе сеанса также предотвращают CSRF, поскольку их идентификаторы непредсказуемы для атакующей третьей стороны.
Стоп? Безлимитный? Возможно. Ваш сайт действительно поражен тревожным количеством поддельных форм, или вы просто преувеличиваете? Не решайте проблем, которых там нет.
Реферер легко подделывается.
Вы должны проверить форму, которую вы можете, чтобы поймать глупых ботов и, возможно, использовать CAPTCHA на стороне сервера.
Referer легко подделать, поэтому любой злоумышленник, который хотел подделать форму, мог просто подделать заголовок Referer. Кроме того, я не верю, что веб-браузеру необходимо отправить заголовок Referer, поэтому он может потенциально исключить сообщения о форме от законных пользователей.
Попробуйте captcha как ReCaptcha . Вы не только предотвратите спам-боты от спама вашего веб-сайта, но также сможете «разрешить» только тех людей, которые используют вашу форму (по крайней мере в некоторой степени), им нужно будет загрузить форму, чтобы получить капчу, а затем отправить ответ).
Spoofing HTTP headers довольно прост и поэтому не должен использоваться для чего-то, что требует строгой безопасности. Один из методов, который обычно используется, заключается в том, чтобы отправить зашифрованный файл cookie и соответствующий, зашифрованный токен в скрытый ввод формы. Файл cookie должен быть cookie только для HTTP. При отправке формы проверьте соответствие значения из файла cookie и значения из скрытого ввода. Это поможет предотвратить подделки запросов на межсайтовых сайтах, поскольку запрос на ваш сайт не может быть успешно выполнен с другого сайта, потому что они либо будут пропускать cookie (для атаки MIM), либо скрытый ввод (поддельная форма). Конечно, это зависит от того, что вы убедитесь, что ваш сайт защищен, поэтому они не могут нюхать токены, чтобы узнать, что им нужно.
Вот хорошая дискуссия о том, как это делается в ASP.NET MVC, http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken -helper /
Без определения «спуфинга» это будет пустой разговор.
Есть дюжина разных «пародий», каждая из которых отличается своей защитой.
Наиболее общим решением является CAPTCHA.
Было бы предложено использовать токен. Если вы используете какую-либо из популярных архитектур MVC, вам не нужно беспокоиться о том, как заботится о предотвращении спуфинга. Но если вы работаете с настраиваемой MVC-архитектурой, как и я, токеном является подход. В вашем классе базы данных для каждой функции CRUD (CREATE, READ, UPDATE и DELETE) проверьте токен. например, токен может быть сгенерирован через md5.
public function save(){ if(isset($_SESSION['token']){ //proceed with saving }else{ //kill it, die; } }
Кроме того, вы можете легко интегрировать ваше веб-приложение с помощью этого набора защиты от перекрестного запроса запросов. Проверьте это здесь
Не помогает. Прочтите это: http://shiflett.org/articles/form-spoofing