Нужно ли нам делать ответ безопасным?

#api #security #oauth-2.0 #response #access-token

#API #Безопасность #oauth-2.0 #ответ #токен доступа

Вопрос:

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

ценю любые советы.

Комментарии:

1. # 1 Что вы имеете в виду response that comes back from that system (or API) is secure enough ? Если вы используете какую-либо конечную точку aws rest api, вы получаете строку, которая будет проанализирована для вашего http-клиента. #2 Считаете ли вы, что эта строка может быть вредоносной и влиять на клиентское приложение?

Ответ №1:

Как обычно в таких случаях, ответ таков: это зависит 😉

  1. Кто является владельцем API, который вы вызываете? Если вы вызываете свой собственный API, вы можете быть уверены в достоверности и безопасности ответа. Если вы вызываете сторонний API, вы можете добавить некоторые проверки. Может быть, сканировать файлы на наличие вредоносного кода, если вы загружаете какие-либо файлы из этого API? Или проверьте, не пытается ли ответ ввести какой-либо код и т.д. Хотя, возможно, это не самая простая вещь.
  2. Используете ли вы безопасное соединение с API? Если вы используете SSL, то вы уверены, что никто не подделал ответ. Кроме того, вы можете проверить цепочки сертификатов, чтобы убедиться, что вы подключаетесь к правильной конечной точке API, а не к вредоносной. Если вы не используете SSL, вам может потребоваться проверить ответ от API, был ли он подделан или нет. Как выполнить эту проверку снова, может быть, нетривиально, но, возможно, ответ может быть подписан?
  3. Где находится клиент, который разговаривает с API? Если у вас есть серверный клиент, взаимодействующий с API, вам не следует беспокоиться о том, что ответ может быть изменен на стороне клиента. Если у вас есть SPA, запущенный в браузере, то ответ может быть изменен атакой «человек в браузере». Такой ответ может быть изменен, даже если вы используете SSL для подключения к API, поскольку SSL завершается в браузере, и скомпрометированный пользовательский агент предоставит злоумышленнику доступ к расшифрованному ответу API. У вас также может быть XSS-атака, которая изменяет ответы в вашем приложении. Опять же, для защиты от этой угрозы вам потребуется, чтобы ответы были подписаны или имели другой способ проверки целостности.

Одним из способов проверки целостности ответа является использование подписанных JWT с асимметричной подписью. API может подписать ответ своим закрытым ключом, а затем вы можете проверить, не был ли он подделан. Например, спецификация JARM использует это для ответов потока OAuth.