JS 検出を使用すると、Web システムは本当に安全ですか?

関連する学習の推奨事項: javascript

あなたの Web はシステムは本当に安全ですか?

千マイルの堤防がアリの巣で崩れた。

Web システムでは、小さな脆弱性が非常に深刻な結果を引き起こす可能性があります。したがって、Web セキュリティは、すべてのシステムが設計、開発、運用、保守の際に考慮する必要がある問題です。

現在、多くの Web システムで講じられている防御手段は基本的かつ単純なものに偏っており、多くの場合、次のような一般的なセキュリティ脆弱性のみを対象としています。

• Csrf
• XSS
• SQL インジェクション

など。これらの基本的な防御手段は必要であり、実装に費用はかかりませんが、システム セキュリティ防御の基本的な部分にすぎません。多くの開発者は、これらのことを行うだけでほとんどの状況に対処できると考えていますが、この考えは非常に危険です。実は、こうした基本的かつ標準化された脆弱性に加えて、各業務システムのビジネスロジックそのものもハッカー攻撃の標的となる可能性が高く、ひとたび侵入されれば重大な影響を及ぼします。以下に、よくあるビジネス ロジックの抜け穴をいくつか挙げます。これらの抜け穴は、以前にシステムを開発する際にも遭遇したものです。皆さんのインスピレーションになれば幸いです。

セッション資格情報管理の混乱

HTTP 自体がステートレスであることは誰もが知っています。ブラウザとサーバーが互いの ID を認識し、信頼できるようにするために、ほとんどの Web システムは「トークン」を使用します。これは、合意された資格情報を使用して実装されており、トークンはユーザーのログイン後に生成され、ユーザーがアクティブにログアウトするか、一定の時間が経過すると期限切れになります。つまり、リクエストが対応するトークンを持ってきた場合、サーバーはトークンを取得し、対応する検証を実行できます。検証に合格した場合、リクエストを信頼し、関連するビジネス ロジックを実行します。トークンを持っていない場合は、サーバーはそのトークンを取得し、対応する検証を実行します。違法または期限切れのものを持ち込む場合は、違法とみなされます。これは問題ないようですが、実際の実装には隠れた抜け穴がある可能性があります。

2 つの例を見てみましょう:

1. フロントエンド開発者 Xiao Ming が、ユーザーが終了ボタンをクリックするためのロジックを作成したとき、単に Cookie またはローカルストレージ内のトークン値をクリアしました。 (トークンは通常、これら 2 つの場所に保存されます)、ビジネス内でトークンを期限切れにするためのバックエンドへのリクエストを開始しませんでした。この場合、このトークンの有効性は本質的にユーザーの意図に反しており、現時点では非常に高いリスクがあります。ユーザーが自然に終了した場合でもトークンは有効であり、他人が何らかの方法でトークンを取得・記録しておけば、ユーザー情報の変更や注文など、ユーザーが行った操作を完全に再現することができます。

2. 上の例では、トークンの有効期限を設定する必要があると述べましたが、適切な有効期限を設けることでリスクを効果的に軽減できます。しかし、バックエンド開発担当者は、トークンの有効期限設定を設定するときに目がくらんで手が震え、余分な桁を入力したり、単位を誤解して S レベルの単位に MS レベルの値を使用したりする可能性があります。有効期限が設定されます 注文は非常に長いです。ログイン後に積極的にログアウトすることを好まないユーザーや、ページに長時間滞在するユーザーにとっては非常に危険です。トークンはユーザーが長期間使用しなくても有効なままであるため、他人がトークンを入手すると、さまざまな悪事が行われる可能性があります。

検証失敗

ファイルのアップロードは、アバターのアップロード、ネットワーク ディスクへのファイルのアップロードなど、Web アプリケーションでは一般的な機能です。悪意のあるユーザーは、アップロード時にトロイの木馬、ウイルス、悪意のあるスクリプトなどのファイルをアップロードする可能性があり、そのようなファイルがサーバー上で実行されると重大な影響を及ぼします。この攻撃方法は比較的低コストであり、攻撃者による悪用が比較的簡単です。アップロードできるファイルの種類が増えるほど、攻撃される可能性が高くなります。悪意のあるプログラムがアップロードされると、ユーザーによってダウンロードされ、ユーザーのコンピュータ上で実行された後に汚染される可能性があります。また、サーバー上で悪意のあるプログラムが実行され、サーバーが制御され、サーバーの麻痺やデータ損失が発生する可能性があります。

