PHP のセキュリティ問題の概要

                                                       

1-XSS

XSSと呼ばれるクロスサイトスクリプティング（クロスサイトスクリプト攻撃）は、コードインジェクション攻撃です。攻撃者は、悪意のあるスクリプトをターゲット Web サイトに挿入し、ユーザーのブラウザ上で実行できるようにします。これらの悪意のあるスクリプトを使用すると、攻撃者は Cookie や SessionID などのユーザーの機密情報を取得し、データのセキュリティを危険にさらすことができます。

ソース

• ユーザーからのUGC情報

• サードパーティからのリンク

• URL パラメータ

• POST パラメータ

• リファラー (信頼できないソースからのものである可能性があります)

  # Cookie (他のサブドメインから挿入される可能性があります)

• エスケープ、フィルター、長さの制限

2-SQL インジェクションSQL ステートメントを使用すると、アカウントなしでログインしたり、データベースを改ざんしたりすることもできます。

攻撃例

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

SQLインジェクションを防御する方法

1. 変数のデータ型と形式を確認する

2. 特殊シンボルをフィルタリングする

3. 変数をバインドし、プリコンパイルを使用する声明

3-CSRFCSRF は一般にクロスサイト リクエスト フォージェリを指します

CSRF 攻撃の正式名はクロスサイトですリクエスト フォージェリ (クロス サイト リクエスト フォージェリ) は、Web サイトの悪意のある使用です。

CSRF は、信頼できるユーザーからのリクエストを偽装することで、信頼できる Web サイトを利用します。攻撃者は、ユーザーの ID を盗み、ユーザーの ID を第三者に送信します。名前。Web サイトは悪意のあるリクエストを送信します。 CRSF が行うことができることには、電子メール、テキスト メッセージの送信、トランザクション転送の実行などにユーザーの ID を使用すること、さらにはユーザーのアカウントを盗むことも含まれます。

例:

次のように: Web A は CSRF 脆弱性のある Web サイト、Web B は攻撃者によって構築された悪意のある Web サイト、ユーザー C は Web A Web サイトの正規ユーザーです

3-1 CSRF 攻撃の原理とプロセスは次のとおりです: 1. ユーザー C がブラウザを開き、信頼できる Web サイト A にアクセスし、ウェブサイト A へのログインを要求するためのユーザー名とパスワード;

2. ユーザー情報が検証された後、ウェブサイト A は Cookie 情報を生成し、ブラウザーに返します。この時点でユーザーはログインに成功します。 Web サイト A にアクセスし、通常どおり Web サイト A にリクエストを送信できます。

3. ユーザーは Web サイト A を終了する前に、同じブラウザで TAB ページを開いて Web サイト B にアクセスします。

4. その後ユーザーのリクエストを受信すると、Web サイト B は攻撃的なコードを返し、Web サイト B にアクセスするリクエストを発行します。サードパーティのサイト A;

5。これらの攻撃的なコードを受信した後、ブラウザは Cookie 情報を伝え、Web サイト B にアクセスするリクエストを送信します。ウェブサイト B の要求に従って、ユーザーが知らないうちにウェブサイト A を更新します。 Web サイト A は、リクエストが実際に B によって開始されたことを認識していないため、ユーザー C の Cookie 情報に基づいて C のアクセス許可でリクエストを処理し、Web サイト B からの悪意のあるコードが実行されます。

3-2 CSRF 攻撃に対する防御CSRF 攻撃を防御するには、現在 3 つの主な戦略があります。HTTP Referer フィールドを確認する。トークンをリクエスト アドレスに追加して検証し、HTTP ヘッダーの属性をカスタマイズして検証します。

