ホームページ  >  記事  >  運用・保守  >  一般的な Web セキュリティの脆弱性とテスト方法は何ですか?

一般的な Web セキュリティの脆弱性とテスト方法は何ですか?

王林
王林転載
2023-05-15 13:28:061655ブラウズ

1. セキュリティ テストの 6 つの基本原則:

認証: 認証されたユーザーのリクエストの返却

アクセス制御: 認証されていないユーザーの権限制御とデータ保護

整合性: ユーザーはサーバーから送信された情報を正確に受信する必要があります

機密性: 情報は対象のユーザーに正確に配信される必要があります

信頼性: どのくらいの頻度で失敗しますか?ネットワークが障害から回復するまでにどれくらい時間がかかりますか?致命的な障害に対処するためにどのような手順が取られますか? (個人的には、この場所はフォールト トレランスと災害耐性テストのカテゴリにもっと偏るべきであると理解しています)

否認防止: 受信したデータが特定のサーバーからのものであることをユーザーが証明できる必要があります。

2. 共通セキュリティテスト内容

権限制御

SQLインジェクション

URLセキュリティテスト

XSS(クロスサイトスクリプティング攻撃) )

CSRF (クロスサイト リクエスト フォージェリ) )

URL ジャンプの脆弱性

その他のセキュリティに関する考慮事項

3. Web アプリケーションのセキュリティ問題の原因は何ですか?一般に、いくつかの理由があります:

1. 複雑なアプリケーション システムには、大量のコードと多数の開発者が含まれるため、過失は避けられません。

2. システムは何度もアップグレードされ、担当者も頻繁に変更されたため、コードの不整合が発生しました。

3. 過去のレガシーシステムや試用運用システムなど、複数のWebシステムが同一サーバー上で稼働します。

4. 開発者がセキュア コーディングのトレーニングを受けていないか、企業に統一されたセキュア コーディング標準が存在しないだけです。

5. テスターは経験が浅い、または専門的なセキュリティ評価テストを受けずにリリースされています。

6. ユーザー入力の検証はありません。ここにいくつかの例があります:

1) ユーザー入力を決して信頼せず、ユーザー入力を確認してください

2) 数値入力は次のとおりです。有効な番号

3) 文字入力には、エンコード記号の特別な処理が必要です

4) Get、Post、Cookie、その他のHTTPヘッダーを含むすべての入力ポイントを確認します

4. 共通セキュリティ テストの脆弱性と解決策:

1. XSS クロスサイト スクリプティング攻撃

SS は SQL インジェクションに似ていますが、XSS は主にフロントエンド HTML と JavaScript を使用して Web ページを通じて悪意のあるスクリプトを挿入します。スクリプト。ユーザーが Web を閲覧すると、ユーザーのブラウザの動作を制御する攻撃手法が実装されます。

XSS が成功すると、ユーザーの Cookie を取得し、その Cookie を使用して Web サイトに対するユーザーの操作権限を盗むことができます。また、ユーザーの連絡先リストを取得し、攻撃者の ID を使用して特定のターゲットをターゲットにすることもできます。グループへの大量のスパムなど。

XSS は、ストレージ型 (永続 XSS)、リフレクション型 (非永続 XSS)、DOM 型の 3 つのカテゴリに分類されます。

テスト方法:

データ入力インターフェイスに、次のように入力します: <script>alert(/123/)</script>。保存に成功した後にダイアログ ボックスが表示された場合は、 XSS 脆弱性があることを示します。

または、URL リクエストのパラメータを <script>alert(/123/)</script> に変更します。ページ上にダイアログ ボックスが表示された場合は、XSS 脆弱性があることを示しています。

2. SQL インジェクション

SQL インジェクションは、Web フォーム送信に SQL コマンドを挿入するか、ドメイン名またはページ リクエストのクエリ文字

文字列を入力し、最終的にはサーバーをだまして悪意のある SQL コマンドを実行します。

SQL インジェクションによって引き起こされる可能性のある危害には、Web ページとデータの改ざん、コア データの盗難、データベースが配置されているサーバーの攻撃によるパペット ホストなどがあります。

たとえば、一部の Web サイトではプリコンパイル済み SQL が使用されておらず、インターフェイス上でユーザーが入力した一部のフィールドが SQL に追加されています。これらのフィールドには悪意のある SQL コマンドが含まれている可能性が非常に高くなります。例:password = "1' OR '1'='1"; ユーザーのパスワードが分からない場合でも、通常どおりログインできます。