通常の状況では、プログラムはファイルの種類を判断し、合法であると思われるファイルのみをサーバーにアップロードすることを許可します。ただし、一部の Web プログラムでは、この判断はフロントエンドでのみ行われ、バックエンドでは行われません。これにより、攻撃者がリクエストを簡単に変更して違法なファイルをアップロードする機会が生まれます。

正しいアプローチは、バックエンドがファイル拡張子の判断、MIME 検出を実行し、アップロード ファイルのサイズやその他の制限を制限して防御することです。さらに、悪意のあるファイルがビジネス サーバーを攻撃してサービスが利用できなくなることを防ぐために、ビジネスから隔離されたサーバーにファイルを保存することもできます。

データ列挙

システムにログインするとき、ほとんどのシステムは、ユーザーがログインするときにユーザーが存在するかどうかを判断し、「この携帯電話番号は登録されていません」というプロンプトを表示します。このロジックが別のインターフェイスを使用して実行される場合、総当たり列挙のリスクがあります。攻撃者は、このインターフェイスを使用して携帯電話番号ライブラリを使用してリクエストの列挙を実行し、システムに登録されている携帯電話番号を特定することができます。これにより、次のステップでブルート フォース パスワード クラッキングの機会が提供されます。

この問題に関しては、この判断をログイン検証インターフェイスに入れ、明確なプロンプトを返さないことをお勧めします。よくできたウェブサイトでは、たいてい「携帯電話番号が登録されていないか、パスワードが間違っています。」というメッセージが表示されます。これによりユーザー エクスペリエンスは損なわれますが、安全性も向上します。

データ書き込みのリプレイ

フォーラム投稿を例として、パケット キャプチャ ツールを使用してフォーラム投稿のリクエスト プロセスをキャプチャし、ツールを通じてプロセスをリプレイすると、次のことがわかります。投稿リストが表示されます。 2 つの同一の投稿。これはリプレイ攻撃です。再生頻度が高速化すると、システム内に大量のジャンクデータが生成されるだけでなく、頻繁な書き込みによりビジネスデータベースに大きな負荷がかかります。

このようなリプレイリスクのあるリクエストの場合は、リクエストの頻度制限を追加することをお勧めします。たとえば、2 つのリクエストのタイムスタンプを特定し、それらが特定の時間値より大きい場合に有効になるように設定できます。

権限の脆弱性

権限の検証は、企業の組織構造管理システムなどのWebシステムの基本機能であり、部署名や部長の変更機能を提供しています。権限の検証を追加すると、ユーザーがこれらの機能を通じて使用権限のない情報を変更することを効果的に防止できます。このようなシステムでは権限の検証が必ず実装されますが、実際に正しく実装されているのでしょうか?

システム内のユーザーが部門名を変更するには、スーパー管理権限を持っていることと、部門 A に所属していることの 2 つの条件を満たす必要があると規定したとします。実際のコード実装では、開発者はユーザーがスーパー管理者であるかどうかだけを判断し、ユーザーが部門に属しているかどうかは判断しないことがよくあります。この場合、部門 B のスーパー管理アカウントを使用して部門 A の名前を変更できますが、これは権限を超えて変更することと同じですが、これは明らかに期待した結果ではありません。部門 B のスーパー管理者ユーザーがインターフェース上で部門 A の部門名を変更するための入り口を見つけられない場合でも、リクエストを取得することでパラメーターを変更できます。

無断改変はもちろん、権限を超えて閲覧することも可能です。 A 部門のスーパーマネージャーが B 部門の部門情報を参照できるとは決して期待しませんよね。

システムでは、ロールに対するユーザーのアクセス権を厳密にチェックして制限することをお勧めします。

セキュリティは決して小さな問題ではなく、冒頭でも述べたように、脆弱性があると壊滅的な打撃を受ける可能性がありますので、皆様もぜひご注意ください。ビジネス設計に注意を払うだけでなく、実装によって引き起こされる低レベルの脆弱性を回避するためのコードレビューにも注意を払う必要があります。

上記は、多数のセキュリティ脆弱性のほんの一部です。より深刻な Web アプリケーションのセキュリティ リスクについては、OWASP Top 10 2017 でリリースされたトップ 10 のセキュリティ問題を参照してください。 www.owasp.org.cn/owasp-proje…

以上がJS 検出を使用すると、Web システムは本当に安全ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。