Я не уверен, что я понимаю, какие типы уязвимостей это вызывает.
Когда мне нужно получить доступ к данным из API, я должен использовать ajax для запроса файла PHP на моем собственном сервере, и этот файл PHP обращается к API. Что делает это более безопасным, чем просто позволяя мне ударить API напрямую с помощью ajax?
В этом случае похоже, что с помощью JSONP http://en.wikipedia.org/wiki/JSONP вы можете делать все, что позволит вам сделать междоменный аякс.
Может ли кто-нибудь просветить меня?
Я думаю, вы недооцениваете проблему, которую пытается решить политика одного и того же происхождения.
Imagine that I'm logged into Gmail, and that Gmail has a JSON resource, http://mail.google.com/information-about-current-user.js, with information about the logged-in user. This resource is presumably intended to be used by the Gmail user interface, but, if not for the same-origin policy, any site that я visited, and that suspected that я might be a Gmail user, could run an AJAX request to get that resource as me, and retrieve information about me, without Gmail being able to do very much about it.
Таким образом, политика одинакового происхождения не защищает вашу страницу PHP от стороннего сайта; и не защищать кого-то, посещающего вашу страницу PHP со стороннего сайта; скорее, чтобы защитить кого-то, посещающего вашу страницу PHP, и любых сторонних сайтов, к которым у них есть специальный доступ, со страницы PHP. ( "Особый доступ" может быть из-за куки файлов или HTTP-AUTH или белого адреса IP-адреса или просто находиться в правильной сети. Возможно, кто-то работает в NSA и посещает ваш сайт, это не значит, что вы должны иметь возможность запускать дамп данных с внутренней страницы NSA.)
JSONP обходит это безопасным способом, вводя другое ограничение: оно работает только в том случае, если ресурс JSONP. Поэтому, если Gmail хочет, чтобы данный ресурс JSON мог использоваться третьими лицами, он может поддерживать JSONP для этого ресурса, но если он хочет, чтобы этот ресурс мог использоваться его собственным пользовательским интерфейсом, он может поддерживать только простой JSON.
Многие веб-службы не построены, чтобы сопротивляться XSRF, поэтому, если веб-сайт может программно загружать пользовательские данные через запрос, куки домена только в силу того, что пользователь посетил сайт, любой, у кого есть возможность запускать javascript, может украсть пользовательские данные.
CORS - плановая безопасная альтернатива XHR, которая решает проблему не несет учетные данные по умолчанию. Спецификация CORS объясняет проблему:
Пользовательские агенты обычно применяют ограничения одного и того же происхождения к сетевым запросам. Эти ограничения не позволяют веб-приложению на стороне клиента работать от одного источника от получения данных, полученных из другого источника, а также ограничить небезопасные HTTP-запросы, которые могут автоматически запускаться по направлениям, которые отличаются от исходного запуска приложения.
В пользовательских агентах, которые следуют этому шаблону, сетевые запросы обычно используют информацию об окружающей среде и информацию управления сеансом, включая HTTP-аутентификацию и информацию о файлах cookie.
EDIT:
Проблема только в том, что XHR работает в кросс-домене, так это то, что многие веб-службы выставляют окружение. Обычно этот орган доступен только для кода из того же источника.
Это означает, что пользователь, который доверяет веб-сайту, доверяет всему коду с этого сайта своими личными данными. Пользователь доверяет серверу, которому они отправляют данные, и любому коду, загружаемому страницами, обслуживаемыми этим сервером. Когда люди, стоящие за сайтом и загружаемыми им библиотеками, заслуживают доверия, доверие пользователя хорошо размещено.
Если XHR работал с перекрестным происхождением и несли куки файлы, этот источник полномочий мог бы быть доступен для кода любому, кто может служить для пользователя. Решения о доверии, которые ранее сделал пользователь, больше не могут быть хорошо размещены.
CORS не наследует эти проблемы, потому что существующие службы не выставляют окружающую среду CORS.
Образец JS->Server(PHP)->API позволяет и не только лучше всего, но и существенно практиковать здравомыслие - проверяйте, что вы получаете, пока он проходит через сервер. В дополнение к этому, такие вещи, как атакованные локальные резольверы (ака DNS Worms) и т.д., Гораздо менее вероятны на сервере, чем на случайном клиенте.
Что касается JSONP: Это не трость, а костыль. IMHO это можно рассматривать как эксплойт против несовместимости комбо HTML/JS, который нельзя удалить без нарушения существующего кода. Другие могут подумать об этом.
В то время как JSONP позволяет, чтобы вы безответственно выполняли код из somwhere в плохом глобальном мире, никто не принуждает вас. Существенные реализации JSONP всегда используют какое-то хэширование и т.д., Чтобы проверить, что поставщик этого кода является надежным. Опять другие могут подумать иначе.
С помощью межсайтового скриптинга у вас будет веб-страница, которая сможет извлекать данные из любого места, а затем сможет работать в том же контексте, что и ваши другие данные на странице, и теоретически иметь доступ к файлам cookie и другим которые вы не хотели бы получать. Скрипты между сайтами будут очень неуверенными в этом отношении, так как вы сможете перейти на любую страницу, и если разрешено script на этой странице, можно просто загружать данные из любого места, а затем запускать неправильный код, следовательно, причина, по которой это запрещено.
JSONP с другой стороны позволяет вам получать данные в формате JSON, потому что вы предоставляете необходимый обратный вызов, чтобы данные передавались, следовательно, он дает вам меру контроля в том, что данные не будут выполняться браузером, если функция обратного вызова делает и выполняет или пытается выполнить его. Данные будут в формате JSON, и вы сможете делать все, что пожелаете, однако оно не будет выполнено, поэтому оно безопаснее и, следовательно, причина, по которой это разрешено.
оригинальный XHR никогда не был разработан, чтобы разрешать запросы с кросс-началом. Причина заключалась в ощутимой уязвимости безопасности, которая в основном известна атакам CSRF.
В этом сценарии атаки сторонний сайт может заставить агента пользователя жертвы отправлять поддельные, но действительные и законные запросы на исходный сайт. С точки зрения исходного сервера такой кованый запрос не является неразличимым из других запросов этого пользователя, которые были инициированы веб-страницами исходных серверов. Причиной этого является то, что он фактически является агентом пользователя, который отправляет эти запросы, и он также автоматически включал бы любые учетные данные, такие как файлы cookie, HTTP-аутентификация и даже сертификаты SSL на стороне клиента.
Теперь такие запросы могут быть легко подделаны: начиная с простых запросов GET, используя <img src="…"> через POST-запросы, используя формы и автоматически отправляя их. Это работает до тех пор, пока его предсказуемо, как создавать такие действительные запросы.
Но это не главная причина запрещать запросы кросс-происхождения для XHR. Поскольку, как показано выше, существуют способы подделывать запросы даже без XHR и даже без JavaScript. Нет, основная причина, по которой XHR не разрешала запросы с кросс-началом, заключается в том, что это был бы JavaScript на веб-странице третьей стороны, на который был отправлен ответ. Таким образом, было бы невозможно отправлять запросы с кросс-началом, а также получать ответ, который может содержать конфиденциальную информацию, которая затем будет доступна для JavaScript.
Вот почему оригинальная спецификация XHR не разрешала запросы на кросс-начало. Но по мере того, как технология продвигается вперед, существуют разумные запросы на поддержку запросов на перекрестное происхождение. Вот почему оригинальная спецификация XHR была расширена до XHR level 2 (теперь XHR и XHR уровень 2), где основное расширение поддерживает кросс- запросы происхождения по особым требованиям, которые указаны как CORS. Теперь сервер имеет возможность проверить происхождение запроса и также может ограничить набор разрешенных источников, а также набор разрешенных HTTP-методов и полей заголовков.
Теперь для JSONP: Чтобы получить ответ JSON запроса в JavaScript и иметь возможность обрабатывать его, он должен либо быть запросом одного происхождения, либо, в случае запроса на перекрестный исход, ваш сервер и пользовательскому агенту необходимо будет поддерживать CORS (из которых последний поддерживается только современными браузерами). Но чтобы иметь возможность работать с любым браузером, был изобретен JSONP, который является просто действительным вызовом функции JavaScript с JSON в качестве параметра, который может быть загружен как внешний JavaScript через <script>, который, подобно <img>, не ограничен к запросам одного и того же происхождения. Но, как и любой другой запрос, запрос JSONP также уязвим для CSRF.
Итак, чтобы сделать это с точки зрения безопасности:
Но также: