PHPは、サーバーサイドアプリケーションにもっともよく使用されるプログラミング言語です。WordPress、Drupal、Laravel内のPHP、そしてPHPベースのアプリケーションは、ウェブアプリケーション全体の77%以上を占めています

コードベースにPHPを使用している場合、もっとも一般的なセキュリティの脆弱性とその緩和のための手順を知っておくことが重要です。セキュリティ侵害は、収益を超える莫大な費用、ユーザーや評判の損失をもたらし、コードベースやユーザー、そして従業員への潜在的な害悪となりかねません。このブログでは、以下について説明します。

  • 一般的なPHPのセキュリティ脅威
  • PHPアプリケーションのセキュリティ問題の監視方法
  • 一般的な、またNew RelicにおけるPHPのセキュリティ全般の強化方法
New RelicのPHPインテグレーション
php logo
さっそくPHPデータのモニタリングを開始しましょう。
PHPクイックスタートをインストール PHPクイックスタートをインストール

一般的なPHPのセキュリティ脅威

監視の必要な、もっとも一般的なPHPの脆弱性のいくつかを見ていきましょう。なお、以下のリストはすべてを網羅しているものではなく、攻撃者はつねに新たなセキュリティの脆弱性を狙っています。

  • クロス・サイト・スクリプティング(XSS):XSSは、攻撃者がページに悪意あるコードを挿入することにより行われます。ユーザーがそのページを閲覧すると、コードはユーザーのブラウザで実行されます。これにより、攻撃者はユーザーの情報にアクセスできるようになり、場合によってはユーザーのアカウントやマシンからアクションを実行できるようにもなります。XSS攻撃のリスクは、フォームの入力検証と出力エンコーディングにより緩和、たとえば特殊文字(特にXSS攻撃でよく使用されるもの)を他の文字に変換することなどにより緩和できます。LaravelのようなPHPフレームワークには、XSSに対する保護が組み込まれています。その他の方法として、HTMLエスケープを使用してユーザー入力をサニタイズし、悪意あるコードが実行されるのを防ぎます
  • SQLインジェクション:SQLインジェクションでは、攻撃者が悪意あるコードをSQLクエリに挿入して、データベースへのアクセスを得ます。SQLインジェクション攻撃を防ぐため、ユーザー入力がデータベースに送られる前にサニタイズする必要があります。ユーザー入力をsanitize() と filter_var()といったPHPメソッドに送り、サニタイジング処理できます。また、ユーザー入力を直接SQLクエリに送るのではなく、パラメータ化されたクエリを使用することもできます
  • クロスサイト・リクエスト・フォージェリ(CSRF):CSRF攻撃では、攻撃者はユーザーがサーバーのデータ書き換えリクエストを送信するように仕掛けます。例えば、攻撃者が本物サイトのログインフォームに偽装したフォームを含むWebページを作成したとします。ユーザーがそのフォームで認証情報を送信すると、攻撃者はユーザーのアカウントにアクセスできるようになります。このようなCSRF攻撃を保護するには、毎回のフォーム送信に独自のトークンを追加します。このトークンは、一般的にはPHPのセッション管理機能を使用して生成されます。サーバーは、リクエストの処理前にトークンが有効であることを検証できます。また、すべてのフォームにHTTPSプロトコルを使用して、毎回のリクエストでHTTPリファラヘッダーを検証することもできます
  • セッションハイジャック:セッションハイジャックはセッションフィクセーションとも呼ばれ、PHPがセッションIDを処理する方法にある脆弱性を悪用した攻撃手法です。デフォルトでは、PHPは新規セッション向けに単純にカウンターを累積していきますが、攻撃者はこれを悪用して次のIDを推測します。そこから攻撃者はユーザーのセッションを乗っ取り、悪意あるアクションを実行します。ランダムな数字の使用など、セッションIDを生成するより安全な方法を採用する必要があります。また、セキュアソケットレイヤー(SSL)を使用して、サーバーとクライアント間のコミュニケーションを暗号化することもできます
  • バッファ・オーバーフロー:バッファオーバーフローは、小さすぎる、または存在しないバッファにデータが書かれた場合に発生します。それによりデータ破損やアプリケーションの損傷が起こり、障害を引き起こします。攻撃者はバッファオーバーフローを利用して、悪意あるコードをアプリケーションに挿入したり、サービス拒否攻撃を発生させます。このリスクは、バッファを適切なサイズに設定しておくこと、またそこにデータを書き込む前に上限を確認することで低減できます。また、PHPのstrncpy()関数など、バッファ・オーバーフローを防ぐ保護機能を使用することもできます
  • サービス拒否(DoS)および分散型サービス拒否(DDoS):DoSおよびDDoS攻撃は、大量リクエストをシステムに送信し、アプリケーションリソースを使い果たして障害を発生させるように意図されています。分散型サービス拒否はより高度な攻撃で、攻撃者はボットネットとも呼ばれるウイルス感染したコンピューターのネットワークを使用して攻撃を実行します。膨大な量のトラフィックを発生させることができるため、DDoS攻撃は防御するのが非常に難しい場合があります。攻撃は、インフラストラクチャレイヤーでもアプリケーションレイヤーでも発生し得ます。DDoS攻撃を防御するには、まず不要なポートやプロトコルなどの潜在的な攻撃ポイントを最小化する必要があります。CDN(コンテンツデリバリーネットワーク)やロードバランサーの使用も、アプリケーションの脆弱なエリアを減らすのに有効です。DoSとDDoS攻撃が発生した際にうまく対応するために、New Relicなどの監視ツールを使用すると、トラフィックの不穏な急上昇や、アプリケーションのリクエスト処理能力の急低下といったメトリクスに関するアラートをチームに送信できます。また、ユーザーリクエスト処理の大幅な遅延や停止も把握できるようになります。サーバー容量やネットワーク能力(CDNなど)の臨機応変な拡張性も、このような攻撃の緩和に有効です。また、レート制限を実行して、過剰なトラフィック量によるホストへの負担を防ぐこともできます
  • パスワード解析:攻撃者は、ブルートフォース攻撃や辞書攻撃によってパスワードを破ることができます。特殊文字を使うより長いパスワードをリクエストしたり、定期的なパスワード更新を推奨、要求することで、ユーザーパスワードが破られるのを防ぐことができます。従業員向けには要求を厳格化し、多要素認証も採用するべきです。そうすることで、攻撃者はパスワードのみでアカウントに侵入することができなくなります
  • 中間者攻撃(MitM):MitM(Man-in-the-Middle)攻撃では、攻撃者はコミュニケーションを傍受したりデータ交換を操作したりして、2者間のコミュニケーションを妨害します。PHPセッションクッキーが脆弱だと、ユーザーセッションが乗っ取られ、MitM攻撃にさらされる可能性があります。PHPのリモートファイルインクルード(RFI)が脆弱だと、悪意あるコードがPHPアプリケーションに挿入される恐れもあります。すべてのユーザー入力を検証し、すべてのクッキーを安全に保つための手順を取ることで、MitM攻撃を防ぐことができます。また、すべての情報伝達がHTTPSを介して送信されることも重要です

