Как предотвратить внедрение SQL и повысить безопасность API REST?

Я новичок в REST API и разрабатываю API, который будет использоваться для iOS/Android/веб-приложений, но я не знаком с угрозами, с которыми API сталкиваются после публикации. Я везде вижу одни и те же советы:

  • Используйте oAuth 2 для разрешения транзакций,
  • Получение и отправка только зашифрованных веб-токенов JSON,
  • Используйте SSL/TTL.

Я думаю, что использование SSL/TLS и JWT должно быть достаточно безопасным для отправки/получения данных, но даже при этом я опасаюсь возможности внедрения SQL, если кто-то украл учетные данные.

Должен ли я проверять запросы на строки SQL-инъекций (такие как этот )? И если я собираюсь поддерживать вход пользователя в систему, имеет ли смысл использовать oAuth вместо JWT?


go rest security websecurity application-security
person Dialvive    schedule 01.01.2021    source источник
comment
Для меня лучший способ — разделить объекты передачи данных (DTO) и объекты базы данных и использовать ORM вместо выполнения SQL-запросов непосредственно из бэкэнда. Таким образом, вы собираете свои запросы к базе данных из предсказуемой структуры (из DTO) и выполняете запросы на основе объектов, что устраняет риск внедрения SQL. Взгляните на gorm   -  person Mikael    schedule 01.01.2021
comment
и другие атаки делают этот вопрос невероятно широким .... поскольку существует неограниченное количество атак (и постоянно обнаруживаются новые)   -  person Flimzy    schedule 02.01.2021
comment
Возможный дубликат stackoverflow.com/q/26345318/13860   -  person Flimzy    schedule 02.01.2021
comment
Отвечает ли это на ваш вопрос? Как я могу предотвратить внедрение SQL в PHP?   -  person symcbean    schedule 02.01.2021
comment
@symcbean Нет, PHP не используется, и вариант использования другой.   -  person Dialvive    schedule 02.01.2021

Ответы (1)


arrow_upward
2
arrow_downward

sql-i

  1. использование подготовленных операторов поможет вам во многом (дальнейшее чтение)

  2. рассмотрите возможность использования слоев ORM для взаимодействия с вашей базой данных (например: gorm)

принципы безопасности

  1. всегда проверяйте ввод пользователя перед выполнением каких-либо операций над ним

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

авторизация

  1. jwt - это просто формат токена (аналогичный вашему удостоверению личности), и вы можете использовать oauth для базовой аутентификации (проверив свое удостоверение личности, прежде чем предоставить вам доступ к какому-либо ресурсу) - подробнее здесь
  2. токены-носители (например, jwt) всегда должны отправляться через TLS/SSL, чтобы злоумышленники не могли получить доступ к незашифрованному тексту jwt (rfc7523)
  3. по мере развития продукта вы, возможно, захотите перейти к модели, в которой вы начнете назначать токены сеанса, хранящиеся на телефоне, но это обычно сопряжено со сложностью обработки отзыва (например, когда и как мне чередовать токены сеанса?)
person Debosmit Ray    schedule 01.01.2021
comment
Хорошо, допустим, что методы GET для одного объекта общедоступны, но нам нужна безопасность AAA для важных данных и других операций. Все данные будут передаваться/запрашиваться с использованием TLS/SSL. Но для доступа или изменения разумных данных API должен выдавать токены-носители (с JWT) после того, как сеанс пользователя предоставил действительный токен oAuth? - person Dialvive; 01.01.2021
comment
@Dialvive довольно много! токен носителя будет передан в заголовках; первое, что ваша конечная точка должна сделать, это выполнить некоторые проверки политики авторизации oauth - person Debosmit Ray; 01.01.2021
comment
Нет причин использовать ORM для предотвращения SQL-инъекций. Если вы решите использовать ORM, потому что вам нужен ORM, хорошо, но делайте это по уважительной причине. - person Flimzy; 02.01.2021
comment
@Flimzy Я думаю, что ORM может помочь избежать написанных человеком уязвимостей при манипулировании БД. И пользовательский ввод должен проверяться на синтаксис SQL, верно? - person Dialvive; 02.01.2021
comment
Нет, пользовательский ввод не должен проверяться на наличие синтаксиса SQL. Его следует либо заключать в кавычки, либо передавать как переменную — тогда синтаксис SQL совершенно не имеет значения. И ORM не нужен ни для одной из этих вещей. - person Flimzy; 02.01.2021