APIセキュリティ101:注射

SQLインジェクションとコマンド注入はどのようにAPIで起こるか

のIvan DiazによるUnsplash写真
あなたはおそらくOwaspトップ10またはWebアプリケーションを脅かすトップ10の脆弱性を聞いたことがあります.また、OWASP APIはトップ10の脆弱性のリストを定期的に選択します.現在のAPIのトップ10は壊れているオブジェクトレベルの承認、壊れたユーザー認証、過度のデータ露出、リソースの欠如＆レート制限、壊れた機能レベルの承認、質量割り当て、セキュリティの設定、注入、不適切な資産管理、および不十分なログ＆モニタリング.これらはAPIに最も影響する脆弱性です.今日は、OWASP API CHERHER 8、Injection、ほとんどのアプリケーションやAPIシステムに影響を与えるタイプの脆弱性について話しましょう.
注入は、SQLインジェクション、OSコマンド注入、およびXML注入のような多数の脆弱性の根本的な問題です.一緒に、注射は、現実世界のアプリケーションとAPIで発見された脆弱性の巨大な割合を説明します.

どのように注射が起こる

単一の文では、アプリケーションが信頼できないユーザーデータとコードを適切に区別できない場合に、注入が発生します.
信頼できないユーザデータはHTTPリクエストパラメータ、HTTPヘッダー、クッキーです.また、データベースや、ユーザーによって変更できる格納ファイルから来ることができます.アプリケーションがコマンドまたはクエリに挿入する前に、信頼されていないユーザーデータを適切に処理しない場合、プログラムのインタプリタは、ユーザー入力をコマンドまたはクエリの一部として混乱させます.この場合、攻撃者はそのコマンドの意味を変える方法でデータをアプリケーションに送ることができます.
例えば、SQLインジェクション攻撃では、攻撃者はSQLコマンドを操作するためにデータを注入します.そして、コマンド注入攻撃において、攻撃者はホスト・システムコマンドの論理を操作するデータをホスティング・サーバに注入する.ユーザデータとプログラミングコマンドやコードを組み合わせたプログラムは潜在的に脆弱です.
APIは、信頼できないユーザー入力がアプリケーションに入ることができる別の方法であるので、注入脆弱性はAPIシステムにも影響を及ぼす可能性があります.注入脆弱性がAPIにどのように見えるか見てみましょう.

例1 - 1 .ブログ記事の検索

APIは、このようなGETリクエストを送信することによって、ユーザーがブログ記事を取得できるようにしましょう.

GET /api/v1.1/posts?id=12358

この要求はAPI 121258を返す原因となります.サーバはSQLクエリでデータベースから対応するブログ記事を取得します.ここで、PostSound IDはURLを介してユーザーが渡されたIDを参照します.

SELECT * FROM posts WHERE post_id = 12358

さて、ユーザーがAPIエンドポイントからこれを要求するならば、どうですか?

GET /api/v1.1/posts?id= **12358; DROP TABLE users**

SQLサーバはセミコロンの後のIDの一部を別々のSQLコマンドと解釈します.したがって、SQLエンジンは最初にこのコマンドを実行して、ブログのポストを通常通りに取得します.

SELECT * FROM posts WHERE post_id = 12358;

次に、このコマンドを実行してユーザーテーブルを削除し、アプリケーションがそのテーブルに格納されているデータを失う原因になります.

DROP TABLE users

これはSQLインジェクション攻撃と呼ばれ、ユーザ入力がSQLクエリに安全な方法で渡されるたびに起こります.APIのユーザー入力だけでURLのパラメータを介して旅行しないでください、彼らはまた、ポストリクエスト、URLのパスパラメータを介してアプリケーションに到達することができますので、など.だから、それらの場所を確保することも重要です.

ファイルシステムの読み込み

サイトでは、APIエンドポイントを介してアップロードしたファイルを読むことができます.

GET /api/v1.1/files?id=1123581321

この要求はサーバにシステムコマンドを介してユーザのファイルを取得させる.

cat /var/www/html/users/tmp/1123581321

この場合、ユーザーはセミコロンの後、追加コマンドを加えることによって、OSコマンドに新しいコマンドを注入することができました.

GET /api/v1.1/files?id=1123581321; rm -rf /var/www/html/users

このコマンドはサーバが/var/www/html/usersにあるフォルダを削除します.

rm -rf /var/www/html/users

APIにおける注入脆弱性の防止

