Каковы риски безопасности при использовании междоменного XMLHttpRequest?

#ajax #security #xmlhttprequest #cross-domain

#ajax #Безопасность #xmlhttprequest #междоменный

Вопрос:

Во многих местах, которые я видел, люди говорили о междоменном XMLHttpRequest, который невозможен из-за некоторых соображений безопасности. Однако я не нашел сообщения, указывающего, каковы на самом деле эти причины безопасности?

Люди упоминали, что JSONP является одной из хороших альтернатив. Другой альтернативой было бы использование Origin Access-Control-Allow-Origin заголовков and .

Однако я просто хочу знать, какие проблемы безопасности могут возникнуть из-за использования междоменного XMLHttpRequest?

Ответ №1:

Я думаю, было бы лучше ответить на ваш вопрос о примере ТОГО, ПОЧЕМУ это было бы ужасно плохо.

Вы заходите на мой сайт (example.org ). Я загружаю скрипт, который отправляет AJAX-запрос на стороне клиента в facebook.com/messages/from/yourgirlfriend . Вы случайно вошли в Facebook, и ваш браузер сообщает Facebook, что мой запрос на самом деле принадлежит вам. Facebook с радостью передает на мой запрос сообщение о странных сексуальных вещах, которые вы хотите попробовать. Теперь я знаю о вас то, что вы, вероятно, не хотели, чтобы я знал.

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

Разве вы не чувствуете себя в безопасности сейчас?

Ответ №2:

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

Ни одна веб-страница не может иметь аутентификации без этих правил, google, учетных записей веб-почты, поэтому ничего из этого не может существовать. Это было бы так, как если бы у вас был XSS в каждом домене. Вы могли бы выполнить XHR против gmail.com и читайте чью-нибудь электронную почту. Токены CSRF не будут работать, потому что вы можете прочитать любую страницу и подделать запрос.

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

Выполняя a Access-Control-Allow-Origin: * , вы лишаетесь своих прав, предоставленных вам веб-браузерами для этой страницы. Это имеет серьезные последствия для безопасности. Вы не сможете защитить себя от CSRF с помощью токенов. capthca может смягчить эту проблему, также может помочь проверка референта (он будет пустым, если источником является HTTPS). Вам следует прочитать шпаргалку по предотвращению CSRF.

Ответ №3:

Если это было разрешено, злоумышленник, которому удалось внедрить Javascript на вашу страницу (с помощью эксплойта / социальной инженерии), может отправлять данные (обычно конфиденциальные), полученные от ваших клиентов, без их ведома (поскольку XMLHttpRequests не требуют действий пользователя, и они молчат). Это мера безопасности браузера.

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

РЕДАКТИРОВАТЬ: Примеры угрозы безопасности: вы входите в свою учетную запись электронной почты через Интернет (например, gmail или yahoo). Вы продолжаете просмотр (на другой вкладке или даже на текущей вкладке) другого вредоносного сайта. Этот вредоносный сайт пытается выполнить XHR на том же веб-сайте вашей учетной записи электронной почты. Поскольку XHR находится в вашем поведении, и поскольку это запрос на стороне клиента / браузера, этот запрос будет иметь тот же сеанс, который вы использовали для входа в систему, и, следовательно, этот веб-сайт может делать с вашей учетной записью все, что захочет (отправлять спам через вашу учетную запись, загружать ваши контакты и т. Д.). Другой пример: на форуме кому-то удается внедрить Javascript с помощью XHR на другой веб-сайт. Теперь он может украсть список контактов (и, возможно, затем удалить их) у всех людей, которые посещают его сообщение на форуме (используя тот же сеанс вашей электронной почты). Не говоря уже о том, что он может поделиться сеансом участников форума, посещающих его сообщение, чтобы получить любые данные, которые у них есть на форуме (личные сообщения / друзья .. и т. Д.). Затем он может отправить эти данные на свой сервер, чтобы сохранить их.