Apache APISIX API ゲートウェイを使用して Web の脆弱性に対処する方法

Open Worldwide Application Security Project は、IoT、システム ソフトウェア、Web アプリケーション セキュリティの分野で、無料で利用できる記事、方法論、ドキュメント、ツール、テクノロジを作成するオンライン コミュニティです。 OWASP は無料のオープン リソースを提供します。 OWASP Foundation という非営利団体が主導しています。 OWASP トップ 10 - 2021 は、40 を超えるパートナー組織から収集された包括的なデータに基づく最近の調査の結果として発表されました。

-- OWASP ウェブサイト

OWASP は、トップ 10 の脆弱性レポートを定期的に発行しています。このレポートは、Web アプリケーションの脆弱性を対象としています。

この投稿では、 Apache APISIX API Gatewayを介してそれらのいくつかを修正する方法について説明したいと思います。

OWASP トップ 10 2021

2021 年のレポートでは次のように言及されています。

• A01:2021 - 壊れたアクセス制御
• A02:2021 - 暗号化の失敗
• A03:2021-注射
• A04:2021-不安定
• A05:2021 - セキュリティの構成ミス
• A06:2021 - 脆弱で古いコンポーネント
• A07:2021 - 識別と認証の失敗
• A08:2021 - ソフトウェアとデータの整合性障害
• A09:2021 - セキュリティのログ記録と監視の失敗
• A10:2021 - サーバー側のリクエスト偽造

詳細については、完全なレポートを確認してください。

脆弱性の修正は、その正確な性質によって異なります。たとえば、脆弱なコンポーネントや古いコンポーネントの修正はプロセス主導で行われるため、バージョンの管理や古いコンポーネントの廃止には規律が必要です。ただし、一部の機能は技術的なものであり、リバース プロキシまたは API ゲートウェイでの適切な構成のみが必要です (サーバー サイド リクエスト フォージェリなど) 。

セキュリティなんて誰も気にしてないよ

セキュリティを強化してもビジネスに何の価値ももたらさないため、セキュリティはデリケートなテーマです。キャリア主導のマネージャーは、次の年次評価で会社の利益が X% 増加したことを証明できないため、セキュリティを気にしません。取締役会がセキュリティを真剣に考慮しない限り、誰も気にしない可能性があります。このため、ほとんどの組織はチェックボックスベースのセキュリティ、別名妥当性のある拒否を実装しています。セキュリティを適切に実装することに興味がある場合は、以前のブログ投稿「セキュリティをリスクとして扱う」にいくつかの考えを書きました。

全体として、アプリケーションの保護には、たとえあったとしても多くの予算はかかりません。したがって、賢明に既存のコンポーネントを検索する必要があります。幸いなことに、OWASP はトップ 10 を処理するためのすぐに使える構成を提供しており、これはCore Rule Setという名前の構成を介して修正できます。残念ながら、これは ModSecurity をターゲットとしています。

ModSecurity (Modsec とも呼ばれます) は、オープンソースの Web アプリケーション ファイアウォール (WAF) です。元々は Apache HTTP Server のモジュールとして設計されましたが、Apache HTTP Server、Microsoft IIS、Nginx などのさまざまなプラットフォームにわたって、一連の Hypertext Transfer Protocol のリクエストおよび応答のフィルタリング機能やその他のセキュリティ機能を提供するように進化しました。これは、Apache License 2.0 に基づいてリリースされたフリー ソフトウェアです。

--ウィキペディアの ModSecurity

Apache APISIX 構成を介して Nnginx を構成することは理論的には可能ですが、もっと簡単な方法がもう 1 つあります。

OWASP コア ルールセットと Coraza

コア ルールセットの説明は、私たちのニーズに非常に関連しています。

OWASP® ModSecurity Core Rule Set (CRS) は、ModSecurity または互換性のある Web アプリケーション ファイアウォールで使用するための一連の汎用攻撃検出ルールです。 CRS は、誤った警告を最小限に抑えながら、OWASP トップ 10 を含む幅広い攻撃から Web アプリケーションを保護することを目的としています。 CRS は、次のような多くの一般的な攻撃カテゴリに対する保護を提供します。

• SQLインジェクション(SQLi)
• クロスサイトスクリプティング (XSS)
• ローカル ファイル インクルージョン (LFI)
• リモート ファイル インクルージョン (RFI)
• PHPコードインジェクション
• Javaコードインジェクション
• HTTPオキシ
• 砲弾ショック
• Unix/Windows シェル インジェクション
• セッションの固定
• スクリプト/スキャナ/ボット検出
• メタデータ/エラー漏洩