1-HTTP Referer フィールドの確認HTTP プロトコルによると、HTTP ヘッダーには Referer と呼ばれるフィールドがあり、HTTP の送信元アドレスが記録されます。リクエスト。通常の状況では、安全な制限付きページへのアクセス要求は同じ Web サイトから送信されます。たとえば、http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory にアクセスする必要がある場合、ユーザーは最初にログインする必要があります。 Bank.example に移動し、ページ上のボタンをクリックして転送イベントをトリガーします。このとき、送金リクエストの Referer 値は、送金ボタンがあるページの URL になります。通常は、bank.example ドメイン名で始まるアドレスになります。ハッカーが銀行の Web サイトに CSRF 攻撃を実装したい場合、自分の Web サイトでリクエストを作成することしかできません。ユーザーがハッカーの Web サイト経由で銀行にリクエストを送信すると、リクエストのリファラーはハッカー自身の Web サイトを指します。 。したがって、CSRF 攻撃から防御するには、銀行の Web サイトは各送金リクエストの Referer 値を確認するだけで済みます。それが Bank.example で始まるドメイン名であれば、そのリクエストは銀行 Web サイト自体からのものであり、合法であることを意味します。リファラーが別の Web サイトである場合、ハッカーによる CSRF 攻撃である可能性があり、リクエストは拒否されます。

この方法の明白な利点は、実装がシンプルで簡単であることです。Web サイトの通常の開発者は、CSRF の脆弱性について心配する必要はありません。必要なのは、セキュリティに敏感なすべてのリクエストにインターセプタを追加することだけです。最後にReferer値を確認することができます。特に現在の既存システムの場合、既存システムのコードやロジックを変更する必要がなく、リスクもなく、非常に便利です。

ただし、この方法は絶対確実というわけではありません。 Referer の値はブラウザによって提供されます。HTTP プロトコルには明確な要件がありますが、ブラウザごとに Referer の実装が異なる場合があるため、ブラウザ自体にセキュリティ脆弱性がないことが保証されません。 Referer 値を検証する方法は、セキュリティを確保するためにサードパーティ (つまりブラウザー) に依存していますが、理論的には安全ではありません。実際、IE6 や FF2 などの一部のブラウザでは、Referer 値を改ざんする方法がすでにいくつか存在します。 Bank.example Web サイトが IE6 ブラウザをサポートしている場合、ハッカーはユーザーのブラウザの Referer 値を Bank.example ドメイン名で始まるアドレスに設定することで、検証を通過して CSRF 攻撃を実行できるようになります。

最新のブラウザを使用している場合でも、ハッカーは Referer 値を改ざんできませんが、この方法には依然として問題があります。 Referer 値にはユーザーのアクセス元が記録されるため、一部のユーザーはこれが自身のプライバシー権を侵害すると考えており、特に組織によっては、Referer 値によって組織のイントラネット内の特定の情報が外部ネットワークに漏洩することを懸念しています。したがって、ユーザー自身がリクエストを送信するときにリファラーを提供しないようにブラウザを設定できます。通常、銀行の Web サイトにアクセスすると、リクエストに Referer 値がないため、Web サイトはそれを CSRF 攻撃とみなし、正規のユーザーのアクセスを拒否します。

2-リクエスト アドレスにトークンを追加して確認します

CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造できるためです。ユーザーの認証情報は Cookie に保存されるため、ハッカーは認証情報を知らなくても、ユーザー自身の Cookie を直接使用してセキュリティ検証を通過できます。 CSRF に対抗する鍵は、ハッカーが偽造できない情報をリクエストに含めることと、その情報が Cookie に存在しないことです。ランダムに生成されたトークンをパラメータとしてHTTPリクエストに追加し、サーバー側でトークンを検証するインターセプタを作成することができますが、リクエストにトークンが存在しなかったり、トークンの内容が間違っていたりする場合は、トークンが不正である可能性があると考えられます。 CSRF 攻撃であるため、リクエストは拒否されます。

