Вопросы Теги

Одинаковая политика происхождения и CORS (совместное использование ресурсов из разных источников)

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

Итак, предположим, что максимальное значение для всех подматриц - x, поэтому мы можем с жадностью выбирать каждый подассемблер в O ( n), так что сумма каждого подмашины максимальна и меньше или равна x. После создания всего подмассива, если количество подматрицы меньше или равно k, поэтому x является одним из возможных решений, или мы увеличиваем x.

Псевдокод: 

int start = Max_Value_In_Array;
int end = Max_Number;

while(start <= end)
   int mid = (start + end)/2;
   int subSum = 0;
   int numberOfSubArray = 1;
   for(int i = 0; i < n; i++){
      if(subSum + data[i] > mid){
          subSum = data[i];
          numberOfSubArray++;
      }else{
          subSum += data[i];
      }
   }
   if(numberOfSubArray <= k)
       end = mid - 1;
   else
       start = mid + 1;

Сложность времени O (n log k) с k - максимально возможная сумма.

29
задан sideshowbarker 2 February 2019 в 09:45
поделиться

2 ответа

Одинаковая политика происхождения (SOP) - это политика, реализуемая браузерами для предотвращения уязвимостей через межсайтовый скриптинг (XSS). Это главным образом для защиты сервера, так как во многих случаях сервер может иметь дело с аутентификацией, файлами cookie, сеансами и т. Д.

Перекрестное распределение ресурсов (CORS) является одним из немногих методов для ослабления СОП. Поскольку SOP по умолчанию включен, установка CORS на стороне сервера позволит отправлять запрос на сервер через XMLHttpRequest, даже если запрос был отправлен из другого домена. Это становится полезным, если ваш сервер предназначен для обслуживания запросов из других доменов (например, если вы предоставляете API).

Я надеюсь, что это проясняет различие между SOP и CORS и целями каждого.

6
ответ дан compid 2 February 2019 в 09:45
поделиться

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

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

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

Как работает атака 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

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

<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>

И браузер попытается загрузить изображение с этого 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 . Например, разные порты для одного и того же домена не имеют одинакового происхождения. Так что браузер может отклонить этот запрос, если порты разные. Как всегда, наш дорогой Internet Explorer является исключением из этого. IE обрабатывает все порты одинаково. Это нестандартно , и ни один другой браузер не ведет себя таким образом. Не полагайтесь на это .

JSONP

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

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

<script src="http://badbakery.com/jsonpurl?callback=cake"></script>

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

Этот 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

2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details

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

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)

84
ответ дан A_P 2 February 2019 в 09:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: