なぜWebセキュリティはここまでダメなのか?

インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。

この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。(もしくは気付いていても公開していない)

侵入されたことを検知/対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか?を考えます。

※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。

“なぜWebセキュリティはここまでダメなのか?” の続きを読む

データフロー分析とセキュリティ

データフロー分析とはコールフローグラフ(CFG)を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的(=プログラムを動作させず)にプログラム実行時のデータフローを分析し、問題を発見する手法です。

コールフローグラフ

データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料(PDF)が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。

“データフロー分析とセキュリティ” の続きを読む

ゼロトラストとフェイルファースト

今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念/原則を挙げるでしょうか?

私なら

  • ゼロトラスト
  • フェイルファースト

を挙げます。

極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。

もう一つ追加するなら

  • 多層防御(縦深防御)

を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。

これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念/原則と言えるかも知れません。

“ゼロトラストとフェイルファースト” の続きを読む

PHPのPharを使ったコード実行

phar(PHPプログラムを1つのアーカイブファイルにまとめて利用するファイル形式)のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。

pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。

BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。

“PHPのPharを使ったコード実行” の続きを読む

セキュアコーディングの構造/原理/原則

セキュアコーディング/セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。

基本原理/基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。

IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。

“セキュアコーディングの構造/原理/原則” の続きを読む

攻撃可能面の管理 – セキュリティの基本

Attack Surface (攻撃可能面=攻撃可能な箇所)の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。

攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析(=リスク分析)します。その上でできる限り攻撃可能な箇所を削減(=リスク削減)します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。

Attack Surface (攻撃可能面)

The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment.[1][2] Keeping the attack surface as small as possible is a basic security measure.

出典:Wikipedia

日本語訳すると以下のようになります。

ソフトウェア環境における攻撃可能面は不正なユーザー(攻撃者)がデータを攻撃対象に入力または取り出し可能な様々箇所(アタックベクター)の集合である。攻撃可能面を可能な限り小さくするのは基本的なセキュリティ対策である

“攻撃可能面の管理 – セキュリティの基本” の続きを読む

セキュリティに拘ってもセキュアにならない – 開発環境セキュリティ

いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。

細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。

“セキュリティに拘ってもセキュアにならない – 開発環境セキュリティ” の続きを読む

データのコンテクスト – セキュリティの基礎

コンテクストを知る、はデータを安全に扱う為に必須の基礎知識です。

よくある致命的な脆弱性を作る考え方は

  • コンテクストなんてどうでもよい。このAPIを使えば良い。

です。セキュリティ対策ではコンテクストが何であるのか?を正しく理解することが重要です。ここではコンテクストについて紹介します。

“データのコンテクスト – セキュリティの基礎” の続きを読む

プログラミングを覚えたら先ず知るべきコーディングプラクティス

プログラミングを覚えたら先ず知るべきコーディングガイドラインを紹介します。このブログではこれらのガイドラインを時々紹介していましたが、まとめて紹介するのは初めてだと思います。これから紹介するガイドラインはセキュアプログラミング/防御的プログラミング/セキュアコーディングと呼ばれる考え方に基づいたガイドラインです。

ここで紹介する考え方や基本はコンピューターサイエンティストらによって原理/論理から導き出された概念/考え方です。

論理的に出鱈目なセキュリティの考え方が当たり前かのように啓蒙され、脆弱なアプリケーションの作成を助長しています。最後にアンチプラクティスの例として紹介します。

“プログラミングを覚えたら先ず知るべきコーディングプラクティス” の続きを読む

「フェイルセーフ」とは何なのか?

「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉&簡単な概念ですが、割と広く誤解されている概念の1つに見えます。

フェイルセーフを一言で言うと

何かに失敗しても致命的な問題に至らないよう安全に失敗させる

これがフェイルセーフです。可能ならば「失敗/故障しても、失敗/故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。

Wikipediaの定義では

フェイルセーフ(フェールセーフ、フェイルセイフ、英語fail safe)とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。

となっています。

こんな単純な概念は間違いようがないでしょ?

と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。

“「フェイルセーフ」とは何なのか?” の続きを読む

NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ

NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。

ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。

  • Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
  • セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
  • 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。

要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、

▽セキュリティー対策ソフトを入れる。

などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。

NHKが紹介した対策ページではスクリーンショット等も交えながら

▽アプリは公式アプリストアからのみダウンロードする。

としているのに、「提供元不明のアプリ」(Android 8ではアプリごとの「不明なアプリ」)のチェックボックスをオフにする、を説明しないのは何事だ!という事です。

確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。

このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」(公開していません)の導入部分に追加したスライドを紹介します。

“NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ” の続きを読む

何故こうなった?プログラムの動作原理を無視したセキュリティ対策

正しく動作するプログラムには

  • 正しい/妥当なデータ
  • 正しいコード

の両方が必要です。

仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。

当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう?

参考: プログラム動作の構造、原理と原則

セキュアコーディングの構造/原理/原則

“何故こうなった?プログラムの動作原理を無視したセキュリティ対策” の続きを読む

PHPのserialize()/unserialize()を安全に利用する方法

serialize()でシリアライズしたデータを外部に送信/保存1し、それをunserialize()すると危険です。

アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わないことになっています。

しかし、外部データでもunserialize()を安全に利用する方法はあります。

“PHPのserialize()/unserialize()を安全に利用する方法” の続きを読む

APIを過信するとおかしな事になる例 – SAML認証成り済まし

今年の2月にSAMLライブラリの脆弱性が報告されていたことを覚えている人も居ると思います。

この脆弱性はXMLコメント(<!– –>)の取り扱いの違いによって、本来のユーザーではない攻撃者を認証してしまう事が問題であったとしています。

攻撃用の文字列サンプルは以下のような物です。

<NameID>user@example.com<!—->.evil.com</NameID>

攻撃が可能になる理由はXMLコメントの取り扱いの違いにあります。

  • あるライブラリは<!– –>までの文字列(user@example.com)までをNameIDとして取り扱う
  • 別のライブラリは<!– –>を取り除いた文字列(user@example.com.evil.com)をNameIDとして取り扱う

これにより攻撃者が別のユーザーに成り済ませてしまう問題が発生しました。1

“APIを過信するとおかしな事になる例 – SAML認証成り済まし” の続きを読む

入力バリデーションが甘いソースコードの検査は本当に大変

入力バリデーションが甘いアプリケーションのソースコードの検査は大変です。何が大変なのか、簡単に紹介します。

ついでに入力バリデーションが甘いアプリケーションの脆弱性診断はかなり簡単でであることも簡単に紹介します。

“入力バリデーションが甘いソースコードの検査は本当に大変” の続きを読む

出力対策の3つの役割 – フェイルセーフ頼みはNG

出力対策だけ行なえばOK!と考えてしまう原因は出力対策に3つの役割があることに気付かないからでは?と思ってこのエントリを書いています。

出力対策は”必須である場合”と”フェイルセーフ対策”である場合があります。

出力対策の基本はこちらです。

出力対策の3原則 + 1原則

“出力対策の3つの役割 – フェイルセーフ頼みはNG” の続きを読む