ウェブを安全に保つ方法

1. はじめに

インターネットの発展の初期、それはまだ IE ブラウザの時代でした。インターネットサーフィンとは、ブラウザを通じて情報を共有したり、ニュースを入手したりすることでした。インターネットの急速な発展に伴い、ウェブページでできることはますます増え、ニュースを読んだり、ゲームをしたりするだけでなく、ショッピングやチャットなど、私たちの生活を豊かにしてくれています。

Web ページの機能が徐々に増加するにつれて、何らかの技術的手段で利益を得ようとするブラックハットが出現し始めています。たとえば、トロイの木馬ウイルスはキーボードを監視し、キーボードで入力した内容をハッカーのマシンに送信し、その内容を分析することでハッカーはゲーム アカウントとパスワードを簡単に入手できます。その後、インターネット上のさまざまなウイルスを解決する専用のウイルス対策ソフトが誕生し、開発が続けられ、ウイルス対策ソフトはコンピュータにとって欠かせないソフトウェアとなりました。

なぜこのようなセキュリティ上の問題が発生するのでしょうか?

セキュリティは最終的には信頼の問題です。誰もが通常の手順に従ってオンラインにアクセスし、個人的な利益を追求しないのであれば、セキュリティの問題について議論する必要はありません。

セキュリティの基礎は信頼にありますが、全員がお互いを信頼することは言うは易く行うは難しです。現段階で私たちができることは、セキュリティ保護を強化し続け、抜け穴がどんどん減り、違法な攻撃がますます困難になることで、徐々にブラックハットの数が減り、ウイルス作成者も減っていくことでしょう。

1. セキュリティで良い仕事をする方法

セキュリティで良い仕事をするには、まずセキュリティ問題の属性を理解する必要があります。先人たちは、数え切れないほどの実践を通じて、最終的にセキュリティ問題の属性を要約しました。 :

1) 機密性

データ コンテンツを漏洩から保護します。通常は暗号化方式が使用されます。

2) 完全性

データコンテンツが完全であり、改ざんされていないことを保護します。通常はデジタル署名方式が使用されます。

3) 可用性。

データはいつでも使用できます。通常は DOS に対して防御します。

2. セキュリティ評価

セキュリティの 3 つの要素が得られたら、セキュリティ問題を評価できます。

1) 資産レベルの分類

最も重要なデータを見つけます。データベースなどで最も重要なデータのホスティング スペースを見つけ出すと、データベースは防御に重点を置く必要があります。データベースのホスティング スペースを調べます。たとえば、サーバー上で、このサーバーは二次防御を提供する必要があります。 OSI ネットワーク レベルでサーバーのホスト スペースを調べてから、ネットワーク レベルで一般的な防御を行う必要があります。

2) 脅威分析

脅威 (危害を引き起こす可能性のあるソース) を見つけます。リスクを調べます（損失の可能性をリスクと呼びます）。

3) リスク分析

は、多基準の意思決定分析を採用しています。つまり、リスク = 脅威レベル * 脅威の実現可能性です。すべての脅威を計算し、最終的なリスクをランク付けし、リスクの高い問題に優先順位を付けます。

4) 解決策の確認

安全でない実装を見つけて解決策を決定します。このソリューションによって、ビジネス要件の本来の意図が変更されるべきではありません。ソリューションはユーザーに対して透過的であり、ユーザーの習慣を変えないようにする必要があります。

セキュリティ評価が完了すると、セキュリティ ソリューションが得られます。その後のセキュリティ作業は、この計画に従うだけで問題ありません。

3. 安全原則

安全ソリューションを確立した後、いくつかの安全原則を策定することもできます。原則に従うことで、半分の労力で 2 倍の結果を得ることができます。

1) ブラックリストとホワイトリストの原則

ホワイトリスト ソリューションは、安全なリソースを承認することを指します。ブラックリスト化スキームとは、安全でないリソースを無効にすることを指します。通常、ブラックリストではすべての安全でないリソースをカウントできないため、ホワイトリスト ソリューションの使用を優先する必要があります。たとえば、スクリプト、CSS、イメージ タグなど、XSS を攻撃する方法は多数あります。これらのタグをブラックリストに追加したとしても、他のタグに XSS 攻撃のリスクがないという保証はありません。

2) 最小権限の原則

