Я чрезмерный инженер, если я рассматриваю преднамеренное неправильное поведение пользователя?

Не слишком ли это сложно, если я добавлю защиту от преднамеренных правонарушений пользователя (мягко говоря), если вред, который может принести пользователь, не связан с моим кодом?

Для пояснения я представляю простой сервис 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

Нет, запросы GET используются для запросов чтения, которые не имеют активной операции записи (они являются «идемпотентными»). Это только операции записи, которые требуют защиты XSRF.

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

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

Если код установлен и поддерживается, крайние случаи должны рассматриваться и рассматриваться в каждом конкретном случае.

Исправление из-за некоторых ошибок на моей части:

GET должен все еще использоваться как часть надлежащего сервиса RESTful, аутентификация должна все еще быть там в любом случае. Я пытался предположить, что в целях безопасности GET во многом похож на POST, но post выполняет свою работу, не помещая информацию в адресную строку, что, как правило, является большой разницей в безопасности (и почему мне не нравится GET), но как опубликовано @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Поскольку это будет использоваться сторонними приложениями, следует следовать рекомендациям для службы RESTful, чтобы конечный разработчик не запутался в этой части.

Вы должны учитывать все возможные варианты, включая то, что пользователь активно злонамерен и (успешно) восстанавливает любые барьеры «безопасность по неизвестности».

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

• Внутренняя служба, защищенная надежным межсетевым экраном, менее подвержена атаке, чем служба в общедоступном Интернете.

• Воздействие того, что кто-то снимает дискуссионный форум с клиентами, меньше, чем влияние кражи кредитных карт клиентов.

Я хочу сказать, что «полная безопасность» является «бесконечно дорогой» ... и практически недостижимой. В идеале вы должны принять решение о том, где провести черту, на основе тщательного анализа затрат и выгод.