テスト方法:

クエリが必要なページで、正しいクエリ条件と 1=1 などの簡単な SQL ステートメントを入力し、応答結果を確認します。正しいクエリ条件の入力が一貫しているということは、アプリケーションがユーザー入力をフィルタリングしていないことを意味し、SQL インジェクションの脆弱性があると最初に判断できます。 、正規表現を使用するか、長さを制限できます。次のキーワードなどを変換します。;

||alert|and|exec|execute|insert|select|delete|update|count|drop|chr| mid|master|truncate|declare|sitename|netuser |xp_cmdshell|or| |,|like'|and|exec|execute|insert|create|drop|table|from|grant|group_concat|column_name|information_schema.columns|table_schema| Union|where|select|delete|update|order |by|count|chr|mid|master|truncate|declare|or|--| |,|like|//

動的アセンブリ SQL は使用しないでください、パラメータ化された SQL を使用するか、ストアド プロシージャを直接使用できます。データのクエリとアクセスを実行します。

管理者権限でデータベース接続を使用せず、アプリケーションごとに権限が制限された個別のデータベース接続を使用します。

例外アプリケーションの情報はできる限り少なくする必要があります。 ヒントとして、元のエラー メッセージをカスタム エラー メッセージでラップすることをお勧めします。

3. URL ジャンプの脆弱性

URL ジャンプの脆弱性、つまり未検証のリダイレクトの脆弱性は、パラメータ内の URL に直接ジャンプする Web プログラム、またはページ内に導入される Web プログラムを指します。開発者の URL は安全でないサードパーティ領域にリダイレクトされるため、セキュリティ上の問題が発生します。

テスト方法:

1. パケット キャプチャ ツールを使用してリクエストをキャプチャします。

2. 302 URL を取得し、ターゲット アドレスを変更して、ジャンプできるかどうかを確認します。

ps: ただし、多くのジャンプにはリファラー検証が追加されているため、攻撃者はジャンプに失敗します。

4. ファイル アップロードの脆弱性

ファイル アップロード攻撃とは、攻撃者が実行可能ファイルをサーバーにアップロードして実行することを意味します。

この攻撃方法は最も直接的かつ効果的です。アップロードされるファイルには、ウイルス、トロイの木馬、悪意のあるスクリプト、Web シェルなどが含まれる可能性があります。

Webシェルとは、asp、php、jsp、cgiなどのWebファイルの形式で存在するコマンド実行環境であり、Webバックドアとも言えます。攻撃者が Web シェルを阻止したり、影響を受けるシステムに Web シェルを挿入したりすると、Web シェルを通じて簡単にシステムに侵入し、Web サイト サーバーを制御することができます。

テスト方法:

アップロードされるファイルの種類やサイズなどを厳密に検証し、悪意のあるコードを含むファイルのアップロードを禁止します。

該当するディレクトリの実行権限を確認してください。ブラウザから Web サーバー上のすべてのディレクトリにアクセスし、ディレクトリ構造が返されるかどうかを確認してください。ディレクトリ構造が表示される場合は、セキュリティ上の問題がある可能性があります。

5. CSRF クロスサイト偽装リクエスト攻撃

CSRF は、ログイン ユーザーの ID を使用して、ユーザーの名前で悪意のあるリクエストを送信し、違法な操作を実行します。

例: ユーザーが CSRF 脆弱性のある Web サイト A を閲覧して信頼した場合、ブラウザーは対応する Cookie を生成し、ユーザーは Web サイトを終了せずに危険な Web サイト B にアクセスします。

危険な Web サイト B は Web サイト A へのアクセスを必要とし、リクエストを行います。ブラウザはユーザーのCookie情報を持ってWebサイトAにアクセスしますが、WebサイトAではユーザー自身からのリクエストなのか、危険なWebサイトBからのリクエストなのかが分からないため、危険なWebサイトBからのリクエストを処理し、ユーザー操作のシミュレーションが完了します。 。これがCSRF攻撃の基本的な考え方です。

テスト方法:

1. 同じブラウザで 2 つのページを開き、一方のページの権限が切れた後、もう一方のページは正常に操作できるか? まだ正常に操作できる場合は、リスクです。

2. ツールを使用してリクエストを送信し、http リクエスト ヘッダーにリファラー フィールドを追加せず、返されたメッセージの応答を確認し、エラー インターフェイスまたはログイン インターフェイスにリダイレクトします。

以上が一般的な Web セキュリティの脆弱性とテスト方法は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はyisu.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。