必要な権限のみを付与し、過剰な権限を与えず、エラーの可能性を減らします。例：通常の権限を持つ Linux ユーザーは ~ フォルダ以下のディレクトリしか操作できません ライブラリを削除して逃げようとする場合、rm -rf / を実行すると権限が無い旨のメッセージが表示されます。

3) 多層防御の原則

この原則はバレル理論に似ており、多くの場合、安全レベルは最も短いボードに依存します。つまり、欠点を残さないでください。ブラックハットは、欠点を突破口として利用して、より大きな抜け穴を掘り出すことがよくあります。

4) データとコードの分離の原則

ユーザーデータがコードとして実行されると、データとコードの境界が混乱し、セキュリティの問題が発生します。例: XSS はこれを攻撃に使用します。

5) 予測不可能性の原則

この原則は、攻撃のしきい値を高め、改ざんや偽造に基づく攻撃を効果的に防止することです。たとえば、データベース内で数値型の自動インクリメント主キーの代わりに uuid を使用すると、攻撃者による ID の推測を防ぎ、バッチ操作を実行できます。トークンには予測不能性も利用されており、攻撃者はトークンを構築できず、攻撃することができません。

これらのセキュリティ原則を念頭に置いて、一般的な攻撃と防御のケースをいくつか紹介しましょう。

2. セキュリティ攻撃・防御事例

セキュリティ攻撃・防御事例は多数ありますが、ここでは比較的出現率の高いセキュリティ問題を中心に紹介します。

(1) クライアント攻撃

主に、XSS 攻撃、CSRF 攻撃、クリック ハイジャッキングが含まれます。

1.

図のように、<script>alert(document.cookie)</script>というユーザー名を登録しました。このユーザー名を閲覧できる全員すべてのページで、現在のブラウザの Cookie がポップアップ表示されます。コードのロジックが Cookie を攻撃者の Web サイトに送信することである場合、攻撃者は現在のユーザーになりすましてログインできます。

XSS を攻撃するにはさまざまな方法があり、XSS 攻撃はユーザーが対話するあらゆる場所に存在する可能性があります。例:

すべての入力ボックス。

• window.location。

• window.name。

• document.referrer。

• document.cookie。 ＃＃＃＃＃＃＃＃＃＃＃＃ローカルストレージ。

• ...

• ページ上にはユーザーと対話する場所が非常に多くあるため、XSS 攻撃手法がいくつか存在するはずです。ブラックハットに発見されると重大な影響を与える可能性があるため注意が必要です。
• 1) XSS 攻撃の影響
  XSS 攻撃が成功すると、攻撃者は次のような大量のユーザー情報を取得する可能性があります。

ユーザー UA の特定。ユーザーのブラウザ拡張機能を特定します。ユーザーが訪問した Web サイトを特定します。 (CSS Visited プロパティ経由。) ユーザーの実際の IP を取得します。 （WebRTC経由など） Cookieの盗用（ユーザーログインの偽造、ユーザー情報の盗用） XSSフィッシング。 (ページにログイン ポップアップ ウィンドウを挿入し、ユーザーに Web サイト内のログイン ポップアップ ウィンドウ (実際にはフィッシング Web サイトからのもの) だと思わせます。ユーザーがログインすると、アカウントとパスワードがフィッシング サイトに漏洩します。 )

2) XSS 攻撃防御

現在、XSS はインターネット業界の注目を集めており、多くの開発フレームワークに安全な HTML レンダリング メソッドが組み込まれています。

一部のセキュリティ構成をカスタマイズすることもできます。

フロントエンド JS が Cookie を操作できないように、HTTP で http-only ヘッダーを構成します。ユーザーがデータを送信するときに XssFilter を使用して安全でないデータを除外する入力チェック。出力検査。ページがレンダリングされるときに危険なデータを除外します。

簡単に言うと、js による cookie の操作を禁止、送信時に html をチェック、出力時に html をチェック (トランスコード可能)

2、CSRF 攻撃

CSRF (クロスサイト)リクエスト フォージェリ) クロスサイト リクエスト フォージェリは、ユーザーの ID を使用してユーザーが意図しない操作を実行する方法です。

例:

