2021年度のセキュリティ関連の事例を見てみても、ランサムウェア攻撃被害、EMOTETの被害など、セキュリティ事故に関わるニュースは絶えず起こっています。またこれ以外にも、Webアプリケーションの脆弱性をついた不正アクセスによる事例も挙がっています。このような不正アクセスの対策として注目を集めているのがWAFです。
私自身、これまでセキュリティについては深く学んだことがありません。そこでWAFがどのように攻撃をブロックしているのか一から学んでいるところです。そんなセキュリティ初心者の私がふと感じた疑問があります。セキュリティが重要視されている現在、インターネットでの通信は「https」が主流となり、WAFはどのようにして暗号化された通信から攻撃対象を判定しているのでしょうか？本記事をご覧の皆様で同じ疑問を持った方へ、WAFとhttpsに関する詳しい解説を踏まえ、お伝えしていきます。
WAFとhttpsとは？
まず、WAFとhttpsについて簡単に説明させていただきます。
WAF（Web Application Firewall）はWebアプリケーションの脆弱性をついた攻撃に対するセキュリティ対策のひとつです。防御対象のWebサイトにWAFを配置し、Webサイトへの攻撃の検知、防御を行うことができます。
各企業でのDX化が進んでいる中、Webサイト数も増えております。2019年では約16億だったサイト数は、2022年では約19億※1まで増えているそうです。つまり、攻撃者からしてみれば、その数だけ攻撃対象が増えているとも言えます。IPAが発表している脆弱性被害の届出※2にも、全体の約7割がWebサイトに関わるものとなっているのです。
※1 https://www.internetlivestats.com/total-number-of-websites/
※2 https://www.ipa.go.jp/security/reports/vuln/software/2021q4.html
次にhttps通信です。https通信は、http通信にSSLというプロトコルを組み合わせ、「Webサイトと利用者」間の通信を暗号化し、第三者から通信のやり取りが分からないようにしているものです。https通信を知る上で誤解してはいけないのは、 「https通信を行っている ＝ 必ずしも安全ではない」ということです。https通信で防御できるのは、あくまで「Webサイトと利用者」間の通信です。通信先のWebサイトが悪意のあるサイトであった際、https通信の暗号化機能は効果を発揮できません。
そこで登場するのが、SSLサーバ証明書になります。SSLサーバ証明書は認証局（CA）と言われる第三者機関から発行されるものです。認証局とやり取りを行い、本物のサイトであることを証明してもらった証として、Webサーバの担当者はSSLサーバ証明書を手に入れます。
入手したSSLサーバ証明書をWebサイトへインストールしておくと、利用者がWebサイトへアクセスする際にその証明書を確認することができます。よって通信先のWebサイトが正しいものであることを判断できるようになります。
また、初めにお伝えしたhttps通信を行うためにも、SSL証明書のインストールが必要となります。https通信を行うため、Webサーバ、クライアント側のブラウザにて、SSL/TLSの設定を有効化にする必要があります。仮にこの設定を行ったとしても、Webサーバにて証明書のインストールが完了していなければ、https通信を行うことができません。
長くなりましたが、https通信についてまとめると以下になります。
【 https通信の総括】
- 「Webサイトと利用者」間の通信を暗号化するもの
- 「https通信を行っている ＝ 必ずしも安全ではない」
- https通信を行うため、WebサーバにSSLサーバ証明書をインストールする必要がある
- 本物のWebサーバであることを証明するため、「SSLサーバ証明書」が存在する
WAFがhttps通信の攻撃を防御できるのはなぜ？
お伝えした通り、https通信は「Webサイトと利用者」間の通信を暗号化し、第三者に通信内容が分からないようにするものになります。この場合、Webサイト、利用者以外の対象者は第三者にあたるため、間に入るWAFも該当します。当然WAFから参照した際も、通信の内容は暗号化された状態で入ってくるので、通信内容を把握することはできません。
しかしWAFがWebサイトへの攻撃を防御するためには、通信の中身を確認して防御対象であるか判断する必要があります。WAFが攻撃を防御するために必要とするのが、「SSLサーバ証明書」と「公開鍵」、「秘密鍵」になります。公開鍵はSSLサーバ証明書に含まれており、秘密鍵はWebサイトの管理者が作成し、公開鍵で暗号化されたものを復号する鍵となります。外部には公開せず、厳重に管理されている鍵になります。
暗号されたhttps通信の復号は以下の流れで行われます。
- 利用者(ブラウザ)がWebサイトに対してリクエストを依頼
- WebサイトがSSLサーバ証明書（公開鍵含む）を利用者に送付
- 利用者側で、Webサイトと暗号化（https）通信を行うための鍵（共通鍵）を作成
- 作成した「共通鍵」を、Webサーバから受領した「公開鍵」で暗号化
- 「公開鍵」で暗号化した「共通鍵」をWebサイトへ送付
※暗号化されているので第三者に「共通鍵」の内容は漏れない - Webサイトは受領した、暗号化された「共通鍵」を「秘密鍵」で復号
- https通信を行うための共通鍵が、両者で確認できたので、以降の通信は公開鍵で暗号化しやり取りを行う（https通信が可能となる）
上記はWebサイトとのやり取りとなりますが、間に入るWAFがhttps通信を復号する際も同じ流れになります。そのため、WAFの設定内にも証明書のインストール、秘密鍵を登録するための仕組みが用意されております。仕組みが存在しないWAFもありますが、WAFの前にhttps通信を復号する仕組みを用意しておくことで攻撃の判断ができるようになります。
ステータスコード403はWAFが防御した証！
WAFによって防御された攻撃はどのような対処をされるのでしょうか。結論から申し上げると対象サイトへの「アクセスを禁止」という形で防御されます。その際に表示されるのが、「ステータスコード403」になります。ステータスコードとは、利用者が対象のWebサーバを利用するリクエストを出し、そのリクエストに対しWebサーバが処理した結果を３桁の数字で表したものになります。
ステータスコードを大枠で分けると以下の内容になります。
- ステータスコード200番台：正常
- ステータスコード300番台：リダイレクト処理
- ステータスコード400番台：クライアント（利用者）に関わるエラー
- ステータスコード500番台：サーバに関わるエラー
WAFで防御された場合、利用者からのリクエストに関わるので、ステータスコード400番台エラーに当てはまり、その中の403「Forbidden」として処理されます。
序章でも申し上げましたが、セキュリティに関するニュースは絶えず起こっております。これはWebサイトへの攻撃手法や、攻撃対象となるシステム構成も複雑化しているため、WAFの防御設定についても都度更新が必要となってきます。その際、WAFにて正しく攻撃対象のリクエストのみ防御できていれば問題はありません。
しかしWAFの設定に不備があり、普通の利用者に対するリクエストも防御してしまう事例もあります。悪意のない利用者に対する、不用意なブロックは、Webサイトの信頼性の低下にもつながってしまいます。WAFの設定変更については最新の注意を払うようにしましょう。
まとめ
「WAFはなぜ暗号化されたhttps通信の攻撃を防御できるのか？」と題してご説明してまいりました。本記事がhttps通信の暗号化および復号、また暗号化された通信に対してWAFの防御する仕組みが担保されることへの理解に少しでもつながれば幸いです。
インターネットの世界で攻撃をする悪者がいなくなるのが、一番いいのですが、現実的には難しい状況です。本記事を通じて、Webサイトを悪意のある攻撃者から守るため、少しでもWAFの存在の重要性を感じてもらえれば嬉しく思います。 当サイトでは、サイバー攻撃を防ぐためのWAFに興味がある方へ、参考になるダウンロード資料をご用意しております。「サイバー攻撃可視化ツールPrimeWAF 基本ガイドブック」は、WAF選定時に抑えるべき機能やポイントがわかる資料になっています。ぜひ資料をダウンロードください。
