前に書いてある
今日は、一般的な Web 脆弱性の原則とそれに対応する強化策、およびこれらの脆弱性がよく発生する場所をクラスメートと共有します。OWASP Top10 と脆弱性の原則とその強化策も、ネットワーク セキュリティ エンジニアの面接で一般的な試験質問です。私の限られたレベルに基づいて、ピカチュウ射撃場と私が学んだコースからいくつかの説明を集めましたが、個人的には、より正確な説明が誰にでも理解できると思います。一緒に :)
1.SQLインジェクション
原則:プログラム コマンドとユーザー入力の間には区別がないため、攻撃者はプログラム コマンドをユーザー入力データとして Web に送信する機会があり、Web は関連するパラメーターを処理せずに直接データベース クエリ操作に受け入れ、その結果、攻撃者はデータベースを取得し、権限を管理し、徐々に権限を昇格させ、最終的にはサーバーのオペレーティング システムを制御します。
強化:ユーザーが入力したデータの厳密な検査、データベース構成における最小権限の原則、特殊文字のエスケープ処理またはエンコード変換、厳密なデータ長、Web サイトの各データ層の均一なエンコード (すべて utf-8 エンコードを使用)、 Web サイトが SQL エラー メッセージをエコーするのを防ぎ、Web サイトが公開される前に専門的な SQL インジェクション検出ツールを使用し、Web サイト ユーザーのデータベース操作権限を制限します。
2. XSS クロスサイト スクリプティング攻撃
分類:反射型 (1 回限りの非永続的なクロスサイト スクリプティング攻撃。現在のページ訪問にのみ影響します)、ストレージ タイプ (永続的なクロスサイト スクリプティング攻撃、攻撃者はサーバー側にデータを保存します)、DOM タイプ (反射タイプの場合もあれば、ドキュメント オブジェクト モデルに基づく脆弱性であるストレージ タイプの場合もあります)。
原則: JS を使用して HTML、CSS、ブラウザの特性を柔軟に操作し、悪意のある攻撃を完了するための JS スクリプトを構築します。ユーザーが XSS によって挿入された Web ページにアクセスすると、ユーザーのブラウザは XSS コードを解析してページのネストを形成し、ポップアップウィンドウの構造、ページのリダイレクト、イメージタグの利用、ウェブサイトスタリオンなど。
一般的な場所:
警告
窓の場所
location.href
オンロード
送信時
エラー時
<iframe>
<テキストエリア>
<画像>
<スクリプト>
3. CSRF クロスサイトリクエストフォージェリ
原則:サーバーがリクエストヘッダーを厳密にフィルタリングしていないことが原因であることが多く、CSRF 脆弱性を判断するポイントは、重要な情報 (パスワードやその他の機密情報など) の操作 (追加、削除、変更) が不正な操作を行っているかどうかを判断することです。厳密な検証が行われており、偽造が容易です。
強化:機密情報の操作に安全なトークンを追加し (トークンには適時性があります)、機密情報の操作に安全な検証コードを追加し、機密情報の操作のための安全なロジック フローを実装します (パスワード変更時など)。 、パスワードを最初に確認コードを追加するなど）、リファラー証拠チェーンの参照も CSRF の防止に非常に効果的です。
トークン: ランダムな検証パラメータ。サーバーにリクエストを行う場合、トークン パラメータを送信する必要があります。トークン検証が正しい場合にのみ、サーバーはクライアントのリクエストを処理します。
リファラー: メッセージ ヘッダーは、リクエストを行った元の URL を示すために使用されます。
4.SSRF
原則: SSRF の原因のほとんどは、サーバーが他のサーバー側アプリケーションからデータを取得する機能を提供し、Web ページのテキスト コンテンツを指定された URL アドレス、指定されたアドレスにある文書や画像のロードなど、攻撃者は改ざんされたリソース要求をサーバーに送信しますが、サーバーは要求の正当性を検証せず、サーバーはその ID を使用して他のサーバーにアクセスします。 。
比較: CSRF と SSRF の違いは、CSRF リクエストは他のサーバーを攻撃せず、ユーザーになりすましてサイト上で操作を実行することです。
一般的な場所:
URL アドレスを介して Web ページのコンテンツを共有する
トランスコーディングサービス
オンライン翻訳
画像のロードとダウンロード: URL アドレス経由で画像をロードまたはダウンロードします。
画像・記事コレクション機能
URL を呼び出すパブリック API およびその他の関数用に実装されます。
URLキーワードからshare、wap、url、srcを検索
ファイルプロトコルを使用してローカルファイルを読み取る
外部リソースを呼び出すすべてのパラメータには SSRF が含まれる場合があります...
5.XXE
原則:外部エンティティ DTD を解析できる拡張マークアップ言語 XML の特性に基づいて、攻撃者は慎重に構築された XML エンティティ コンテンツをサーバーに注入し、指定された構成に従ってサーバーを実行させ、問題を引き起こします。クライアント側の XML データは、厳密なセキュリティ制御がないと、XML 外部エンティティの挿入につながります。
補強:現在、多くの言語の対応する XML 解析関数は、デフォルトで外部エンティティのコンテンツを解析することが禁止されているため、この脆弱性の発生を回避しています。php を例にとると、php は libxml を使用して xml を解析します。 2.9.0 および上記のバージョンでは、XML 外部エンティティの内容の解析が禁止されていました。
一般的な場所:
<!エンティティ...
6. PHPのデシリアライゼーション
原則: php がネットワーク上でオブジェクトを送信する必要がある場合、または送信を容易にするためにオブジェクトをファイルまたはデータベースに書き込む必要がある場合、オブジェクト全体をバイナリ文字列 (シリアル化) に変換し、それが他のファイルに到達したときに、オブジェクト全体をバイナリ文字列に変換することができます。 end, then 元のオブジェクトに戻すプロセス (逆シリアル化)。シリアル化と逆シリアル化自体には問題はありませんが、逆シリアル化されたコンテンツがユーザー制御可能であり、PHP のマジック関数がバックグラウンドで不適切に使用されている場合、セキュリティ上の問題が発生します (例: unserialize() に渡されるとき、パラメーターがオブジェクトの内部変数や関数が制御可能である場合、攻撃者は慎重に構築されたシリアル化された文字列を渡すことで、オブジェクトの内部変数と関数を制御できます。
一般的な場所:
シリアライズ()関数
unserialize() 関数
_睡眠魔法の魔法の方法
_目覚めの魔法の魔法の方法
7. 任意のファイルがアップロードされる脆弱性
原則:ファイルのアップロード機能は Web アプリケーション システムで非常に一般的であり、たとえば、多くの Web サイトでは登録時にアバターのアップロードや添付ファイルのアップロードなどが必要になります。ユーザーがアップロードボタンをクリックすると、アップロードされたファイルが指定された種類、サフィックス名、サイズなどをバックグラウンドで判断し、設計された形式に従ってファイル名を変更し、指定されたディレクトリに保存します。バックグラウンドでアップロードされたファイルのセキュリティ判断が行われない場合、または判断条件が十分に厳密でない場合、攻撃者は、一言のトロイの木馬などの悪意のあるファイルをアップロードする可能性があり、これによりバックグラウンド サーバーが Web シェル化されます。したがって、ファイルアップロード機能を設計する際には、受信ファイルのセキュリティを厳密に考慮する必要があります。例: ファイルの種類、サフィックス名、サイズを確認する、
ファイルのアップロード方法を確認する、ある程度複雑なファイル名を変更する、ファイルのアップロード後にパスを公開しない、など...
8. 任意のファイルがダウンロードされる脆弱性
原則:ファイルのダウンロード機能は、多くの Web システムに表示されます。通常、ダウンロード リンクをクリックすると、ダウンロード リクエストがバックグラウンドに送信されます。通常、このリクエストにはダウンロードするファイル名が含まれており、バックグラウンドが開始されます。コードをダウンロードし、ファイル名に対応するファイル応答をブラウザに送信するとダウンロードが完了します。バックグラウンドが要求されたファイル名を受け取り、セキュリティ上の判断を行わずにダウンロード ファイルのパスに直接入力すると、安全でないファイル ダウンロードの脆弱性が発生する可能性があります。このとき、攻撃者が予期されるプログラムのファイル名ではなく、注意深く構築されたパス (../../../etc/passwd など) を送信すると、指定されたファイルが直接ダウンロードされる可能性が非常に高くなります。それ。その結果、バックグラウンドで機密情報 (パスワード ファイル、ソース コードなど) がダウンロードされます。したがって、ファイルのダウンロード機能を設計する際、ダウンロード対象のファイルがフロントエンドから渡される場合は、受信ファイルのセキュリティを考慮する必要があります。覚えておいてください: フロントエンドとやり取りするすべてのデータは安全ではないため、軽視すべきではありません。