これらは注入脆弱性の簡単な例である.実際には、注射の脆弱性は常にこの明白ではないことを覚えておくことが重要です.そして、この操作は、データのこの部分が処理されるか、使われるいつでも起こります.悪意のあるユーザーデータがアプリケーションによってすぐに使用されていない場合でも、信頼されていないデータは、危険な関数や保護されていないクエリなど、何か悪いことができるプログラムのどこかに移動することができます.そして、これは彼らがアプリケーション、そのデータ、またはそのユーザに損害を与える場所です.
そういうわけで、注射はとても難しいです.信頼されていないデータは、ストリームに触れるアプリケーションコンポーネントを攻撃できます.そして、アプリケーションが受信した信頼できないデータのすべての部分については、それは検出し、アプリケーションのすべての部分をターゲットに攻撃を中和する必要があります.そして、アプリケーションは、攻撃者が代わりにSQLインジェクションを引き起こすつもりであるとき、それがXSSをトリガーするのに使用されるどんな特殊文字も含んでいないので、データの部分が安全であると思うかもしれません.安全で安全なデータがアプリケーションの異なる部分で非常に異なって見えるので、どんなデータが安全であるかについて決定するのは必ずしも簡単でありません.
入力検証
では、どのようにこれらの脅威に対して保護するのですか?最初に行うことは信頼できないデータを検証することです.これは、アプリケーションコンポーネントに影響を与える危険な文字を含む入力を拒否するために、ブロックリストを実装することを意味します.あるいは、入力文字列を既知の良い文字だけで許可するアロアリストを実装します.たとえば、サインアップ機能を実装しているとしましょう.データがSQLクエリに挿入されようとしていることを知っているので、単一の引用符のようにSQLの特殊文字であるユーザー名入力を拒否します.または、英数字だけを許す規則を実装できます.
しかし、時にはブロックリストを実行するのは難しいです.なぜなら、どの文字がどれだけの行を下にあるアプリケーションコンポーネントにとって重要かを知らないからです.あなただけの1つの特殊文字を逃す場合は、攻撃者は保護をバイパスすることができます.
そして、allowlistsは制限的であるかもしれません、そして、場合によっては、時々、あなたはユーザー入力フィールドで単一引用符のような特殊文字を受け入れる必要があるかもしれません.たとえば、コナンオブライエンという名前のユーザーが署名している場合、彼は彼の名前で単一の引用符を使用することが許されるべきです.
パラメータ化
注射に対するもう一つの可能な防御はパラメタリゼーションです.パラメータ指定は、ユーザーが指定したパラメータを挿入する前に、コマンドのコード部分をコンパイルすることを指します.
これは、ユーザコマンドをプログラムコマンドに連結してコンパイルするためにサーバに送信するのではなく、すべてのロジックを最初に定義し、それをコンパイルし、実行前にコマンドにユーザー入力を挿入することを意味します.ユーザー入力が最終的なコマンドに挿入されたあと、コマンドは解析されて、再びコンパイルされません.そして、元の文にない何も、ストリングデータとして扱われて、実行可能コードではありません.それで、あなたのコマンドのプログラム論理部分はそのままのままです.
これにより、ユーザが入力した内容に関係なく、データベースのコード部分とコマンドのデータ部分を区別できます.このメソッドは、いくつかの注入脆弱性を防ぐのに非常に効果的ですが、コード内のすべてのコンテキストで使用することはできません.
エスケープ
そして最後に、代わりに特殊文字をエスケープすることができます.エスケープは、特別な文字ではなくデータとして扱われるように、ユーザー入力で特殊文字をエンコードすることを意味します.ユーザー入力で特別なキャラクタをマークするために特別なマーカと構文を使用することによって、エスケープは、インタプリタがデータが実行されることを意図しないことを知っています.
しかし、この方法には問題があります.つの場合は、すべての川下パーサーに対して厳密なエンコーディング構文を使用したり、パーサによって誤って解釈されたエンコードされた値を危険にする必要があります.また、いくつかの文字をエスケープすることを忘れてしまうかもしれません.したがって、インジェクション脆弱性を防ぐ鍵は、異なる言語のパーサーがどのように働くかを理解することです.
どのような他のセキュリティ概念を学びたいですか?私は知りたい.Twitterでの接続をお気軽に.
アプリケーションのセキュリティについてもっと知りたいですか?我々の無料Owaspトップ10コースをここに持ってください:https://www.shiftleft.io/learn/.