【第2回】セキュリティワーキンググループの取り組みと、開発で気をつけたいセキュリティの話（後編）

こんにちは。
システムズのセキュリティワーキンググループ（以下、セキュリティWG）です。
最近、「○○社で情報漏えい」「Webサービスが不正アクセスで停止」といったニュースを見かけることが増えました。
とはいえ、いざ「セキュリティを意識して開発しましょう」と言われても、

  • どこから手を付ければいいのか分からない
  • 何をすると危ないのかイメージしづらい

と感じる方も多いと思います。
このコラムでは、

  • そもそもシステムのセキュリティは、何が怖いのか
  • 開発時に特に気をつけたい代表的な脆弱性はどんなものか
  • セキュリティWGがどんな取り組みをしているのか

を、あまり専門用語に寄りすぎない形でご紹介します。
後編となる今回は、

  • クロスサイトスクリプティング（XSS）
  • セキュリティWGの活動内容
  • 日々の開発で意識したいポイント

についてご紹介します。

クロスサイトスクリプティング（XSS）

ユーザーの書き込み中のスクリプトが、他の人のブラウザで動いてしまう問題

クロスサイトスクリプティング（XSS）は、ユーザーが入力したスクリプトが、
そのページを見た別のユーザーのブラウザで実行されてしまう脆弱性です。

イメージしやすい例として、「掲示板」や「コメント欄」を考えてみます。

  • ユーザーの書き込み内容を、そのままHTMLとして画面に表示する
  • 書き込みの中に <script>…</script> のようなスクリプトが含まれている
  • そのページを見た別のユーザーのブラウザが、そのスクリプトを実行してしまう

こうなると、たとえば次のようなことができてしまいます。

  • クッキーの情報を盗み取る
  • 本物そっくりのログイン画面を表示し、ID・パスワードを入力させる

どう防ぐか（ポイント）

ユーザーの入力をHTMLに埋め込むときは、

  • < や >、” などの記号を
  • &lt; や &gt;、&quot; などの文字列に置き換える

ことで、「ただの文字」として表示されるようにします。

多くのフレームワークやテンプレートエンジンには、HTMLエスケープ機能が標準で備わっています。
まずはそれを“デフォルト”として使うのがおすすめです。

明らかにおかしい入力は、そもそも受け付けない

  • 不自然に長い入力
  • タグやスクリプトを含む必要がない場所で、それらを含む入力

などは、サーバ側で弾きます。

「この項目には何文字まで」「どの文字種まで許可するか」をあらかじめ決めておくと安心です。
前提として、ブラウザは受け取ったHTML／JavaScriptを素直に実行しようとする性質があります。

そのため、
「ユーザーからの入力は、そのまま画面に返さない」
「どこかで必ずフィルタをかける」
という意識が重要です。

セキュリティWGについて

最後に、システムズのセキュリティWGがどのような活動をしているかをご紹介します。

立ち上げのきっかけと、目指していること

セキュリティWGは、

  • 開発プロジェクト全体のセキュリティレベルを底上げしたい
  • セキュリティに関する知見を、社内で継続的・横断的に共有していきたい

という思いから立ち上がりました。
将来的には、次のような姿を目指しています。

  • 社内外へのセキュリティ支援・サービスとしての展開
  • セキュリティ人財の育成
  • セキュリティチームとしての組成

ツールを使った“仕組みづくり”

セキュリティ対策を、人の注意力だけに頼るのではなく、
ツールも活用して「仕組み」として組み込んでいくことも、WGの重要なテーマです。

現在、次のようなツールを検証・導入しています。

Snyk（静的解析ツール）
ソースコードや利用しているライブラリに、既知の脆弱性が含まれていないかをチェックするツールです。
開発中の段階で「ここは危ないかもしれない」というポイントを自動的に検出してくれます。

OWASP ZAP（動的解析ツール）
実際に動いているWebアプリケーションに対してテスト用のリクエストを送り、
SQLインジェクションやXSSなどの脆弱性がないかを確認するツールです。

これらのツールについて、

  • プロジェクトのどのタイミングで使うのがよいか
  • どのくらいの頻度で回すのが現実的か

といった点を、WG内で試行しながら運用方法を整えているところです。

勉強会・情報共有・相談窓口として

ツールの導入以外にも、セキュリティWGでは次のような活動を行っています。

  • 代表的な脆弱性（今回ご紹介した内容など）をテーマとしたミニ勉強会
  • 最近のセキュリティ事故の事例紹介と、そこから得られる教訓の共有
  • プロジェクトからの相談を受ける窓口としての役割

私たちが大事にしているのは、
「常に完璧な答えを用意すること」よりも、「一人で悩まず、気軽に相談できる場になること」 です。

おわりに

「セキュリティ」と聞くと、

  • 難しそう
  • 専門的で、自分には関係ないかもしれない

と感じる方も多いかもしれません。
しかし、今回ご紹介したように、

  • ユーザー入力をそのまま信じて処理しない
  • 危険になりやすい処理（SQL実行、OSコマンド実行、スクリプトの出力）には、一段階フィルタや専用APIを挟む
  • 自分だけで抱え込まず、フレームワークやツール、そして周囲の人に頼る

といった基本を押さえるだけでも、システムの安全性は大きく向上します。
セキュリティWGとしても、「一緒にセキュリティを考えていける仲間」を増やしていきたいと考えています。

日々の開発の中で少しでも、

  • 「このSQLの書き方、大丈夫かな？」
  • 「この入力値、そのまま画面に出してしまっていないかな？」

と疑問や不安を感じた際には、立ち止まって確認することが重要です。
本コラムが、そのようにセキュリティを意識して見直す一助となれば幸いです。

関連記事

コラム

【第1回】セキュリティワーキンググループの取り組みと、開発で気をつけたいセキュリティの話（前編）

2026.04.22