Как я ограничиваю доступ JSON?

Обычным методом ограничения доступа к вашему домену является добавление к контенту чего-то, что выполняется бесконечно.

Например:

while(1);{"json": "here"} // google uses this method
for (;;);{"json": "here"} // facebook uses this method

Итак, когда вы получаете это через XMLHttpRequest или любой другой метод, который ограничен исключительно вашим доменом, вы знаете, что вам нужно разобрать бесконечный цикл. Но если он получен через узел сценария:

<script src="http://some.server/secret_api?..."></script>

Он завершится неудачно, потому что сценарий никогда не выйдет за пределы первого оператора.

Я думаю, вы неправильно понимаете ту часть, где запрос JSON инициируется из браузера пользователя , а не с вашего собственного сервера. Статическая HTML-страница доставляется браузеру пользователя, затем он разворачивается и выполняет код Javascript на странице. Этот код открывает новое соединение с вашим сервером для получения данных JSON. С точки зрения вашего PHP-скрипта, запрос JSON приходит откуда-то из внешнего мира.

Учитывая вышеупомянутый механизм, вы мало что можете сделать, чтобы запретить кому-либо вызывать JSON API вне контекста вашей HTML-страницы. .

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

Итак, что мы можем сделать?

Определите здесь слабые места:

http://www.example.com/json/getUserInfo.php?id=443

Теперь злоумышленник может легко запросить всю информацию о пользователе от 1 до 1.000.000 в цикле. Слабым местом идентификаторов auto_increment является их линейность и то, что их легко угадать .

Решение: используйте нечисловые уникальные идентификаторы для ваших данных.

http://www.example.com/json/getUserInfo.php?userid=XijjP4ow

Вы не можете перебрать их. Правда,

Любое решение здесь будет несовершенным, если ваши статические страницы, использующие API, должны находиться в общедоступном Интернете. Поскольку вам нужно иметь возможность, чтобы клиентский браузер отправлял запрос и выполнял его, возможно, почти каждый сможет увидеть, как именно вы формируете этот URL.

Вы можете попросить приложение, стоящее за вашим API, проверить http реферер, но его легко подделать, если кто-то захочет.

Если это не требование, чтобы страницы были статичными, вы можете попробовать что-нибудь, где у вас есть кратковременный «ключ», сгенерированный API и включенный в HTML-ответ первой страницы, который передается в качестве параметра обратно в API. Это добавит накладные расходы на ваш API, хотя вам потребуется, чтобы сервер на этом конце поддерживал список действительных «ключей», как долго они действительны и т. д.

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

Короткий ответ: любой, кто имеет доступ к страницам вашего веб-сайта, также сможет получить доступ к вашему API.

Вы можете попытаться усложнить использование вашего API, зашифруя его в различными способами, но поскольку вам нужно будет включить код JavaScript для расшифровки вывода вашего API, вы просто настроите себя на гонку вооружений со всеми, кто решит, что они хотят использовать ваш API другими способами. Даже если вы используете недолговечные ключи, решительный «злоумышленник» всегда может просто очистить ваш HTML (вместе с текущим ключом) непосредственно перед использованием API.

Если все, что вы хотите сделать, это запретить другим веб-сайтам использовать ваш API на их веб-страницах вы можете использовать заголовки рефереров, но имейте в виду, что не все браузеры отправляют рефереров (и некоторые прокси также удаляют их!). Это значит, что ты' d хотите разрешить все запросы, в которых отсутствует реферер, и это даст вам только частичную защиту. Кроме того, рефереры могут быть легко подделаны, поэтому, если какой-то другой веб-сайт действительно хочет использовать ваш API, он всегда может просто подделать браузер и получить доступ к вашему API со своих серверов.

Извините, может я ошибаюсь, но ... можно ли это сделать с помощью HTTPS?

Вы можете (?) Получить доступ к своему API через http s : //example.com/json/?var1=x&var2=y, поэтому только аутентифицированный потребитель может получить ваши данные ...

Вы или можете ли вы использовать аутентификацию на основе файлов cookie? Мой опыт основан на аутентификации форм ASP.NET, но тот же подход должен быть применим и с PHP с небольшим кодом.

Основная идея заключается в том, что когда пользователь аутентифицируется через веб-приложение, в браузер клиента возвращается файл cookie с зашифрованным значением. Затем json api будет использовать этот файл cookie для проверки личности вызывающего абонента.

Очевидно, что этот подход требует использования файлов cookie, поэтому это может быть для вас проблемой, а может и не быть.