политика одного и того же происхождения и CORS-в чем смысл?

У меня есть некоторые проблемы с пониманием политики одного и того же источника и различных способов ее "обхода".

Очевидно, что политика одного и того же источника существует в качестве меры безопасности, поэтому один сценарий, который приходит с сервера/домена, не имеет доступа к данным, поступающим с другого сервера/домена.

Также ясно, что иногда полезно иметь возможность нарушить это правило, поэтому, например, приложение mashup обращается к информации с разных серверов для создания результатов разыскиваемый. И один из способов сделать это-Корс.

1) Если я не ошибаюсь, CORS позволяет целевому серверу сказать браузеру "это нормально для вас, чтобы взять данные/код от себя", добавив некоторые заголовки в ответ. Но, если это верно, это означает, что вредоносный сервер может просто добавить этот заголовок, и браузер разрешит извлечение любых данных или кода, потенциально опасных, поступающих с этого сервера.

2) с другой стороны, у нас есть JSONP, что позволяет нам извлечение произвольного кода или данных с сервера без включения CORS, что позволяет избежать основной цели SOP. Таким образом, вредоносный сервер, способный управлять JSONP, может вводить данные или код даже с помощью SOP, встроенного в браузер.

Итак, мои вопросы таковы:

Верна ли вторая аргументация? Является ли это решением сервера, должен ли браузер принимать содержимое? Верна ли вторая аргументация? Это, опять же, не в решении браузера принимать или нет данные?

Не лежит предположение оказать СОП бесполезно?

Спасибо, что просветили меня!!

1 18
cors same-origin-policy

1 ответ:

Здесь важно отметить, что если пользователь вошел на сайт http://example.com/ и запрос http://example.com/delete?id=1 удаляет сообщение пользователя, а затем следующий код удаляет сообщение пользователя: 

<script src="http://example.com/delete?id=1" />
Это называется CSRF / XSRF-атакой (подделка межсайтовых запросов). Вот почему большинство серверных веб-приложений требуют тикет транзакции: вместо http://example.com/delete?id=1 Вы должны сделать http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Теперь следующая атака не сработает: 

<script src="http://example.com/delete?id=1" />

...потому что он не содержит параметр txid. Теперь давайте рассмотрим, что произойдет, если к сайту можно будет получить доступ с помощью XmlHttpRequest. Скрипт, запущенный в браузере пользователя, может за спиной пользователя извлекать и анализировать http://example.com/pageThatContainsDeleteLink , извлеките txid и затем запросите http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

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

<script src="http://example.com/pageThatContainsDeleteLink" />

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

Возможно, вам будет интересно почитать это: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Эта атака сработала против Gmail еще в тот день и позволила вам получать почту пользователя из кода JavaScript, запущенного на другом сайте. Все это показывает, что модель безопасности WWW очень тонкая и не очень хорошо продуманная. Он эволюционировал вместо того, чтобы быть хорошо спроектированным.

Что касается вашего вопроса: Вы, кажется, думаете, что сервер http://example.com/ является злонамеренным один. Но это не так. Используя обозначения моего ответа, http://example.com/ - сервер, являющийся целью атаки, и http://attacker.com/ - это сайт злоумышленника. Если http://example.com/ открывает возможность отправлять запросы с помощью JSONP или CORS, правда, он может стать уязвимым для атаки CSRF/XSRF, которую я только что описал. Но это не означает, что другие сайты станут уязвимыми для атаки. Аналогично, если http://attacker.com/ открывает возможность отправлять запросы с помощью JSONP или CORS, сайт злоумышленника только что стал уязвимым для CSRF / XSRF-атаки. Таким образом, дезинформированный администратор сервера может открыть дыру в своем собственном сайте, но это не влияет на безопасность других сайтов.

12