ユーザーは最初にサーバー B にログインし、次にサーバー C にアクセスしました。サーバー C は、悪意のあるスクリプトを使用して A になりすまし、サーバー B 上の特定の関数を呼び出します。サーバー B にとって、これは A によって開始されたリクエストであると考えられ、通常のリクエストとして処理されます。

想像してみてください。CがAになりすまして送金すると、間違いなく多大な経済的損失が発生します。

1) CSRF の防御方法

CSRF に対する防御方法は主に以下のとおりです:

a. 検証コードリファラーチェック

ユーザーに次のことを要求します。すべてのリクエストを検証して、リクエストが本物であることを確認します。つまり、悪意のあるスクリプトが複雑な検証コードを認識できないという事実を利用して、すべてのリクエストが合法であることを確認します。

b. リファラーチェック

リクエストを開始したサーバーがターゲットサーバーであるかどうかを確認します。つまり、HTTP リクエストの Referer ヘッダーには現在のリクエストのドメイン名が渡されており、このドメイン名が不正なサーバーのドメイン名である場合にはアクセスを禁止する必要があります。

c, トークン

予測不可能性の原則を使用して、各リクエストにはランダム コードが含まれている必要があります。このランダム コードは通常のユーザーによって保存されます。ブラック ハットはランダム コードを知らないため、リクエストを実行できませんユーザーになりすまして作成されました。

(学習ビデオ共有:

php ビデオ チュートリアル

)

3. クリック ハイジャック

クリック ハイジャックは、視覚的に欺瞞的な攻撃手法です。攻撃者は、iframe ネストを通じて攻撃対象の Web サイトを自分の Web ページに埋め込み、iframe を透明に設定し、ページ上にボタンを表示してユーザーのクリックを誘導します。

画像の上に透明な紙を重ねたようなもので、見えているのは攻撃者のページですが、実際にはこのページは一番下にあるだけで、実際にクリックしたのが攻撃者のページです。別のウェブページ。

1) クリックハイジャック防御

クリックハイジャックは主に iframe を経由するため、防御は主に iframe に基づいています。

オプション 1: フレームバスティング

if (self !== top) {  // 跳回原页面
  top.location = self.location;
}

通常の Web サイトは、JS スクリプトを使用して、悪意のある Web サイトによって埋め込まれているかどうかを判断します。たとえば、ブログ Web サイトが iframe によって開かれていることを検出すると、自動的に通常ページへジャンプします。

オプション 2: HTTP で x-frame-options ヘッダーを使用して iframe の読み込みを制御します。これには 3 つのオプション値があります:

DENY、これはページが許可されていないことを意味します。 iframe を通じて表示されます。 SAMEORIGIN は、同じドメイン名で iframe を介してページを表示できることを意味します。 ALLOW-FROM は、指定されたソースからの iframe でページを表示できることを意味します。

配置 iframe 的 sandbox 属性：sandbox = "allow-same-origin" ，则只能加载与主站同域的资源。

（二）服务端攻击

服务器端的攻击的方式也非常多，这里列举几个常见的。

SQL 注入攻击文件上传漏洞登录认证攻击应用层拒绝服务攻击webServer 配置安全

1、SQL 注入攻击

SQL 注入和 XSS 一样，都是违背了数据和代码分离原则导致的攻击方式。

如图所示，我们利用 SQL 注入，就能在不需要密码的情况下，直接登录管理员的账号。

攻击的前提是：后端只用了简单的拼接 SQL 的方式去查询数据。

// 拼接出来的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'
// 无论密码输入什么，这条 sql 语句都能查询到管理员的信息

除此之外，SQL 注入还有以下几种方式：

a、使用 SQL 探测，猜数据库表名，列名。

通过 MySQL 内置的 benchmark 探测数据库字段。如：一段伪代码 select database as current if current[0]==='a',benchmark（10000,'猜对了'） 如果表明猜对了，就延迟 10 s 并返回成功。

b、使用存储过程执行系统命令

通过内置的方法或存储过程执行 shell 脚本。如：xp_cmdshell、sys_eval、sys_exec 等。

c、字符串截断

如：MySQL 在处理超长的字符串时，会显示警告，但会执行成功。注册一个 admin + 50 个空格的用户，会触发截断，最终新增一个 admin 用户，这样就能拥有管理员权限了。

1）SQL 注入防御

防止 SQL 注入的最好的办法就是，不要手动拼接 SQL 语句。

