Webサイトの脆弱性の調査

そんなに脆弱性が多いのだろうか

こんにちは、こたかです。

最近サイトの脆弱性をついた情報漏洩が話題になっています。
そんなに脆弱性は多くあるものなのか気になったので調べてみました。

新手のアタックはあまりなさそう

アタックの多くはURLスキャンで発掘して、基本のセキュリティー対策ができていないサイトが標的になります。
基本的な脆弱性は有名で多くは対策されています。

■ウェブサイトにおける脆弱性解説(https://www.ipa.go.jp)

• SQLインジェクション
• クロスサイト・スクリプティング
• CSRF (クロスサイト・リクエスト・フォージェリ)
• ディレクトリ・トラバーサル
• コマンド・インジェクション
• セッション管理(IDの連番はNG)
• HTTP ヘッダ・インジェクション(動的にヘッダを生成するWebページが対象)
• HTTPS の不適切な利用
• サービス運用妨害 (DoS)
• メール不正中継

新しい手口は画面の書き換え

「サイトを書き換えることができる状態」が前提となった攻撃です。サイトの書き換えができないサイトでは問題を起こせません。

新しい手口は、ログインページを偽装し、攻撃者のサイトへリダイレクト、正しいパスワードを詐取し、本物のエラーページへ戻す、というものです。

もともとの前提「攻撃者からサイトの書き換えができる状態」に無理がありますが、実際に書き換えができる状態になっていたという事のようです。

「Apache　Struts2」の脆弱性ではURLにコマンドを送ることでリモートコードが実行できる状態でした。これが原因です。
「Apache　Struts2」を使っていることが前提なので、「Apache　Struts2」を使っていないと攻撃は成立しません。
今回はこたかのサイトは対象外です。

使っていない機能を把握することが重要

開発者は「使う機能」についてはサイトを構成する際に実装するため、機能について把握しているものです。
しかし、「使わない機能」は設定しないため、把握していない場合がほとんどです。
把握していない機能が有効化されていて、脆弱性があると対策することができません。

こたかは「Apache　Struts2」を使用したことが無いので、脆弱性に気がつきません。
このような場合は、初めにすべての機能を無効化することから始めたりします。

把握しているURLしか使わせない

開発時、フレームワークが止まろうが、サイトが表示されないだろうが、すべてのURLをアクセス禁止にします。
そのあと、表示に必要なURLをアクセスログから逆引きして公開していきます。この時フォルダ１つまるごと公開すると、脆弱性を公開してしまいますので、なるべくフォルダの機能を確認しながら公開の範囲を限定していきます。

管理者用URLにはデバイス認証で保護する

管理者用の機能はアクセスできる利用者を管理者に限定する必要があります。
管理者ログイン画面は特定デバイスのみで表示するように制限が必要です。
この制限をしないサイトが多すぎます。
「管理画面は管理者アカウントでしかログインできないので大丈夫」と考えているサイトは標的です。
デフォルトのURLに「管理者用ログイン画面が見えている」状態が危険だと気づいていないことになります。
なぜなら、そのセキュリティーは「パスワードが１回で当たらないこと」が前提でしょうが、被害を受けたサイトは１回で当てられているからです。
パスワードを固定して、サイトを回すと、パスワードが一致した場合、そのサイトは１回でパスワードが当たるわけです。
対策は単純でIPフィルター・クッキーフィルター・特殊URL、で防止します。

リモート用URLは公開しない

リモート操作用URLを認証無しで公開することは危険です。
リモート操作のURLは「デバイス認証」されたデバイス以外はアクセス禁止にします。

脆弱性は「文字列を受ける機能」でしか起こせません。理由は、書き換える操作には、スクリプトを送る必要があるためです。

スクリプト処理のURLでは文字種、キーワード種、文字数、null、空文字のチェックが漏れなく行われている必要があります。
しかし、文字列はそのままスクリプトへ渡したくなるものです。
チェック機能を別で組むなど、チェックは処理から分離して、漏れが無いようにします。

リモート機能・文字列を受ける機能が無く、公開するURLがすべて把握できている場合は脆弱性はありません。
改変できないためです。

他ソフト障害での脆弱性が残る

他ソフト障害は、コンテンツ側では回避できません。「Apache」本体にある脆弱性はコンテンツ側では防ぐことができません。
パッチが出るまで待ち、対応するしかありません。
フレームワークの脆弱性は脆弱性のある機能を切り離すことで回避できます。

もし改ざんされた場合はすぐにサイトを停止する

クレジット決済が乗っ取られている場合は、被害が拡大してしまうため、すぐにサイトを停止させます。
改ざんされた時期を特定し、アクセス数を確認し、被害見積りを行います。
個人情報保護法では、個人情報漏洩の被害が出てしまった場合には報告が必要です。個人情報漏洩の報告を行います。

改ざんされた場合に自動的にサイトを停止するようにセキュリティー対策を入れておくと良いです。
定期的にチェックが必要ですが被害は最小限になります。

まとめ

Webサイトのセキュリティー対策：

• 基本のセキュリティー対策は行う。基本がわからない場合は調べる
• 新手の手口は昔からある画面の偽装
• 使っている機能以外は確実に停止させる。プラグインやアップデートによる勝手なURL公開はブロックする
• 管理者用URLすべてを漏れなく認証機能で保護する。
• リモートURLは公開しない
• 他ソフト障害による脆弱性対策として、改ざん検知のセキュリティー対策を行い、改ざんされたら速やかに停止させる

ほとんどの被害は「リモート操作」による改ざんです。
リモート用URLが保護されているか確認をおすすめします。

それではまた、次の記事でお会いしましょう。