Актуальны ли межсайтовые атаки с использованием ajax?

avatar
i.brod
8 апреля 2018 в 09:43
744
2
-1

Я создаю приложение React с бэкендом PHP(Codeigniter).

Поскольку Codeigniter, похоже, не решает эту проблему автоматически, я начал исследовать эту тему. Я понимаю, почему пользовательский ввод должен экранироваться перед отображением на HTML-странице, но вопрос в том, следует ли это делать в приложении, которое полагается исключительно на AJAX.

Я попытался вывести эту строку внутри HTML-элемента в компоненте React после получения запроса ajax:

<script>alert('hey');</script>  

В итоге это была просто буквальная строка в HTML. Конечно, JS не выполнялся.

Есть ли ситуации, когда такая строка может быть выполнена, даже если она была извлечена из ajax JSON?

Источник
Praveen Kumar Purushothaman
8 апреля 2018 в 09:44
0

Браузер останавливает его выполнение.

i.brod
8 апреля 2018 в 09:48
0

Правин: Так я могу полностью игнорировать проблему?

Praveen Kumar Purushothaman
8 апреля 2018 в 09:48
0

Я действительно так считаю. Есть ли у вас случай, когда вы таким образом включаете скрипт из другого домена, и он выполняется?

i.brod
8 апреля 2018 в 09:53
0

Нет, я не знаю. Но я тоже неопытный..

Praveen Kumar Purushothaman
8 апреля 2018 в 09:54
0

Я собираюсь оставить это как есть. Подождем ответов других специалистов.

i.brod
8 апреля 2018 в 09:56
0

Самое скромное, что я читал на этом сайте :D

Praveen Kumar Purushothaman
8 апреля 2018 в 09:56
0

Ха-ха... Я не понял? Извините, что вы имели в виду?

i.brod
8 апреля 2018 в 09:57
1

Я имею в виду, что на этом сайте редко можно увидеть скромность :-)

Praveen Kumar Purushothaman
8 апреля 2018 в 09:58
0

Хорошо, только что получил некоторую информацию для вас. Насколько я знаю, браузер, когда он запрашивает контент AJAX с другого сайта, будет рассматриваться как межсайтовый скриптинг или XSS. Когда браузер подозревает, что это может быть потенциально уязвимо для пользователя, а также из другого домена, отличного от текущего домена, он прекращает выполнение JavaScript или подобных вещей. :) Так что я действительно считаю, что это безопасно с современными браузерами, но я действительно не уверен со старыми, если вы нацелились на них. :)

i.brod
8 апреля 2018 в 10:07
0

Понимаю. Следует отметить одну вещь: мой внутренний API не находится в другом домене. Сервер, который обслуживает файлы, тот же, что и API.

Praveen Kumar Purushothaman
8 апреля 2018 в 10:12
0

Рассматривали ли вы возможность использования Cross Origin? Посетите Enable-CORS.com, и это может привести вас в правильном направлении.

Ответы (2)

avatar
Veshraj Joshi
8 апреля 2018 в 10:34
0

Я думаю, что вы понимаете Cross Site Scripting (CSS) иначе, CSS не может быть автоматически предотвращено любым языком программирования. На самом деле, в CSS код javascript был сохранен в базе данных и отображался при отображении, сохраненный код может иметь вызов ajax и отправлять данные на какой-либо другой сайт с данными ваших файлов cookie.

Не будет никаких проблем, если вы распечатаете сохраненный код как есть. Если вы напечатаете свое значение json, например echo json_enocde($apiArray), тогда ваш код не будет выполнен, даже если ваш API вызывается без ajax (путем нажатия URL-адреса), потому что код скрипта скрывается в браузере (вы можете проверить это).

Да, ваш код может быть выполнен, если вы привяжете возвращаемое значение ajax как HTML. Вот почему фреймворки javascript печатают возвращаемые значения ajax как есть, и вам нужно явно писать код для привязки html-кода. Если вы привяжете свое значение ajax.

см. как связать html в reactjs в этом случае ваш код может быть выполнен.

В php есть функция htmlentities($values_that_need_to_be_printed_with_script_tag), которая печатает ваш код как есть, это не позволяет браузерам отображать код javascript.

Самая простая вещь, чтобы предотвратить CSS(corss site scripting), — это печатать ваши данные как есть — не позволяйте вашему браузеру отображать ваш код, хранящийся в базе данных.

Veshraj Joshi
8 апреля 2018 в 10:38
0

дайте мне знать, полезно ли это для вас или нет? если нет, я предоставлю вам больше ресурсов.

i.brod
8 апреля 2018 в 12:23
0

Хм, я все еще немного смущен этим :D

avatar
Conal Mittal
8 апреля 2018 в 10:15
0

Хорошей практикой является экранирование тегов в бэкенде перед их отправкой во внешний интерфейс.

Возьмем пример:

Допустим, вы звоните http://example.com/get.php?userInput=< script >alert('hi');</script >

Ожидаемый вывод вышеуказанного запроса: "< script >alert('hi');< /script >".

Теперь вызов ajax преобразует его в строковый литерал, и он не выполняется в том месте, где он потребляется, но если пользователь напрямую посещает вышеуказанный URL-адрес, он будет отображаться как HTML, и вышеуказанный скрипт будет выполнен. В этом случае атакуемый все еще может украсть cookie или выполнить другую вредоносную работу.

i.brod
8 апреля 2018 в 12:15
0

Очень интересный пример...не думал об этом

Gabor Lengyel
8 апреля 2018 в 22:57
0

Много раз, особенно с современными одностраничными приложениями, реализация кодирования на сервере является антишаблоном. В большинстве случаев лучше отправлять данные клиенту как есть (закодированные в формат передачи, т.е. json, очевидно), а затем клиент может решить, какая дополнительная кодировка ему нужна, в зависимости от того, где она будет использоваться. Дело в том, что это не обязательно html-кодировка, и сервер не должен знать об этом. Конечно, частичный html должен быть экранирован. Если тип содержимого text/json и x-content-type-options: nosniff отправлен, прямой доступ не будет уязвим.