Как надежно защищать публичные запросы JSONP?

Я пытаюсь найти, есть ли хороший способ предотвратить использование CSRF в виджетах javascript, встроенных на веб-сайты клиентов.

Виджет позволит конечным пользователям делать запросы против учетных записей наших клиентов через JSONP на сервер PHP, который проксирует эти запросы для нашего (непубличного) API.

К этому моменту я не придумал верный способ обеспечить, чтобы все запросы поступали только с сайтов наших клиентов. Некоторые идеи, которые у меня были:

Токены, сгенерированные на стороне сервера, и переданные вместе с каждым последующим запросом JSONP (не уверены, как аутентифицировать первоначальный запрос, поскольку, поскольку первый токен был доступен для чтения в JS, и каждый может запросить "следующий" токен)
Проверка заголовка Referer (ненадежная, может быть подделана или просто не передана браузером)
Использование SSL (конечно, поможет, но не решает проблему CSRF)

Возможно ли это? Я встретил виджет Fotomoto, который, похоже, позволяет использовать тот же тип функциональности, который мы ищем, но не уверен, как они это делают.

Ответ 1

Вы никогда не найдете решение, гарантирующее, что запросы, поступающие от случайных третьих сторон (пользователей), фактически инициируются путем доступа к веб-сайту ваших клиентов. Если ваша безопасность зависит от этого, тогда вам нужно удалить это предположение. (Если вы действительно имеете в виду "убедитесь, что запросы поступают только с серверов наших клиентов", это тривиально: SSL с сертификатами на стороне клиента. Но я предполагаю, что вы имеете в виду "исходящие из случайных пользовательских машин с намерением использовать наших клиентов", сайты ".)

Что вы должны искать, как запретить пользователям обманывать (CSRF). Так, например, тот факт, что Referer может быть подделан, не имеет значения для этой проблемы. Вопрос только в том, есть ли браузер, у которого есть недостаток, который позволит третьей стороне обмануть пользователя в создании поддельного Referer. Поэтому вы должны проверить Referer как необходимый, но недостаточно. То есть, если Referer ошибается, повесьте трубку на вызывающем устройстве. Но тот факт, что Referer прав, не означает, что вы действительно получаете законный запрос. Большинство CSRF, я считаю, связано с неспособностью проверить Referer, а не ошибки браузера.

Статья в Википедии о CSRF содержит приличное резюме очевидных методов профилактики. Просто проверка Referer - это большой первый шаг.

Ответ 2

По определению это "запрос на кросс-сайт". Важно отметить, что независимо от того, является ли запрос CSRF уязвимостью, в значительной степени зависит от того, что делает запрос. Например, если злоумышленник может заставить клиента сделать запрос на поиск, это, вероятно, не сделает ничего полезного для злоумышленника. Если злоумышленник может изменить пароль администратора, у вас возникнет очень серьезная проблема.

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