Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Что подразумевается под safe API?

В контексте:

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful with APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

Что же такое safe API?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Думаю, що тут малось на увазі саме те, що згадували в попередніх коментарях.

Але, блін, «preferred option»!!! Це як? Ми хочемо, але не обов’язково? :)
Як на мене, такі речі мають робитися по замовчуванню та на автоматі.

Якщо не секрет, це звідки текст?

Скорее всего имеется ввиду правильное использование REST с инкапсуляцией CRUD операций.
Другими словами API нужно писать таким образом что бы злоумышленник не мог получит доступ к использованию например, SQL запросов к базе данных(почитайте о SQL инъекциях).
Если вы ожидаете параметризированый запрос, валидируйте колличество и типы параметров, добавьте валидацию чексум.
Не изобретайте велосипеды, используйте разные end поинты для разных операций.
Не валидируйте запросы(не пердавайте все время) с использованием приватных данных для аутентификации, используйте для этого API ключи и токены.

Вам нужен перевод или объяснение?

Объяснение) Своими словами, что такое безопасное API или полезные ссылки. Спасибо

Safe API строго разделяет (внешние) данные и код.

«INSERT INTO foo SET a = $a, b = $b» — unsafe, данные ($a и $b) пойдут через интерпретатор вместе с кодом.
«INSERT INTO foo SET a = ?, b = ?», $a, $b — safe, код интерпретируется отдельно, данные идут отдельно.
Контекст см. wiki:SQL injection и особенно Parametrized statements.

Про stored procedures см. stackoverflow.com/...nt-stop-all-sql-injection пример с create procedure getUser. Даже если вызов будет с разделением данных и кода, они будут перемешаны внутри процедуры.
Т.е. «EXEC getUser ?, ?», $a, $b выглядит как safe код, но таковым не является.

Проблема не специфична для SQL. То же самое касается любой ситуации, где возможен вызов интерпретатора на внешние данные. Всякие exec, eval и т.д.

Підписатись на коментарі