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

Question

На моем сайте я могу вызвать определенные вещи, используя GET-запрос, например, возможность скрыть или удалить комментарий. Я не очень волнуюсь, но было бы довольно неприятно, если кто-то спроектирует атаку, используя img src = url для удаления комментариев или электронных писем. Есть ли способ предотвратить это?

Я использую httponlycookies для входа в систему. если кто-то делает img src или другой вариант, будет ли запрос отправлять действительные файлы cookie для входа? я должен использовать POST вместо этого? Будет ли POST замедлить работу сайта? Существует очень мало файлов cookie, поэтому браузер может отправлять файлы cookie и POST одним пакетом, однако я не знаю, должны ли POST и файлы cookie быть отдельными.

кажется, что во всех этих ответах есть что-то, чего не следует учитывать в другом 3. Так что я превращу это в вики, чтобы люди могли получить больше информации, а не смотреть на принятый ответ.

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

я должен использовать вместо этого POST? Будет ПОСТ замедлить сайт? Есть очень маленькие куки, чтобы браузер мог отправить печенье и POST с одним пакетом Однако я не знаю, если и ПОСТ печенье должно быть отдельным.

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

В конце я бы предложил вам воспользоваться html-очистителем для обеспечения безопасности ваших URL-адресов и форм.