このメソッドは、Referer を確認するより安全です。ユーザーがログインしてセッションに配置した後にトークンを生成できます。その後、トークンはリクエストごとにセッションから取り出して、リファラー内のトークンと照合できます。比較してください。ただし、このメソッドの難しい点は、トークンをパラメーターの形式でリクエストに追加する方法です。 GET リクエストの場合、トークンはリクエスト アドレスに追加され、URL は http://url?csrftoken=tokenvalue になります。 POST リクエストの場合、トークンがパラメータとしてリクエストに追加されるように、フォームの最後に追加します。しかし、Webサイトではリクエストを受け付ける場所がたくさんあり、リクエストごとにトークンを追加するのは非常に面倒で見落としがちなので、JavaScriptを使ってページごとにトラバースする方法が一般的です。 dom ツリー全体については、dom 内のすべての a および form タグの後にトークンが追加されます。これでほとんどのリクエストは解決できますが、ページが読み込まれた後に動的に生成される HTML コードの場合、このメソッドは効果がなく、コーディング時にプログラマが手動でトークンを追加する必要があります。

この方法のもう 1 つの欠点は、トークン自体のセキュリティを確保することが難しいことです。特に、ユーザーが独自のコンテンツを公開することをサポートする一部のフォーラムやその他の Web サイトでは、ハッカーが自分の個人 Web サイトのアドレスを公開する可能性があります。システムはこのアドレスの後にトークンも追加するため、ハッカーは自分の Web サイトでこのトークンを入手し、すぐに CSRF 攻撃を開始することができます。これを回避するために、システムはトークン追加時に判定を加えることができ、リンク先が自社サイトの場合は後からトークンを追加し、外部ネットワークへのリンクの場合はトークンを追加しません。ただし、csrftoken がパラメーターとしてリクエストに添付されていない場合でも、ハッカーの Web サイトはリファラーを通じてトークン値を取得し、CSRF 攻撃を開始する可能性があります。これは、一部のユーザーがブラウザーのリファラー機能を手動でオフにすることを好む理由でもあります。

3-HTTP ヘッダーの属性をカスタマイズして検証します

このメソッドでも、検証にトークンを使用します。前のメソッドとは異なり、トークンを置く代わりにトークンを配置する必要はありません。 HTTP リクエストのパラメータとして、HTTP ヘッダーのカスタム属性に追加します。 XMLHttpRequest クラスを使用すると、このタイプのすべてのリクエストに csrftoken HTTP ヘッダー属性を一度に追加し、そこにトークン値を入れることができます。これにより、従来のリクエストにトークンを付加する煩わしさが解消されると同時に、XMLHttpRequestでリクエストしたアドレスがブラウザのアドレスバーに記録されず、トークンが他のWebサイトに漏洩する心配もなくなりました。リファラーを通じて。

ただし、この方法には大きな制限があります。 XMLHttpRequest リクエストは通常​​、Ajax メソッドでページの部分的な非同期リフレッシュに使用されます。すべてのリクエストがこのクラスでの開始に適しているわけではなく、このクラス リクエストを通じて取得されたページはブラウザによって記録できないため、前方、後方、更新が可能です。 、収集などの操作はユーザーに不便をもたらします。さらに、CSRF 保護を持たない従来のシステムでこの方法を保護に使用したい場合は、すべてのリクエストを XMLHttpRequest リクエストに変更する必要があり、これにより Web サイト全体がほぼ書き換えられることになります。このコストは間違いなく受け入れられません

4-CC 攻撃

4-1 CC 攻撃の原理:

CC 攻撃の原理は、攻撃者が一部のホストを制御して大量のデータ パケットを他のサーバーに継続的に送信し、サーバーがクラッシュするまでサーバーのリソースを使い果たすというものです。 CC は主にサーバー リソースを消費するために使用されます。多くの人が Web ページにアクセスすると、Web ページを開くのが遅くなるという経験は誰にでもあります。CC は複数のユーザー (ユーザーの数と同じ数のスレッド) を停止することなくシミュレートします。大量のデータ操作を必要とする (つまり、多くの CPU 時間を必要とする) ページは、サーバー リソースの無駄を引き起こします。CPU は長時間 100% であり、ネットワークが混雑し、混雑するまで常に未完了の接続が存在します。通常のアクセスは停止されます。

4-2 CC 攻撃の種類:

CC 攻撃には 3 つの種類があります。攻撃