PHPセキュリティ全般を強化する

ここまで、それぞれの攻撃に対する基本的なセキュリティ対策をご紹介してきましたが、次はPHPアプリケーションのセキュリティ強化についてより詳しく見ていきましょう。数え上げるときりがないので、PHPアプリケーションを保護するためにできること、すべきことは以下のリスト以外にも多くあることを覚えておいてください。PHPを含むすべてのプログラミング言語に適用できる、より包括的なコード保護の実践に関しては、OWASPのSecure Coding Practices-Quick Reference Guideをご確認ください。

  • New Relic Vunerability Management(脆弱性管理)機能を組み込む。それにより、サードパーティの依存関係内のセキュリティの脆弱性に関する情報も含め、スタック全体にわたる統合的なセキュリティビューが得られます
  • セキュアバイデザインのコード設計慣行に従う。エンジニアリングチームは、初期段階からの安全なアプリケーション構築に注力すべきです。これには、最小限の権限などの原則が含まれます。ユーザーにはアプリケーションのアクションに必要最小限の権限のみを与えるというものです。そうすれば、もしユーザーのアカウントに侵入されても、攻撃者はアプリケーションに対して限られたアクセスしか得られません
  • 攻撃を受けることを想定して、それらに備える。これは、セキュアバイデザインのベストプラクティスのもう1つの原則です。攻撃は可能であり、起こるのだと想定しましょう。そうすれば、油断につけ込まれるようなことはありません。チームの訓練、セキュリティ侵害と障害に対するプロトコルと運用ガイドラインの設定、またチームが実際の攻撃発生の際によりよく対応できるように、攻撃を想定したトレーニングを設けるといった十分な備えを行うことなどがあります
  • 安全なホストを使用する。すべてのホストが安全性を保証できるわけではありません。CDN(DoSやDDoS攻撃に対する保護のため)、ファイアウォール(不正攻撃)、SSL認証(ウェブサイトを実証し、攻撃者によるサイトの悪意ある複製を防止する)を提供するホストサービスの使用を検討しましょう
  • 故障に対して耐性を持つようにシステムを構築する。故障に対して耐性(fault tolerant)を持つようなデザインとは、システムが稼働・使用中の想定外の急上昇に対応できることを意味します。これらの急上昇は、DoSやDDoS攻撃を含め、さまざまな理由により発生します。攻撃を受けている間にもユーザーがコンテンツにアクセスできることを保証するコンテンツデリバリーネットワークの使用や、攻撃中にサービスの規模拡大ができるようにクラウドに余剰のサーバースペースや柔軟性を確保しておくことなどが考えられます。逆に、必要に応じて攻撃の影響を最小化するためにレート制限を行うこともできます
  • セキュリティ監査を実施する。自社システムのセキュリティと脆弱性を定期的に評価すべきです。これには、セキュリティ診断、システム環境と設定の評価、コード検証などがあります。New Relicの脆弱性管理機能では、すべてのアプリケーションの脆弱性を、いつでも一元的に評価することができます
  • アプリケーション内のアクティビティを監視する。New Relicのようなアプリケーションパフォーマンスツールを使用して、スループットやトランザクションレートなど、攻撃に大きな影響を受けかねない主要メトリクスを監視することができます
  • 重要なパフォーマンス閾値のアラートを設定する。監視ツールやセキュリティツールのアラートを設定し、チームが可能な限り迅速に、不穏なアクティビティの通知を受けられるようにします
  • データベースを保護し、パラメータ化を使用する。データベースを保護するためには、多くの手順が必要です。もっとも重要かつ基本的なものの1つは、パラメータ化を使用してユーザー入力をサニタイズすることです。以下は、パラメータ化を使用していない、安全ではないSQLクエリです。

    SELECT * FROM users WHERE name = '{$name}'

    攻撃者は悪意あるSQL文を入力できるため、データベースは$name入力をコマンドとして読み、コードを実行します。ここには、プライベート情報を収集するコマンドや、データベースの行を更新、さらには破壊するコマンドの入力さえもできてしまいます。以下は、MySQLのパラメータ化された例です。

    "SELECT name FROM users WHERE name = @name";

    MySQLは、パラメーターを定義するために@を使用します。SQL文をパラメーターとして使用できないため、悪意あるユーザーはパラメーターを通じて悪意あるSQL文を送信できず、SQLへのインジェクションの恐れはなくなります。Laravelを使用している場合、パラメータ化されたクエリを簡単に生成するのにEloquent ORMを使用することもできます。以下がその例です。

    $user = DB::table('users')->where('name', $name)->get();

    ここでは、$nameは、where()句を使用してパラメーターとして送られます。

