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 を処理するためのすぐに使える構成を提供しており、これは という名前の構成を介して修正できます。残念ながら、これは ModSecurity をターゲットとしています。 Core Rule Set  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 上に構築され、プロキシの Wasm インターフェイスのセットを指定する を実装します。最後に、Apache APISIX はプロキシと WASM の統合を提供します。 Coraza Coraza プロキシ Wasm は proxy-wasm ABI すべてを一緒に入れて 要約しましょう:  OWASP は、Web セキュリティの脆弱性トップ 10 のリストを提供しています。 コア ルールセットを介して ModSecurity 用にそれらを実装します。  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 変数を定義して保守性を向上させる Corza Wasm リリースを入手する 最近の APISIX バージョンでは、セキュリティを強化するためにユーザーは になっています。パッケージをインストールする必要があるため、  に切り替える必要があります。 apisix root   がインストールされていないためインストールし、ダウンロードしたアーカイブを解凍し、アーカイブを削除し、  アンインストールし、抽出されたフォルダーの所有者を変更します。 unzip unzip ユーザー に戻ります apisix 次のステップでは、Coraza Wasm プラグインを使用するように APISIX 自体を構成します。   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 ログレベルを上げて、ログで何が起こっているかを確認します エンジンのスイッチを入れます Corza セットアップを使用する すべてのルールを使用してください。よりきめ細かい制御のために必要なものを選択できます 上で定義した 構成を使用します 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

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

このオーディオは、ストーリーの元の言語で制作されています。

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

About Author

コメント

ラベル

この記事は

Related Stories

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

AI の力を解き放つ。最先端技術の体系的レビュー: 概要と序論

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

AI の力を解き放つ。最先端技術の体系的レビュー: 概要と序論

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps