Разрешить запрос Get, но только в моем домене?

Вы перепутали пару общих вопросов здесь.

Во-первых, атака, как уже отмечали другие, называется подделкой межсайтовых запросов. Можно вызвать либо GET, либо POST из другого домена, и, поскольку запрос направляется в ваш домен, он будет передан в файлах cookie для вашего домена, которые включают сведения о сеансе.

Чтобы противостоять этому, когда пользователь входит в систему, сгенерируйте токен (некоторая случайная строка символов), которую все ссылки и формы на вашем сайте передают обратно во время этого сеанса. Когда приходит запрос, возьмите детали сеанса из файла cookie и найдите, какой токен должен быть GETted/POSTed для этого сеанса. Если правильный токен не был передан, вы можете проигнорировать запрос/информировать пользователя/детали журнала для дальнейшего расследования. Я бы порекомендовал последнее, так как при реализации этого вы вполне можете пропустить несколько ссылок или форм, которые тогда не будут работать. Пользователи могут просто уйти, не тратя время на то, чтобы сообщить вам об этом.

Во-вторых, GET-запросы должны быть безопасными (то есть просто вызывать отображение данных без внесения изменений), а POST-запросы должны использоваться для всех запросов на изменение данных. Во-первых, на случай, если пауку удастся перейти по ссылке, вызывая изменения, которые пауки не должны вызывать. Во-вторых, в качестве резервной копии для пользователя, обновляющего страницу — браузер должен напоминать ему, что он будет повторно отправлять запрос и хочет ли он продолжить. Я говорю в качестве резервной копии, потому что все ваши запросы должны быть написаны таким образом, чтобы они были безвредны/игнорировались при повторной отправке, т.е. не имели кнопки, которая запрашивает удаление последнего элемента, вместо этого ищите идентификатор последнего элемента 1423 и есть кнопка запроса на удаление 1423; если это отправлено дважды, то во второй раз ваша проверка должна заметить, что элемент 1423 больше не существует и не вызывает дальнейших изменений.

я должен использовать POST вместо этого? Может ли POST замедлить работу сайта? Файлов cookie очень мало, поэтому браузер может отправлять файлы cookie и POST с одним пакетом, однако я не знаю, должны ли POST и файлы cookie быть отдельными.

Да, в вашем случае лучше использовать POST для снижения риска безопасности. И не отдавайте предпочтение скорости безопасности, используйте POST, и да, post и cookie не будут конфликтовать друг с другом.

В заключение я бы посоветовал вам воспользоваться очистителем HTML, чтобы сделать ваши URL-адреса и формы безопасны.

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

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Я в основном согласен со статусом 203. Помимо того, что он сказал о том, что POST на самом деле не помогает, пара комментариев:

1) GET безопасны только в том случае, если приложение написано правильно. Я видел приложения, в которых GET используются даже для внесения изменений. Во-вторых, если вы возвращаете данные JSON в виде массива и ваша точка входа не защищена от CSRF, в некоторых браузерах злоумышленник может украсть данные жертвы, заманив жертву на веб-сайт, на котором есть ‹script src=http://yourserver/json_rsp_entrypoint›‹/script>; а затем переопределить конструктор массива.

2) Во-вторых, имея что-то случайное в параметре, а затем проверяя, что хранится в сеансе, это сложно, если у вас нет сеансов (например, если у вас есть сотни серверов и вы не хотите выполнять запросы ДБ). Таким образом, одной из альтернатив является включение MD5 (session_cookie) в качестве токена CSRF. Это позволяет вам проверять, не прибегая к БД, а злоумышленник без XSS не может получить session_cookie и, следовательно, не может создать токен. Обратите внимание, что я не рекомендую использовать в качестве токена сам session_cookie, потому что это создает более серьезные проблемы — когда реферер просачивается или находится в скрытом поле формы, а затем, если страница сохраняется.