最佳方案，使用预编译语句绑定变量：通常是指框架提供的拼接 SQL 变量的方法。这样的语义不会发生改变，变量始终被当成变量。严格限制数据类型，如果注入了其他类型的数据，直接报错，不允许执行。使用安全的存储过程和系统函数。

2、CRLF 注入

在注入攻击中，换行符注入也是非常常见的一种攻击方式。

如果在 HTTP 请求头中注入 2 个换行符，会导致换行符后面的所有内容都被解析成请求实体部分。攻击者通常在 Set-Cookie 时，注入换行符，控制请求传递的内容。

3、文件上传漏洞

上传文件是网页开发中的一个常见功能，如果不加处理，很容易就会造成攻击。

如图所示，攻击者上传了一个木马文件，并且通过返回的 URL 进行访问，就能控制服务器。

通常我们会控制上传文件的后缀名，但也不能完全解决问题，攻击者还可以通过以下方式进行攻击：

• 伪造正常文件

• 将木马文件伪装成正常的后缀名进行上传。

• 如果要避免这个问题，我们可以继续判断上传文件的文件头前 10 个字节。

• Apache 解析方式是从后往前解析，直到找到一个认识的后缀名为止

• 如：上传一个 abc.php.rar.rar.rar 能绕过后缀名检查，但在执行时，被当成一个 php 文件进行执行。

• IIS 会截断分号进行解析

• 如：abc.asp;xx.png 能绕过后缀名检查，但在执行时，被当成一个 asp 文件进行执行。

• HTTP PUT 方法允许将文件上传到指定位置

• 通过 HTTP MOVE 方法，还能修改上传的文件名。

• 通过二者配合，就能先上传一个正常的后缀名，然后改为一个恶意的后缀名。

• PHP CGI 路径问题

• 执行 http://abc.com/test.png/xxx.php 时，会把 test.png 当做 php 文件去解析。

• 如果用户正好是把一段恶意的 php 脚本当做一张图片进行上传，就会触发这个攻击。

1）文件上传漏洞防御

防御文件上传漏洞，可以从以下几点考虑：

将文件上传的目录设置为不可执行。判断文件类型检查 MIME Type，配置白名单。检查后缀名，配置白名单。使用随机数改写文件名和文件路径上传文件后，随机修改文件名，让攻击者无法执行攻击。单独设置文件服务器的域名单独做一个文件服务器，并使用单独的域名，利用同源策略，规避客户端攻击。通常做法是将静态资源存放在 CDN 上。

4、登录认证攻击

登录认证攻击可以理解为一种破解登录的方法。攻击者通常采用以下几种方式进行破解：

• 彩虹表

• 攻撃者は、平文と MD5 の間の多数の対応関係を収集し、MD5 暗号文を解読して元のテキストを見つけます。

• レインボー テーブルの MD5 パスワードについては、ソルトを追加して二次暗号化を実行して、解読を回避できます。

• セッション固定攻撃

• サーバー上のアプリケーション システムのセッション ID 固定メカニズムを使用して、同じものを使用する他のユーザーの助けを借りて認証と認可を取得します。セッションID。

• 攻撃者がログインに失敗すると、バックエンドはセッション ID を返します。攻撃者は、ログインするために通常のユーザーにセッション ID を与えます。ログインが成功すると、攻撃者はこれを使用できます。通常のユーザーになりすましてログインするためのセッションID。

• ブラウザがログインするたびにセッション ID を更新すると、この問題は回避できます。

• セッション維持攻撃

• ユーザー エクスペリエンスのために、ユーザーがまだいる限り、バックエンドはユーザーを許可しないことがあります。生きています。セッションは無効です。

• 攻撃者は、継続的にリクエストを行うことで、このセッションを存続させることができます。

1) ログイン認証の防御方法

多要素認証のパスワードは防御の第一線として使用されますが、パスワードの検証が成功した後は、引き続き次のことを行うことができます。検証: ユーザーのセキュリティを確保するための動的パスワード、デジタル証明書、SMS 検証コードなど。 SMS と Web ページは完全に独立したシステムであるため、攻撃者が SMS 認証コードを入手することは困難であり、攻撃を実行することはできません。

5. アプリケーション層のサービス拒否攻撃

