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

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

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

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

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

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


security csrf jsonp
person sheldonbaker    schedule 29.08.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Rob Napier    schedule 29.08.2011

arrow_upward
1
arrow_downward

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

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

person rook    schedule 29.08.2011