セキレイ｜ITの基礎知識

Webセキュリティ入門

泥棒が入れるからといって、ドアも窓も釘付けにはできません。Webサイトを安全に動かし続けるために、攻撃の仕組みと守り方を整理します。

一般向け解説資料｜スマートフォン・PCでの閲覧、A4印刷に対応

1. Webサイトはどう動く？

Webサイトは、利用者のブラウザと、ページやデータを提供するサーバーが通信することで動いています。ページを見るだけのサイトもあれば、ログイン、検索、予約、投稿などを受け付けるサイトもあります。

基本的な流れ

利用者がブラウザでページを開く。
サーバーがHTMLや画像などを返す。
ブラウザがHTML・CSS・JavaScriptを使って画面を表示する。
必要に応じて、サーバー側のプログラムがデータベースを読み書きする。

たとえば、HTMLはページの骨組み、CSSは見た目、JavaScriptはブラウザ上の動きに関わります。PHPなどのサーバー側プログラムは、ログイン処理やデータの取得などを担当できます。

大切な点：Webサイトは一枚のページだけでできているとは限りません。ブラウザ、Webサーバー、プログラム、データベース、ネットワークなど、複数の部品が連携しています。

2. よくある攻撃と被害

攻撃・問題	身近なたとえ	起こりうること
脆弱性の悪用	壊れた鍵や欠陥のある扉を利用される	不正アクセス、情報漏えい、サーバー上での不正な処理など。脆弱性の内容によって被害は異なります。
SQLインジェクション	申込用紙の記入欄に、係員への不正な命令まで書かれる	データベースの情報を見られたり、書き換えられたりする可能性があります。
クロスサイトスクリプティング（XSS）	掲示板に、閲覧者のブラウザで動く悪意ある内容を紛れ込ませる	偽の画面表示や、条件によっては利用者情報の窃取などにつながります。
リモートコード実行（RCE）	外から建物の機械を勝手に操作される	脆弱性を通じて、攻撃者がサーバー上で意図しないプログラムを実行できる場合があります。
フィッシング	本物そっくりの窓口で暗証番号を聞き出す	偽サイトなどに誘導され、利用者自身がパスワードなどを入力してしまいます。

攻撃の名前が同じでも、実際の影響はシステムの構成や設定、権限、保存されているデータによって変わります。「脆弱性がある」ことと「必ず乗っ取られる」ことは同じではありませんが、悪用される可能性を放置してよいわけでもありません。

3. PHP・JavaScript・CSSの違い

言語や技術そのものを「危険」「安全」と単純に分けることはできません。どこで動くのか、どのように使われているか、欠陥があるかどうかが重要です。

技術	主な役割・実行場所	注意点
PHP	一般にはサーバー側で動き、ページ生成やデータ処理を行う	脆弱性や設定不備が悪用されると、サーバーや接続先データへの被害につながることがあります。
JavaScript	主にブラウザで動き、画面の操作や更新を行う。サーバー側で動く環境もある	悪用されると、ページを見ている利用者に影響する場合があります。サーバー側で使う場合はサーバー側のリスクもあります。
CSS	ページの色、配置、文字の大きさなど見た目を指定する	通常は見た目を整えるためのものです。ただし、入力内容の扱いやページ構成などの条件によっては、情報推測などの攻撃に悪用されることがあります。
HTML	ページの構造や内容を表す	利用者の入力を安全に扱わないと、悪意ある内容がページの一部として解釈されることがあります。

誤解しないために：PHPだから危険、JavaScriptだから利用者だけが危険、CSSなら必ず安全、ということではありません。攻撃の成立条件と、プログラムに与えられた権限を確認する必要があります。

4. 守るための基本対策

① ソフトウェアを更新する

OS、Webサーバー、PHPなどの実行環境、CMSやプラグインを、提供元のセキュリティ情報に従って更新します。更新は既知の欠陥を修正するための重要な対策です。バージョン番号だけで判断せず、利用しているOSの配布元が修正を提供しているかも確認します。

② 入力と出力を適切に扱う

利用者から受け取った文字を、そのままプログラム命令として扱わないことが基本です。ただし、対策は一律ではありません。

SQLの処理には、原則としてプリペアドステートメントを使う。
HTMLに文字を表示するときは、表示する場所に応じたエスケープを行う。
入力値は、想定する形式・長さ・範囲に合っているか検証する。