アプリケーション層のサービス拒否攻撃は、DDOS 攻撃とも呼ばれ、大量のリクエストを使用してリソースの過負荷を引き起こし、サーバーに障害を引き起こすことを指します。利用できなくなること。

#通常、次の DDOS 攻撃方法があります。

• #SYN フラッド フラッド攻撃

• HTTP 3 ウェイ ハンドシェイク メカニズムを使用して、サーバー接続リソースを消費します。

• 例: 攻撃者が大量の HTTP リクエストを開始しましたが、3 回のハンドシェイクは完了せず、2 回のハンドシェイクのみを完了しました。このとき、サーバーはタイムアウトになるまで待機し続けます。現時点では、サーバーは大量のガベージ リクエストの処理で忙しく、通常のリクエストを処理する時間がありません。

• Slowloris 攻撃

• HTTP リクエスト ヘッダーを非常に遅い速度で送信し、サーバー接続リソースを消費します。

• 例: 攻撃者は大量の HTTP リクエストを送信しますが、各リクエスト ヘッダーの送信は非常に遅く、10 秒ごとに 1 文字ずつ送信されます。データを待つために、サーバーは常に接続を維持する必要がないため、開始するとすぐにサーバー接続の数がすぐに消費されてしまいます。

• HTTP POST DOS

• HTTP を送信するときに、非常に長い Content-Length を指定して長い間隔で送信すると、サーバー接続リソースが消費されます。 。

• CC 攻撃

• リソースを非常に消費するいくつかのページに対するリクエストを継続的に開始します。

• 例: ページ内の一部のページでは、バックエンドでの大量の計算や、非常に時間のかかるデータベース クエリが必要です。リクエストが大量に発生すると、サーバーの CPU、メモリ、その他のリソースが占有される可能性があります。

• サーバー制限 DOS

• XSS 経由で長すぎる Cookie を挿入すると、リクエスト ヘッダーの長さが Web サーバーの容量を超えます。サーバー側 このサービスは拒否されます。

• ReDOS

• 欠陥のある正規表現を狙って、大量のリクエストが開始され、システム リソースが消費されます。

1) アプリケーション層のサービス拒否攻撃の防御

現時点では、アプリケーション層のサービス拒否攻撃に対する特に完璧なソリューションはありませんが、いくつかの最適化は可能です。

アプリケーション コードのパフォーマンスを最適化し、Redis や Memcache などのキャッシュ ソリューションを合理的に使用して CPU リソースの使用量を削減します。ネットワーク アーキテクチャを最適化し、バックエンドで負荷分散を構築します。静的リソースは CDN を使用して管理されます。リクエスト頻度の制限 サーバーはすべての IP アドレスのリクエスト頻度を計算し、異常な IP を除外して無効にします。 LRU アルゴリズムを使用して、最初の 1,000 リクエストの IP アドレスをキャッシュできます。IP リクエストの頻度が高すぎる場合は、これを無効にします。

実際、DDOS に対処する基本的な考え方は、信頼できないユーザーを無効にして、リソースが通常のユーザーによって使用されるようにすることです。

3. Web サーバー構成のセキュリティ

Web アプリケーションをデプロイするとき、Nginx、Apache、IIS、Tomcat、Jboss などの Web サーバーを使用することがよくありますが、これらのサーバー自体にもいくつかのセキュリティ リスクがあります。設定が不適切な場合、攻撃を受けやすくなります。

Web サーバーを設定するときは、次の点を参照してください:

1. ユーザー権限で Web サーバーを実行します

最小権限の原則に従い、最小限の権限を持つ Web サーバーは、侵入された後にアクセス許可を制限します。

2. ビジュアル バックエンドの削除

Tomcat や Jboss などの Web サーバーを実行している場合、ビジュアル操作バックエンドはデフォルトで有効になり、ポート 8080 で実行され、最初のアクセスは行われません。認証されました。

攻撃者はビジュアル背景を使用して、リモートから war パッケージをロードしたり、制御のためにトロイの木馬ファイルをアップロードしたりできるため、ビジュアル プラットフォームを削除する必要があります。

3. 適時にバージョンを更新してください

主要な Web サーバーは時々いくつかの脆弱性を修正するため、適時にバージョンを更新することを忘れないでください。

関連する推奨事項: Web サーバーのセキュリティ

以上がウェブを安全に保つ方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。