Ответ 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. Таким образом, дезинформированный администратор сервера может открыть дыру на своем собственном сайте, но это не влияет на безопасность других сайтов.