入力の検証、出力時のエスケープ、SQLの安全な処理は、互いに補い合う対策です。「サニタイズを一度すればすべて安全」とは考えません。

③ 権限を必要最小限にする

Webサイトのプログラムやデータベースの接続アカウントには、仕事に必要な権限だけを与えます。Webプログラムが侵害されても、サーバー全体やデータベース全体を自由に操作できないよう、被害の範囲を小さくします。

④ 通信や接続先を制限する

ファイアウォールで必要な通信だけを許可し、管理用のSSHやデータベースを不用意にインターネットへ公開しないようにします。HTTPSは通信を暗号化しますが、サーバー内の脆弱性を修正するものではありません。

⑤ ログとバックアップを用意する

ログは異常の発見や原因調査に役立ちます。バックアップは、故障や侵害の後に復旧するための備えです。バックアップが存在するだけで安心せず、実際に復元できるか確認します。

⑥ WAFなどの防御機能を補助的に使う

WAF（Web Application Firewall）は、Web通信を検査し、設定されたルールや検知条件に基づいて不審な通信を遮断する仕組みです。役立つ場面はありますが、すべての攻撃を見抜けるわけではなく、脆弱性の根本修正の代わりにはなりません。

5. 重大な脆弱性が見つかったら

重大な脆弱性が公表されたときは、慌てて何でも止めるのではなく、情報を確認して、リスクに応じた対応を選びます。

対象かどうか調べる：利用している製品・バージョン・設定が影響を受けるか確認する。
提供元の情報を確認する：修正版、回避策、影響する条件を確認する。
更新や回避策を適用する：バックアップや動作確認など、運用上必要な準備を行う。
修正までの危険を評価する：公開範囲の制限、機能の一時停止、サービス全体の一時停止などを検討する。
対応後に確認する：修正が適用されたこと、サービスが正常に動作すること、異常なアクセスがないかを確認する。

サービス停止は選択肢のひとつ：修正が間に合わず、危険を許容できない場合には一時停止が適切なことがあります。一方で、停止すると利用者や業務に影響します。安全性とサービス継続の両方を考え、根拠を持って判断します。

家に例えるなら、鍵の不具合を直すことが根本対策です。監視や補助錠も役立ちます。それでも修理が終わるまで危険が高いなら、一時的に建物を閉めることも考えます。いつまでもドアや窓を釘付けにするのが目的ではありません。

6. 公開サイトの点検項目

公開サイトを管理する人は、次の項目を定期的に確認しましょう。

□ OS・Webサーバー・実行環境・CMSなどの更新状況を把握している。
□ 公開する必要のないポートやサービスを閉じている。
□ SSHなどの管理用接続を適切に制限している。
□ データベースを原則として外部へ直接公開せず、接続権限を絞っている。
□ Webプログラムが不要なファイルを読んだり書き換えたりできないようにしている。
□ HTTPSを適切に設定している。
□ ログを確認でき、異常時の連絡・対応手順がある。
□ バックアップを取り、復元テストを行っている。
□ 重大な脆弱性が公表されたとき、誰が判断し、誰が対応するか決まっている。

このチェックリストは出発点です。必要な対策は、サイトの用途、公開範囲、扱う情報、システム構成によって異なります。

7. 用語ミニ辞典

用語	簡単な説明
脆弱性	プログラムや設定などにある、攻撃や事故につながりうる弱点。
パッチ	ソフトウェアの欠陥などを修正するための更新。
RCE	Remote Code Execution。遠隔からサーバーなどで不正なコードを実行される問題。
SQLインジェクション	入力などを通じて、不正なSQL命令を実行させる攻撃。
XSS	Webページに悪意あるスクリプトを紛れ込ませ、閲覧者のブラウザで動かす攻撃。
Cookie	ブラウザに保存される小さなデータ。ログイン状態の管理などに使われる。
ファイアウォール	ネットワーク通信をルールに従って許可・遮断する仕組み。
WAF	Webアプリケーションへの通信を検査し、不審な通信を遮断する仕組み。
最小権限	利用者やプログラムに、必要な範囲だけの権限を与える考え方。
バックアップ	故障や誤操作、攻撃などに備えてデータを別に保存しておくこと。