プロキシ攻撃
• ボットネット攻撃
• 直接攻撃は、主に重要な欠陥のある WEB アプリケーションを対象としており、一般的には、Web アプリケーションに問題がある場合にのみ使用されます。プログラムの作成中、この状況は比較的まれに発生します。ボットネット攻撃は DDOS 攻撃に似ています。Web アプリケーション レベルでは防御できないため、プロキシ攻撃は CC 攻撃者です。通常、攻撃者は 100 個のプロキシなどのプロキシ サーバーのバッチを操作し、各プロキシが 10 個のリクエストを発行します。これにより、WEB サーバーは 1,000 の同時リクエストを同時に受信し、プロキシから返されたデータが自身の帯域幅をブロックして別のリクエストを開始できなくなるのを防ぐために、リクエストの送信後すぐにプロキシから切断されます。このとき、WEBサーバーはこれらのリクエストに応答する処理をキューイングし、データベースサーバーも同様に、食堂に行ったときと同じように、通常のリクエストは最後に処理されます。食事をするのに、いつも並んでいるのは 10 人未満です。今日は、目の前に 1,000 人が並んでいる場合、順番が来る可能性は非常に低いです。このとき、ページが開くのが非常に遅くなるか、遅くなります。白い画面が表示されます。

4-3 CC 攻撃と DDOSDDoS の違いは、IP に対する攻撃であるのに対し、CC はサーバー リソースを攻撃することです。

5-DOS 攻撃DOS: 中国語名はサービス拒否であり、DOS 動作を引き起こす可能性のあるすべての攻撃は DOS 攻撃と呼ばれます。この攻撃の影響は、コンピュータまたはネットワークが通常のサービスを提供できなくなることです。一般的な DOS 攻撃には、コンピュータ ネットワークの帯域幅や接続に対する攻撃が含まれます。 DOS は、スタンドアロン コンピュータ間のスタンドアロン攻撃です。

DOS 攻撃の原理: まず、攻撃者は攻撃対象サーバーに偽の IP リクエストを大量に送信し、攻撃対象サーバーはリクエストを受信した後に確認情報を返し、攻撃者の確認を待ちます。 (プロトコルの仕組みと TCP スリーウェイ ハンドシェイクに関する基礎知識) このプロセスには TCP の 3 ウェイ ハンドシェイクが必要です。攻撃者が送信したリクエスト情報は偽であるため、サーバーは返された確認情報を受信できず、サーバーは一定期間待機状態になりますが、このリクエストに割り当てられたリソースは解放されていません。攻撃者が一定時間待機すると、タイムアウトにより接続が切断されますが、その際に攻撃者は再度新たな偽の情報要求を送信するため、最終的にはサーバーのリソースが枯渇し、麻痺状態に陥ります。

6-DDOS 攻撃DDoS 攻撃は、分散型サービス拒否攻撃です。DDoS 攻撃手法は、従来の DoS 攻撃に基づいています。生み出された攻撃方法。通常、単一の DoS 攻撃は 1 対 1 で行われますが、コンピュータおよびネットワーク技術の発展に伴い、DoS 攻撃の難易度は高まっています。そこで DDoS 攻撃が誕生しました。その原理は非常に単純です。コンピュータとネットワークの処理能力が 10 倍に向上しました。1 台の攻撃マシンによる攻撃はもう機能しません。その後、より多くのパペット マシンを使用して DDoS が開始されます。攻撃、被害者を攻撃します。」以前よりも大きな規模で。一般的に使用される DDoS ソフトウェアには、LOIC が含まれます。

ここに 2 つの点を追加します: まず、ルータは特殊なタイプのコンピュータであるため、DDOS 攻撃はコンピュータだけでなくルータも攻撃する可能性があります。第 2 に、ネットワーク速度が攻撃の有効性と速さを決定します。ネットワーク速度が制限されている環境では、攻撃の影響はあまり明らかではありませんが、ネットワーク速度が速いほど効果的です。

以上がPHP のセキュリティ問題の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。