Как надеждно да защитим публичните 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