オープンワールドワイドアプリケーションセキュリティプロジェクトは、IoT、システムソフトウェア、ウェブアプリケーションセキュリティの分野で無料で利用可能な記事、方法論、ドキュメント、ツール、技術を提供するオンラインコミュニティです。OWASPは無料でオープンなリソースを提供しており、OWASP財団という非営利団体によって主導されています。OWASPトップ10 – 2021は、40を超えるパートナー組織からの包括的なデータに基づく最近の研究の成果として公開されたものです。
OWASPは定期的にトップ10の脆弱性レポートを発表しています。このレポートはウェブアプリケーションの脆弱性を対象としています。
この投稿では、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を扱うための即時に使える設定を提供しており、コアルールセットという設定名で修正可能です。残念ながら、それはModSecurityを対象としています。
ModSecurity, いわゆる Modsec とも呼ばれる、オープンソースのウェブアプリケーションファイアウォール(WAF)です。もともと Apache HTTP Server のモジュールとして設計されたものが、Hypertext Transfer Protocol のリクエストおよびレスポンスのフィルタリング機能や、他のセキュリティ機能を含む幅広いプラットフォームで提供されるように進化しました。これには Apache HTTP Server、Microsoft IIS、Nginx が含まれます。Apache ライセンス 2.0 の下で無料のソフトウェアとしてリリースされています。
理論的には Apache APISIX の設定を通じて Nginx を設定することは可能ですが、より直接的な方法があります。
OWASP Core Ruleset と Coraza
Core Ruleset の説明は私たちのニーズに非常に関連があります:
OWASP® ModSecurity Core Rule Set(CRS)は、ModSecurity または互換性のあるウェブアプリケーションファイアウォールで使用するための一般的な攻撃検出ルールのセットです。CRS は、広範な攻撃からウェブアプリケーションを保護し、誤警報を最小限に抑えることを目的としています。CRS は、多くの一般的な攻撃カテゴリからの保護を提供しています。
- SQL インジェクション(SQLi)
- クロスサイトスクリプティング(XSS)
- ローカルファイルインクルージョン(LFI)
- リモートファイルインクルージョン(RFI)
- PHP コードインジェクション
- Java コードインジェクション
- HTTPoxy
- Shellshock
- Unix/Windows シェルインジェクション
- セッション固定
- スクリプティング/スキャナ/ボット検出
- メタデータ/エラー漏洩
OWASPはCorazaを提供しており、これはModSecurityのポートで、Goライブラリとして利用可能です。Coraza Proxy WasmはCorazaの上に構築され、プロキシ-wasm ABIを実装しており、これはプロキシ用の一連のWasmインターフェースを指定します。最後に、Apache APISIXはプロキシ-wasmの統合を提供しています。
すべてをまとめる
要点を総括すると:
- OWASPはトップ10のウェブセキュリティ脆弱性のリストを提供しています。
- それらをコアルールセットを通じてModSecurityに実装しています。
- CorazaはModSecurityのポートで、プロキシ-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
- 保守性を高めるために変数を定義する
- Coraza Wasmのリリースを入手します。
- 最近のAPISIXバージョンでは、セキュリティを強化するためにユーザーは
apisix
です。パッケージをインストールする必要があるため、root
に切り替える必要があります。 unzip
をインストールする必要があります。これはインストールされていません。ダウンロードしたアーカイブを解凍し、アーカイブを削除し、unzip
をアンインストールし、抽出したフォルダの所有者を変更します。- ユーザー
apisix
に戻ります。
次のステップは、APISIX自体をCoraza Wasmプラグインを使用するように設定することです。
wasm:
plugins:
- name: coraza-filter #1
priority: 7999 #2
file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3
- Wasmコードで設定されたフィルタの名前
- 最も高い優先度を設定して、他のすべてのプラグインよりも先に実行されるようにします。
- 抽出されたファイルへのパス(上記の
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
coraza-filter
プラグインを設定します。これで利用可能です。- 設定を定義します。ここでは、
default
という1つを定義しますが、複数定義して異なるルートで異なるものを使用することも可能です。 - ログレベルを上げて、ログで何が起こっているか確認します。
- エンジンをオンにします。
- Corazaの設定を使用します。
- すべてのルールを使用します。より細かい制御のために、必要なものだけを選択することもできます。
- 上記で定義された
default
設定を使用します。
設定をテストするためのルートを定義します。ルートを/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>'
応答はHTTPステータスコード403です。ログを見ると、次のヒントが表示されます。
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が仕事をしました!
結論
大多数の組織はセキュリティに対するインセンティブを設けていません。そのため、賢く対処し、できる限り既存のコンポーネントを利用する必要があります。
Apache APISIXをOWASPトップ10に対してCorazaとコアルールセットを使用して強化することができます。
さらに進める
この記事の完全なソースコードはGitHubで見つけることができます。
Source:
https://dzone.com/articles/hardening-apache-apisix-with-the-owasps-coraza-and