У меня есть некоторые проблемы с пониманием политики одного и того же происхождения и различными способами "обхода".
Понятно, что политика одного и того же происхождения существует как мера безопасности, поэтому один script, который поступает с сервера/домена, не имеет доступа к данным, поступающим с другого сервера/домена.
Также ясно, что иногда полезно иметь возможность нарушить это правило, поэтому, например, приложение mashup обращается к информации с разных серверов, чтобы создать желаемые результаты. И один из способов сделать это - CORS.
1) Если я не ошибаюсь, CORS позволяет целевому серверу говорить в браузере "это нормально для вас взять данные/код от себя", добавив некоторые заголовки в ответ. Но, если это правильно, это означает, что вредоносный сервер может просто добавить этот заголовок, и браузер позволит извлекать любые данные или код, потенциально опасные, исходящие с этого сервера.
2) С другой стороны, у нас есть JSONP, позволяющий извлекать произвольный код или данные с сервера без разрешения CORS, тем самым избегая основной цели SOP. Таким образом, вредоносный сервер, способный управлять JSONP, может вводить данные или код даже с помощью SOP, подключенного в браузере.
Поэтому мои вопросы:
Правильно ли вторая аргументация? Это решение сервера, должен ли браузер принимать содержимое?
Правильно ли вторая аргументация? Это опять же не в решении браузера, принимать или не принимать данные?
Разве JSONP не делает SOP бесполезным?
Спасибо, что просветили меня!!
Политика одного и того же происхождения и CORS - какой смысл?
Ответ 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. script, запущенный в браузере пользователя, за спиной возвращаемого пользователя и разбора http://example.com/pageThatContainsDeleteLink, извлеките txid и затем запросите http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess
Теперь, если XmlHttpRequest не может получить доступ к сайтам, имеющим другое происхождение, единственный способ попытаться получить txid - попытаться сделать что-то вроде:
<script src="http://example.com/pageThatContainsDeleteLink" />
... но это не помогает, поскольку результатом является HTML-страница, а не часть кода JavaScript. Итак, есть причина, по которой вы можете включить <script> : s с других сайтов, но не получить доступ к другим сайтам через XmlHttpRequest.
Вам может быть интересно прочитать это: 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. Таким образом, дезинформированный администратор сервера может открыть дыру на своем собственном сайте, но это не влияет на безопасность других сайтов.