Почему можно предотвратить угон json с помощью метода POST?

Question

Я обнаружил следующую ошибку ASP. NET MVC при возврате json в методе Get:

Этот запрос был заблокирован, поскольку конфиденциальная информация могла быть раскрытым сторонним веб-сайтам, когда это используется в запросе GET. Чтобы разрешить запросы GET, установите JsonRequestBehavior на AllowGet.

Очевидно, эта уязвимость называется json Hijacking . В этой статье объясняется, что веб-сайт может быть использован при возврате json с использованием Get. Но возвращение json в методе Post безопасно.

Почему изменение Get на Post предотвращает эту атаку?

Answer 1

Я был очень удивлен, увидев, что так много людей пытаются доказать, что JSON Взлом по-прежнему является проблемой безопасности. (Конечно, если вы все еще используете Firefox 2, Opera 9 или Safari 3). Ни в одном из современных браузеров давно не возникает этой проблемы. Статья, на которую вы ссылаетесь в своем вопросе, написана в 2009 году. Вы можете проверить это сообщение для получения дополнительной информации о том, как проблема была исправлена. И вам не нужно беспокоиться о JsonRequestBehavior, просто позвольте получить и забыть.

ОБНОВЛЕНИЕ

Извините, я не читал вопрос о награде. Почему изменение запроса на публикацию предотвращает угон json?

Вы можете найти статью здесь , в которой описаны шаги атаки JSON Hijacking. Это выглядит следующим образом:

• Шаг 1 : Получите аутентифицированного пользователя для посещения вредоносной страницы.

• Шаг 2 : Вредоносная страница будет пытаться получить доступ к конфиденциальным данным из приложения, в которое вошел пользователь. Это можно сделать путем встраивания тега сценария на страницу HTML , поскольку политика одного и того же происхождения не применяется к тегам сценария. .

  <script src="http://<jsonsite>/json_server.php"></script>

  Браузер сделает запрос GET на json_server. php, и любые файлы cookie аутентификации пользователя будут отправлены вместе с запросом.

  ...

Вы можете думать об этом сценарии так: пользователь посещает www.yoursite.com и проходит аутентификацию. После этого пользователь ушел с вашего сайта и go на вредоносный сайт. Если на вредоносном сайте есть тег <script src="http://www.yoursite.com/some_endpoint"></script>, браузер сделает GET-запрос. Если возвращаемые данные - JSON, этот сайт может получить конфиденциальные данные с помощью установщика прототипа объекта. (Помните, что злоумышленники будут пытаться использовать тег SCRIPT, а не запрос AJAX, потому что политика одного и того же происхождения не применяется к тегам сценария. См. Правила доступа к сети между разными источниками .)

Но если вы меняете тип запроса http://www.yoursite.com/some_endpoint с GET на POST, когда браузер пытается получить к нему доступ, ваш сервер отклоняет его.

Также я оставляю старую книгу MVC Framework здесь поясняет концепцию.

Answer 2

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

Обновленный ответ :

На самом деле вы не найдете источника, который сообщает вам, чем GET, POST запросы отличаются для JSON Hijacking атак. На самом деле разница в том, как веб-серверы и браузеры обрабатывают эти запросы. Уязвимость JSON захвата касается вредоносных веб-сайтов, использующих конечную точку на вашем веб-сайте / приложении, которая предоставляет JSON данные и ответ на GET запрос ( запрос, который по умолчанию разрешает ресурсы, например js, изображения, текстовые файлы для загрузки ), если вы измените его на POST, они не смогут включать <script>, которые выполняют запрос POST из атрибута src, даже внутри тега скрипта POST запросы будут предотвращены политикой CORS.

В эпоху современных браузеров у нас больше нет этого типа уязвимости (по крайней мере, в форме, упомянутой в статье об обнаружении Джереми Гроссманом) , потому что политики CORS.

Это также упоминается в других связанных вопросах

Answer 3

Если вы откроете сетевую панель на любой веб-странице, содержащей сценарии, изображения, таблицы стилей или шрифты, вы увидите, что все эти запросы выполняются с использованием метода GET HTTP. Например, так выглядит запрос файла, загруженного тегом <script>:

А это пример загруженного файла по тегу <img> выглядит так:

Браузер просто слепо поверит вам, что если вы загружаете такой ресурс откуда угодно, вы знаете, что вы выполняются, и он получит его для вас (иначе такие вещи, как CDN, не будут работать) в отличие от запроса XHR !

Запросы XHR (включая fetch вызовы) проверяются на соответствие CORS политика, я полагаю, вы знакомы с тем, что это такое. JavaScript не сможет выполнять какие-либо запросы XHR для ресурса, который находится в другом домене (или порте et c.).

Итак, у вас есть два типа политик запросов:

1. Все, что вы получаете с помощью XHR, будет проверено на соответствие CORS, но вы можете выбрать любой метод HTTP-запроса, который хотите
2. Все, что вы загружаете, используя img, script, link et c не будет проверяться на соответствие политике CORS , но вы ограничены GET только HTTP-запросами . Браузер также отправит все файлы cookie, в данном случае в первую очередь файлы cookie.

Это означает, что если вы обслуживаете массив JSON, используя GET, вы можете использовать script тег, чтобы получить его для вас независимо от того, в каком домене вы находитесь . Затем, используя трюк, упомянутый в статье, вы можете выполнить массив (звучит странно, но да) и получить конфиденциальную информацию.

Если вы используете POST, злоумышленник не может использовать тег script (или любой другой) для выполнения этого запроса, поскольку он использует запросы GET для извлечения ресурсов.

Вы могли подумать А, но я могу использовать form для этого! , но вы столкнетесь с теми же проблемами CORS. Если вы просто отправите form, данные JSON загрузятся на текущую страницу, и вы, как злоумышленник, не сможете получить их, поскольку ваш скрипт больше не существует на странице.

Вы мог подумать А, я просто установил цель form на iframe! , но JavaScript не позволит вам получить доступ к чему-либо в этом iframe.

Имеет ли это смысл ?

Answer 4

JSON не следует возвращать как GET, потому что данные могут быть украдены с помощью введенного <script> от злоумышленника (например, если содержимое Dynami c загружается без экранирования HTML). Сценарии запрашиваются с сервера с помощью метода GET, поэтому все, что отправлено с сервера с помощью POST, не будет запущено из внедренного сценария. Когда их скрипт запущен, хакер может использовать вашего вошедшего в систему cook ie для доступа к вашему JSON, который им не должен быть разрешен.

Подробнее о JSON уязвимостях взлома эта статья и этот ТАК ответ .