New Relicでセキュリティの脆弱性を防ぐ

深刻な被害をもたらす前にセキュリティの脆弱性を発見し、パッチを適用するのは簡単ではないこともあります。特に、スタックに無数のサービスや外部の依存関係が潜在的に存在する場合にはなおさらです。もし、スタック全体のセキュリティの脆弱性に関するインサイトを得られるツールがあれば理想的です。

以下の画像が示すように、New Relicの脆弱性管理なら、スタック全体の脆弱性に関する総合的なビューが得られます。

スタック全体にわたり、未対応の脆弱性やトリアージされていない脆弱性をすべて確認できます。また、GitHubのDependabot、Lacework、Snykその他のセキュリティツールとの統合も可能で、1箇所ですべての可視性を容易に得られるようになります。New Relic脆弱性管理機能についての詳細をご確認ください。

アプリケーションパフォーマンス監視(APM)も、プロアクティブなセキュリティ対策の重要な一環です。PHPクイックスタートを使用すれば、わずか数分で開始できます。クイックスタートには、トランザクションレート、エラーレート、スループットなどの主要パフォーマンスメトリクスを表示するダッシュボードが用意されています。ウェブのトランザクションに時間がかかりすぎていたり、アプリケーションのスループットが低すぎる場合には、自動的にアラートが送信されます。これらはいずれも、エラーが起こりつつある兆候か、もしくはシステムが攻撃の対象となっていることを示すものかもしれません。また、幅広いインジケータに関する独自のアラートを設定することもできます。それにより、チームは攻撃がアプリケーションを侵害する前に通知を受けることができます。以下の画像は、エラーレートやスループットを含む、PHPアプリケーションからのメトリクスを示すNew Relicのダッシュボードです。

PHPアプリケーションのセキュリティ上の脆弱性やパフォーマンス上の問題を監視できるようになったら、次のステップとしてアラートを設定し、問題が発生した際にチームに通知することができます。

もしNew Relicが自社に最適かどうか迷っているなら、ぜひ無料ティアをお試しください。テレメトリデータ容量が毎月100GBを超えない限り、ずっと無料でご利用いただけます。わずか数分で、PHPアプリケーションに関するセキュリティの重要なインサイトを取得できるようになり、同時に安心感も得られます。