Соединение строкового индексного массива в JavaScript

Политика того же происхождения

Что это такое?

Политика того же происхождения является мерой безопасности, стандартизированной среди браузеров. «происхождение» в основном относится к «домену» . Он не позволяет различным источникам взаимодействовать друг с другом, чтобы предотвратить атаки, такие как Подделка межсайтовых запросов .

Как работает атака CSRF?

Браузеры позволяют веб-сайтам хранить информацию на компьютере клиента в виде файлов cookie. К этим cookie-файлам прикреплена некоторая информация, например, имя cookie-файла, когда он был создан, когда он истекает, кто установил cookie-файл и т. Д. Cookie выглядит примерно так:

Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]

Итак, это шоколадное печенье, которое должно быть доступно с http://bakery.com и всех его поддоменов.

Этот файл cookie может содержать некоторые конфиденциальные данные. В этом случае эти данные ... chocolate. Как вы видите, очень чувствительны.

Так что браузер сохраняет этот куки. И всякий раз, когда пользователь отправляет запрос в домен, в котором этот файл cookie доступен, файл cookie отправляется на сервер для этого домена. Счастливый сервер.

1149 Это хорошо. Супер крутой способ для сервера хранить и извлекать информацию на стороне клиента и от нее.

Но проблема в том, что это позволяет http://malicious-site.com отправлять эти куки на http://bakery.com , без пользователя зная! Например, рассмотрим следующий сценарий:

# malicious-site.com/attackpage

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();

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

Это произошло потому, что ваш браузер отправил ваше шоколадное печенье на http://bakery.com , что заставило http://bakery.com думать, что вы ] делают запрос на новый заказ, сознательно . Но это не так.

Это, проще говоря, атака CSRF. Поддельный запрос был сделан через сайты. «Подделка межсайтовых запросов». И это не сработает, благодаря политике того же происхождения.

Как политика того же происхождения решает эту проблему?

Запрещает вредоносному сайту отправлять запросы другим доменам. Простой.

Другими словами, браузер не позволяет любому сайту делать запрос на любой другой сайт. Это помешало бы различным источникам взаимодействовать друг с другом посредством таких запросов, как AJAX.

Однако , загрузка ресурсов с других хостов, таких как изображения, скрипты, таблицы стилей, фреймы, отправка форм и т. Д., Не подпадает под это ограничение. Нам нужна еще одна стена для защиты нашей пекарни от вредоносного сайта с помощью CSRF Tokens .

CSRF Tokens

Как уже говорилось, вредоносный сайт все еще может делать что-то подобное, не нарушая политику того же происхождения:

И браузер попытается загрузить изображение с этого URL, в результате чего запрос GET на этот URL отправляет все файлы cookie. Чтобы этого не случилось, нам нужна защита на стороне сервера.

По сути, мы присоединяем случайный уникальный маркер подходящей энтропии к сеансу пользователя, сохраняем его на сервере, а также отправляем его клиенту с помощью формы. Когда форма отправляется, клиент отправляет этот токен вместе с запросом, и сервер проверяет, является ли этот токен действительным или нет.

Теперь, когда мы сделали это, и вредоносный веб-сайт отправляет запрос снова, он всегда будет отказывать, поскольку у вредоносного веб-сайта нет никакого способа узнать токен для сеанса пользователя.

---

CORS

При необходимости политику можно обойти, когда требуются межсайтовые запросы. Это известно как CORS . Обмен ресурсами между источниками.

Это работает, когда «домены» сообщают браузеру о необходимости охлаждения и разрешают такие запросы. Эту «говорящую» вещь можно сделать, передав заголовок. Примерно так:

Access-Control-Allow-Origin: //comma separated allowed origins list, or just * Так что если http://bakery.com передает этот заголовок браузеру и странице, создающей запрос, на http: // bakery. com присутствует в списке источников, затем браузер пропустит запрос вместе с файлами cookie.

Существуют правила, согласно которым источник определяется как ^{1 sup>. Например, разные порты для одного и того же домена не имеют одинакового происхождения. Так что браузер может отклонить этот запрос, если порты разные. Как всегда, наш дорогой s> Internet Explorer является исключением из этого. IE обрабатывает все порты одинаково. Это нестандартно , и ни один другой браузер не ведет себя таким образом. Не полагайтесь на это .}

JSONP

JSON with Padding - это просто способ обойти политику одного и того же происхождения, когда CORS не является опцией. Это рискованно и плохая практика. Избегайте этого.

Этот метод включает в себя запрос к другому серверу, например, следующим образом:

Поскольку политика того же источника не предотвращает это ^{2 sup> запрос, ответ на этот запрос будет загружен на страницу.}

Этот URL, скорее всего, отвечал бы содержимым JSON. Но просто включение этого JSON-контента на страницу не поможет. Это приведет к ошибке, конечно. Поэтому http://badbakery.com принимает параметр обратного вызова и изменяет данные JSON, отправляя их в виде того, что передается параметру обратного вызова.

Таким образом, вместо возврата,

{ user: "vuln", acc: "B4D455" }

, который является недопустимым JavaScript и выдает ошибку, будет возвращаться,

cake({user: "vuln", acc:"B4D455"});

это допустимый JavaScript, он будет выполнен и, вероятно, где-то сохранен в соответствии с функцией cake, так что остальная часть JavaScript на странице может использовать данные.

Это в основном используется API для отправки данных в другие домены. Опять же, это плохая практика, она может быть рискованной, и ее следует строго избегать.

Почему JSONP плох?

Прежде всего, он очень ограничен. Вы не можете обработать любые ошибки, если запрос терпит неудачу (по крайней мере, не нормальным способом). Вы не можете повторить запрос и т. Д.

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

Наконец, вы вставляете случайный код JavaScript в DOM. Если вы не уверены на 100%, что удаленная служба вернет безопасные пироги, вы не можете полагаться на это.

Список литературы

^{1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin sup>}

^{2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details sup>}

Другие достойные чтения

http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html

http://tools.ietf.org / html / rfc3986 (извините: p)

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

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