Webサイトへの攻撃が後を絶たない。改ざんや悪質サイトへと誘導するその手口はさらに巧妙化し、従来のIPSなどでは防ぎきれなくなった。サイトを脅威から守るために、今すぐできるセキュリティ対策を紹介する。
2005年春、2007年春に猛威を振るったSQLインジェクション(※注1)の検知数が、2008年の3月上旬から当時の何倍もの規模にまで増えてきた(図1)。正直なところSQLインジェクションは「過去の遺物」であり、ほとんどのサイト運営者が何らかの手を打ち、もう絶滅したと思われていたが、現在も被害に遭うサイトは後を絶たない(図2)。
※注1 第三者がWebアプリケーションなどのセキュリティ上の脆弱性を悪用してデータベースの不正な操作を可能とする攻撃手法
ここではWebアプリケーション(以下、Webアプリ)の脆弱性対策の話が中心であるため、攻撃の詳細にまでは触れないが、一連の攻撃で厄介だったのは、攻撃コードが難読化されていたことである(図3)。攻撃コードの難読化により、既存のベンダー製シグネチャが適用されたIDS/IPS(不正侵入検知/防御システム)などでは検知できないため、自組織では攻撃があったことに気付かなかった。利用者や第三者からの指摘があるまで放置されていたのである。
その結果、Webページに利用されているデータベースの値(HTMLの一部になる値)が改ざんされ、ページを改ざんされたのと同じ状態となった。そのサイトにアクセスしたユーザーは知らないうちに悪質なプログラムをダウンロード・実行し、Webブラウザや音楽プレーヤーなどのプログラムの脆弱性を突いて攻撃者に情報を送信したり、ウイルスに感染したりしてしまう。さらに各サイトの攻撃コード(スクリプト)も難読化されていたため対応が遅れ、被害規模が大きくなってしまったのだ。
皆さんのサイトは本当に大丈夫だろうか? もし不安なら、以下に挙げるようなIPA(情報処理推進機構)やわれわれのようなセキュリティベンダーが提供する無償ログチェッカーで、攻撃の有無を調べてみることをお勧めする。仮に攻撃があったと判定されたとしても、誤検知の場合もあるので慌てず内容を確認し、攻撃が本物か誤検知かを判断する。攻撃が本物ならその攻撃が成功していそうか否か、また攻撃されているWebアプリの脆弱性(設計/プログラミング上の欠陥)の有無などを調べてみるとよい(自組織で調べられない場合は後述を参照)。そのほか、とにかく不安なら最初から身近なセキュリティベンダーに相談するのもよいだろう。
まず、セキュリティ対策を発注する側が注意する点を考える。Webアプリのセキュリティ対策に限らず、セキュリティ対策を考える際に重要なことは、発注者側が満たすべき要件をシステムインテグレーター側に要求することである。「インテグレーターの技術者は言われなくてもきちんと対策をやってほしい」と彼らの良心に期待するのは自由だが、セキュリティ対策はほとんどの場合、要求しなければ実装されない。なぜなら、アプリケーションの機能を追加したときと同様、セキュリティ対策にはお金が掛かるからである。
では、どのように要求すべきか? まずは自社のセキュリティポリシーやシステム開発標準などを確認し、その上で日本ネットワークセキュリティ協会(JNSA)の「Webシステム セキュリティ要求仕様(RFP)」編 β版やPCI DSS(クレジットカード業界のセキュリティ基準)などを参考に提案依頼書(RFP)を作成してみてはいかがだろうか。
次に対策を行う側、つまり開発者側にとってWebアプリのセキュリティ対策の中心は、セキュアなアプリケーションを開発することである。しかし、そのアプリケーションが稼働するサーバが欠陥だらけでは、下位レイヤーのOSやミドルウェアから攻められてしまう。従って、従来言われている「サーバの要塞化(ハードニング)」「セキュリティパッチ適用の徹底」などの基本的な対策を怠ってはいけない。どの分野においても基本は大事である。
Copyright © ITmedia, Inc. All Rights Reserved.
「TikTok禁止」は結局、誰得? どうするトランプ氏――2025年のSNS大予測(TikTok編)
米国での存続を巡る議論が続く一方で、アプリ内ショッピングやAI機能の拡大など、TikTok...
ネットの口コミを参考に8割超が商品を購入 最も参考にした口コミの掲載先は?
ホットリンクは、口コミ投稿の経験や購買への影響を調査した結果を発表した。
「生成AIの普及でSEOはオワコン」説は本当か?
生成AIの普及によりSEOが「オワコン」化するという言説を頻繁に耳にするようになりました...