Является ли предотвращение XSS веской причиной для предпочтения POST, а не GET для веб-приложений?

Question

Текущая тенденция в веб-приложениях, похоже, заключается в использовании запросов GET для всего. В частности, используя RESTful URL, которые описывают сервис, команду и ее параметры. Несколько месяцев назад Джефф Этвуд писал о вреде XSS. Он продемонстрировал, как даже разрешение пользователям размещать на вашем сайте что-то настолько безобидное, как тег img, может привести к уязвимости XSS. Причина в том, что браузер будет просто слепо запрашивать URL-адрес в атрибуте «src», что может сделать что-то просто раздражающее, такое как выход пользователя из системы, или что-то гораздо более зловещее.

Когда я впервые начал заниматься веб-разработкой десять лет назад, общепринятым подходом было всегда отдавать предпочтение формам POST, а не GET для форм, и именно по этой причине приложение на стороне сервера требует POST для отправки форм. Браузеры все время отправляют запросы GET (как в вышеупомянутом примере тега «img»), но они отправляют запросы POST только при определенных обстоятельствах (в частности, формы с атрибутом «method», установленным в POST). Требуя POST, кажется, вы можете устранить большой сегмент XSS-атак. Является ли это веской причиной для их предпочтения?

Answer 1

С каких это пор REST подразумевал использование GET для всего? Последнее, что я проверил, это означало с точностью до наоборот. Используйте GET-запросы для получения ресурса и POST для отправки одного на сервер.

Одним из ключевых моментов REST является использование HTTP-запросов, которые лучше всего соответствуют операции, которую вы пытаетесь выполнить. GET следует использовать для того, для чего он предназначен: Получение данных с сервера без изменения состояния на сервере. Его не следует использовать для обновления ресурсов на сервере. POST или PUT предназначены для этого.

Использование HTTP в том виде, в котором оно предназначалось для использования, помогает избежать некоторых (но далеко не всех) XSS-атак, а также заставляет браузеры вести себя намного лучше при общении с вашим сайтом. Браузер ожидает, что запросы GET могут быть безопасно повторены, не требуя подтверждения от пользователя. Это то, что он делает, например, если вы обновляете страницу или используете кнопки «назад / вперед». Ожидается, что POST изменит состояние на сервере, поэтому браузер обычно запрашивает подтверждение перед повторением запроса POST.

Answer 2

Я думаю, вы неправильно понимаете REST. Дело не в том, чтобы предпочитать GET, а в POST, а в том, чтобы использовать GET, когда запрос не влияет на данные на сервере, и в POST, где данные модифицируются. REST - это все о том, как правильно использовать доступные глаголы HTTP.

Например, форма поиска часто будет использовать GET, а форма Create X обычно будет использовать POST.

Answer 3

Вы путаете ванильные вызовы Ajax с вызовами REST.

Ванильные Ajax-вызовы используют GET или POST, и вам решать, как их обработать.

REST использует глаголы GET, HEAD, POST, PUT, DELETE

HTTP VERB   REST/CRUD
POST         Create
GET          Read
PUT          Update, Create
DELETE     Delete

Вы хотите использовать POST поверх GET, когда вы беспокоитесь о CSRF, а не XSS.

Хорошее эмпирическое правило всегда используйте POST и используйте GET, только если вы абсолютно уверены, что хотите поделиться этими данными с другими сайтами или данные не являются конфиденциальными.

Но простое использование POST не защитит вас на 100%.

И XSS, и CSRF очень важны, и вы должны рассмотреть свое приложение для обоих, но это два совершенно разных зверя.

CSRF:

Википедия

OWASP

XSS:

OWASP

Answer 4

Уже предоставленные ответы действительно отвечают на ваш вопрос - нет, предотвращение XSS не является веской причиной, чтобы предпочесть POST, а не GET. Однако, если вы хотите продемонстрировать это, воспользуйтесь такими инструментами, как WebScarab или Tamper Data , которые очень полезны для тестирования уязвимостей вашего собственного сайта. Внедрить код в запрос POST так же легко, как и в GET. Однако даже без этих инструментов учтите, что если вы не проверяете POST или GET на стороне сервера, легко отправлять пармы с помощью GET. Просто добавьте, например,? Parm1 = value1 & parm2 = value2 & etc в URL.

Answer 5

XSS не будет остановлен; XSS - это когда пользователь заставляет вас каким-то образом выводить свой сценарий другим пользователям. Это требует фильтрации.

XSRF также не будет остановлен; для этого необходимо добавить одноразовые токены какого-либо рода, чтобы гарантировать, что кто-то сможет зайти на ваш сайт, только если он действительно на нем (а не отправлять сообщения со встроенного iframe и т. п.).

Однако POST против GET не позволяет веб-ускорителям и скреберам (например, Google Bot) изменять ваш сайт. Они переходят только по ссылкам GET, и, таким образом, если вы не хотите, чтобы ваш сайт был удален (например, Daily WTF), убедитесь, что «удалить этот элемент» не является GET. ; -)

Чаще всего это вопрос семантики и размера формы. GET не публикует форму, поэтому ограничен тем, что вы можете поместить в URL, что не так много. POST допускает произвольные объемы данных. PUT и DELETE больше для семантики; и то, и другое можно сделать через POST.

Answer 6

Бывают ситуации, когда вам следует использовать POST, а не GET, но избегание XSS не входит в их число. Возможно, вы думаете о XSRF , но даже тогда требование POST на самом деле вас не защищает. Фактически, сторонники REST на самом деле сказали бы, что вы должны не просто использовать GET, а использовать POST, PUT и DELETE для соответствующих операций " CRUD ".

Чтобы избежать XSS , избегайте и / или очищайте контент от пользователей соответствующим образом.

Чтобы избежать XSRF , требуйте секретные жетоны на любой побочный эффект, который может быть опасным. (Кстати: рекомендуется избегать использования запросов GET при передаче секретных токенов, так как это может привести к их утечке в реферерах.)

По возможности используйте GET для запросов только для чтения . (почти каждый раз, когда запрос может уместиться в URL)

Используйте POST (или PUT или DELETE, если это возможно и целесообразно) для записи запросов.