-- OWASP® ModSecurity Core Rule Set Web サイト

OWASP は、Go ライブラリとして利用できる ModSecurity のポートであるCorazaも提供します。 Coraza プロキシ Wasm はCoraza 上に構築され、プロキシの Wasm インターフェイスのセットを指定するproxy-wasm ABIを実装します。最後に、Apache APISIX はプロキシと WASM の統合を提供します。

すべてを一緒に入れて

要約しましょう:

1. OWASP は、Web セキュリティの脆弱性トップ 10 のリストを提供しています。
2. コア ルールセットを介して ModSecurity 用にそれらを実装します。
3. Coraza は ModSecurity のポートであり、proxy-wasm 実装として利用可能です

この方法で、Apache APISIX を健全で安全なデフォルトで構成できます。やりましょう。

まず最初に、Coraza は Apache APISIX ディストリビューションの一部ではありません。ただし、Docker を使用してここに追加するのは簡単です。

 FROM apache/apisix:3.8.0-debian ENV VERSION 0.5.0 #1 ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip #1 ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2 USER root #3 RUN <<EOF apt-get install zip -y #4 unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm rm $CORAZA_FILENAME apt-get remove zip -y chown -R apisix:apisix /usr/local/apisix/proxywasm EOF USER apisix #5

1. 変数を定義して保守性を向上させる
2. Corza Wasm リリースを入手する
3. 最近の APISIX バージョンでは、セキュリティを強化するためにユーザーはapisixになっています。パッケージをインストールする必要があるため、 rootに切り替える必要があります。
4. unzipがインストールされていないためインストールし、ダウンロードしたアーカイブを解凍し、アーカイブを削除し、 unzipアンインストールし、抽出されたフォルダーの所有者を変更します。
5. ユーザーapisixに戻ります

次のステップでは、Coraza Wasm プラグインを使用するように APISIX 自体を構成します。

 wasm: plugins: - name: coraza-filter #1 priority: 7999 #2 file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3

1. Wasm コードで設定されたフィルターの名前
2. 他のプラグインよりも前に実行されるように最高の優先順位を設定します。
3. 抽出されたファイルへのパス。上記のDockerfileを参照してください。

最後に、プラグインをルートに割り当てることも、すべてのルートに適用するグローバル ルールとして設定することもできます。私は静的構成を使用しています:

 global_rules: - id: 1 plugins: coraza-filter: #1 conf: directives_map: #2 default: - SecDebugLogLevel 9 #3 - SecRuleEngine On #4 - Include @crs-setup-conf #5 - Include @owasp_crs/*.conf #6 default_directives: default #7

1. coraza-filterプラグインが利用可能になったので設定します。
2. 構成を定義します。ここでは、単一のdefaultを定義していますが、複数を定義して、異なるルートで異なるものを使用することもできます。
3. ログレベルを上げて、ログで何が起こっているかを確認します
4. エンジンのスイッチを入れます
5. Corza セットアップを使用する
6. すべてのルールを使用してください。よりきめ細かい制御のために必要なものを選択できます
7. 上で定義したdefault構成を使用します

https://httpbin.org/へのルートを定義してセットアップをテストします。 /getへのルートを呼び出しましょう。

 curl localhost:9080?user=foobar

応答は予想どおりです。

 { "args": { "user": "foobar" }, "headers": { "Accept": "*/*", "Host": "localhost", "User-Agent": "curl/8.4.0", "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", "X-Forwarded-Host": "localhost" }, "origin": "192.168.65.1, 176.153.7.175", "url": "http://localhost/get?user=foobar" }

次に、クエリ文字列で JavaScript を送信してみましょう。このリクエストがサーバー側で予期されることはありえないため、インフラストラクチャがそれから保護される必要があります。

 curl 'localhost:9080?user=<script>alert(1)</script>'

応答は 403 HTTP ステータス コードです。ログを見ると、次のヒントがわかります。

 Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection Coraza: Warning. Javascript method detected Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1

コラサは仕事をしてくれました！

結論

ほとんどの組織はセキュリティに対する奨励を行っていません。したがって、賢明に対処し、既存のコンポーネントを可能な限り使用する必要があります。

Coraza とコア ルールセットを使用することで、OWASP Top 10 に対して Apache APISIX を強化できます。

さらに進むには:

• OWASP セキュリティ トップ 10
• OWASP ModSecurity コア ルールセット
• OWASP コラサ WAF
• APISIX - Coraza との統合

この投稿の完全なソース コードはGitHubにあります。

初出は 2024 年 2 月 4 日にA Java Geekで公開されました