ОТДЫХ против безопасности

Question

Пару дней назад я наткнулся на новости о том, как хакеры украли 200 000+ учетных записей Citi, просто изменив номера в URL. Похоже, что разработчики поставили под угрозу безопасность из-за RESTful, а также не удосужились сохранить идентификатор сессии вместо userId. Я также работаю над продуктом, в котором безопасность является главной задачей, поэтому мне интересно, следует ли нам избегать REST и использовать почтовые запросы везде в таком случае? или я упускаю что-то важное о REST?

Answer 1

Не вините модель за плохую реализацию, вместо этого учитесь на ошибках других.

Это мое (краткое) мнение, но я уверен, что будут добавлены лучшие ответы:)

(PS - использование Post никак не повышает безопасность)

Answer 2

Проблемы безопасности, упомянутые в этом вопросе, не имеют ничего общего с REST, SOAP или Web. Это связано с тем, как проектируются приложения.

Вот еще один распространенный пример. Скажем, в приложении электронной коммерции есть экран для отображения деталей заказа. Для вошедшего в систему пользователя URL-адрес может выглядеть следующим образом:

http://example.com/site/orders?orderId=1234

Предполагая, что заказы являются глобально уникальными (для всех пользователей этой системы), можно легко заменить этот идентификатор заказа другим действительным идентификатором заказа, не принадлежащего пользователю, и просмотреть подробности. Простой способ защитить это - убедиться, что базовый запрос (SQL и т. Д.) Имеет идентификатор пользователя, также добавленный как конъюнкция (И в предложении WHERE для SQL).

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

Answer 3

Одни и те же данные передаются по проводам независимо от того, используете ли вы GET или POST. Вот пример запроса GET, который является результатом отправки формы [вынул значение User-Agent, потому что оно было длинным]:

GET /Testing/?foo=bar&submit=submit HTTP/1.1
Host: localhost
User-Agent: ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/Testing/demoform.html

Теперь вот тот же запрос, что и POST:

POST /Testing/ HTTP/1.1
Host: localhost
User-Agent: ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/Testing/demoform.html
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
foo=bar&submit=submit

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

В GET мы видим, что foo = bar и submit = submit в первой строке запроса. В POST мы должны посмотреть на последнюю строку, чтобы увидеть это ... эй! foo = bar и submit = submit. То же самое.

На уровне браузера разница проявляется в адресной строке. Первый запрос показывает строку ?foo=bar&submit=submit, а второй - нет. Злоумышленник, который хочет перехватить эти данные, не заботится о том, что появляется в адресной строке браузера. Основная опасность возникает из-за того, что любой может скопировать URL-адрес из адресной строки и передать его таким образом, что утечка параметров; на самом деле люди очень часто делают это.

Единственный способ помешать нашему злоумышленнику увидеть любой из этих типов запросов - все это должно быть зашифровано перед отправкой на сервер. Сервер предоставляет открытый ключ, который используется (через протокол https и SSL / TLS). Браузер использует ключ для шифрования запроса, а сервер расшифровывает его своим закрытым ключом. На стороне клиента все еще существует проблема относительно того, принадлежит ли ключ, полученный от сервера, людям, работающим на сервере. Это должно быть проверено с помощью какой-либо внеполосной системы доверия, такой как проверка третьей стороной или сравнение отпечатков пальцев или что-то в этом роде.

Все это полностью ортогонально REST. Независимо от того, как вы это делаете, если вы передаете информацию по сети через HTTP, у вас возникнет эта проблема, и вам нужно будет зашифровать запросы / ответы, чтобы злоумышленники не могли их увидеть.

Answer 4

Я бы посчитал REST и все проблемы безопасности веб-приложений очень похожими.

Задача, изложенная в вопросе, считается «школьной» ошибкой, чего не сделает опытный веб-разработчик.Поэтому, если вы понимаете безопасность веб-приложений - вы также поймете безопасность REST.

Поэтому добавьте опытного веб-разработчика в свою команду, если у вас его нет - он поможет вам с REST.

Answer 5

Использование POST вместо GET в качестве меры безопасности - это просто использование «безопасности через неизвестность». На самом деле это не так безопасно, так как любой с небольшим знанием HTTP может подделать POST-запрос.

Использование идентификаторов сеансов вместо идентификаторов пользователей также является еще одним способом скрыть дыру в безопасности, но на самом деле это не решает проблему, поскольку идентификаторы сеансов также могут быть взломаны.

Тот факт, что в данном конкретном случае дыру в безопасности стало чрезвычайно легко использовать путем изменения URL, не делает использование REST причиной проблемы безопасности.

Как уже упоминалось, всякий раз, когда вам нужно защитить REST-сервисы, HTTPS - это то место, где стоит начать поиск.

Answer 6

POST-запросы не более безопасны, чем RESTful-запросы, которые не более безопасны, чем GET-запросы.

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

Вот пример: запросы GET не должны использоваться для критических действий, таких как снятие банковского счета, потому что, если вы вошли в свой банковский счет, кто-то может установить образ румян с источником как http://yourbank.com/actions/withdraw/300USD, и URL будет загружен, снимая деньги с вашего банковского счета. Этому легко противостоять с помощью запроса POST.

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

Answer 7

Если безопасность является главной задачей, используйте исключительно https:// и POST, никогда http:// и GET.

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

(... и воздержитесь от ошибки аутентификации с помощью https:// и переключения на http:// позже, что было "стандартом де-факто" до тех пор, пока несколько месяцев назад кто-то не опубликовал инструмент, который сделал очевидное )