Не слишком ли это сложно, если я добавлю защиту от преднамеренных правонарушений пользователя (мягко говоря), если вред, который может принести пользователь, не связан с моим кодом?
Для пояснения я представляю простой сервис JSON RESTful, например:
GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item
Сама служба предназначена не для использования через браузер, а только из сторонних приложений, управляемых пользователем (таких как телефонные приложения, настольные приложения и т. Д.). Кроме того, сама служба должна быть без сохранения состояния (то есть без сеанса).
Аутентификация выполняется с помощью базовой аутентификации по SSL.
Я говорю об одном возможном «вредном» поведении, подобном этому:
Пользователь вводит URL-адрес GET в браузере (без причины, но ...). Браузер запрашивает базовую аутентификацию, обрабатывает ее и сохраняет аутентификацию для текущего сеанса просмотра. Не закрывая браузер, пользователь посещает вредоносный веб-сайт с вредоносным JavaScript- кодом CSRF / XSRF, который отправляет POST в наш сервис.
Приведенный выше сценарий крайне маловероятен, и я знаю, что с точки зрения бизнеса мне не стоит слишком беспокоиться. Но ради улучшения ситуации, думаете ли вы, что если имя пользователя и пароль требуются и для данных JSON POST, это поможет?
Или я должен вообще отказаться от Basic Auth, избавиться от GET и использовать только POST / PUT с информацией об авторизации в них? Поскольку информация, полученная через GET, также может быть конфиденциальной.
С другой стороны, считается ли использование пользовательских заголовков чистой реализацией REST? Я могу отбросить Basic Auth и использовать пользовательские заголовки. Таким образом, можно избежать, по крайней мере, CSRF-атаки из браузера, и приложения, использующие сервис, установят имя пользователя / пароль в пользовательском вереске. Плохо для такого подхода то, что теперь сервис нельзя использовать из браузера.
источник
Ответы:
Чрезмерная инженерия? Не за что. Анти-XSRF меры являются необходимой частью любого безопасного веб-приложения или службы. Может быть, а может и нет, «крайне маловероятно», что кто-то решит атаковать вас, но это не делает ваше программное обеспечение менее небезопасным.
Системы, как правило, подвергаются атакам с использованием XSRF, и, хотя результаты не так сразу очевидны - очевидно, хуже, чем инъекции SQL или XSS, они достаточно плохие, чтобы поставить под угрозу все взаимодействующие с пользователем функции.
Это означает, что вы не можете иметь «чистый» интерфейс RESTful, где единственными параметрами являются свойства самого вызова. Вы должны включить в запрос что-то, что злоумышленник не мог угадать. Это может быть пара имя пользователя-пароль, но это далеко не единственный возможный выбор. Вы можете иметь имя пользователя вместе с токеном, сгенерированным из соленого хэша пароля. Вы можете получить токены, выданные самой службой во время аутентификации (которые могут быть запомнены в сеансе или проверены криптографически).
Нет, запросы GET используются для запросов чтения, которые не имеют активной операции записи (они являются «идемпотентными»). Это только операции записи, которые требуют защиты XSRF.
источник
<script>тега, намеренно («JSONP») или случайно ( незащищенный JSON ).Никогда ничего не доверяй. Каждый запрос является атакой. Каждый пользователь хакер. Если вы разрабатываете с таким мышлением, ваше приложение будет гораздо более безопасным, стабильным и с меньшей вероятностью будет взломано злоумышленником. Все, что нужно, - это один умный человек, чтобы найти способ обойти вашу безопасность, чтобы у вас были серьезные проблемы с вашими данными (один из ваших самых ценных ресурсов ).
Если вы обнаружили дыру в безопасности своего приложения, сделайте все, что, по вашему мнению, нужно, чтобы устранить пробел. Ваш API, в частности, должен быть самой недоверчивой частью программного обеспечения из существующих. Я бы потребовал учетные данные и идти с запросами на отправку.
источник
Если код установлен и поддерживается, крайние случаи должны рассматриваться и рассматриваться в каждом конкретном случае.
Исправление из-за некоторых ошибок на моей части:
GET должен все еще использоваться как часть надлежащего сервиса RESTful, аутентификация должна все еще быть там в любом случае. Я пытался предположить, что в целях безопасности GET во многом похож на POST, но post выполняет свою работу, не помещая информацию в адресную строку, что, как правило, является большой разницей в безопасности (и почему мне не нравится GET), но как опубликовано @Lee,
Поскольку это будет использоваться сторонними приложениями, следует следовать рекомендациям для службы RESTful, чтобы конечный разработчик не запутался в этой части.
источник
Вы должны учитывать все возможные варианты, включая то, что пользователь активно злонамерен и (успешно) восстанавливает любые барьеры «безопасность по неизвестности».
Но в то же время вы должны оценивать последствия успеха взлома и вероятность того, что попытка будет иметь место. Например:
Внутренняя служба, защищенная надежным межсетевым экраном, менее подвержена атаке, чем служба в общедоступном Интернете.
Воздействие того, что кто-то снимает дискуссионный форум с клиентами, меньше, чем влияние кражи кредитных карт клиентов.
Я хочу сказать, что «полная безопасность» является «бесконечно дорогой» ... и практически недостижимой. В идеале вы должны принять решение о том, где провести черту, на основе тщательного анализа затрат и выгод.
источник