Как надежно защитить публичные запросы JSONP? - PullRequest
Новая
       16

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

3 голосов
/ 29 августа 2011

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

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

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

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

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

Ответы [ 2 ]

1 голос
/ 30 августа 2011

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

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

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

1 голос
/ 30 августа 2011

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

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

...