世の中のソフトウェアには危険なコードが埋もれています。これがセキュリティ問題の原因になっています。なぜ危険なアプリケーションが書かれるのか？その仕組みを理解すると、対策が可能です。
(さらに…)-
リスク分析とリスク対応をしよう
情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。
情報システムは「モノ」（物と人）、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。
当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない！といった場合も多いので仕方ない側面もあります。
しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。
※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。
(さらに…) -
究極のセキュリティ要求事項とは？
前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。
- Confidentiality – 機密性
- Integrity – 完全性
- Availability – 可用性
- Reliability – 信頼性
- Authenticity – 真正性
- Non-repudiation – 否認防止 (Accountability – 責任追跡性）
これらが基礎的な情報セキュリティの要求事項になります。以上です。
※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335（古い情報セキュリティ標準）で定義していた要素に戻った形になりました。
これで終わってしまうと何の事なのか？究極の要求事項とは何なのか？となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。
(さらに…) -
無視されているリスク分析
炎上プロジェクトの主な原因の１つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。
これと同じことが情報セキュリティ対策でも起きています。
致命的な脆弱性が残っているシステムの主たる原因の１つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。
漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。
- ◯◯対策として△△を実施する
といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。
システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。
特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。
続きを読む -
Railsのリモートコード実行脆弱性、今昔
去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。
ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。
(さらに…) -
PHP用のCookieセッションセーブハンドラー
JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは
- サーバー側のリソース（DBやファイルなど）を使わないので簡単にスケールする
ことにあります。
しかし、Cookieの保存は大きく分けて3つの問題があります。
- ネットワークが不安定だとデータが失われる場合がある（ネットワーク接続の問題）
- ロックがないのでデータが失われる場合がある（サーバー側の問題）
- 更新のタイミングによりデータが失われる場合がある（クライアント側の問題）
※ この問題はこのCookieを利用したセーブハンドラの問題ではなく、クッキー等のクライアント側にセッションデータを持たせるセッション管理の仕組み全般に存在します。
このハンドラーはデータ改ざんを検出するようになっており、Cookieの問題により改ざん攻撃と誤検出する可能性があります。
1、2は一般に広く認知されている問題でしょう。この場合はほぼ攻撃と誤検出されないと思われます。攻撃ではないのに攻撃と誤検出するのはほぼ3のケースだと考えられます。壊れ方によっては3ケースでも攻撃とは検出せず、仕様として単純にクッキーをリセットする場合もあります。タイミングによるデータ損失が100%攻撃と誤検出されるのではありません。
調べたのはしばらく前になりますが、タイミングによって失われるケースも完全に無視してよい程度ではありませんでした。これはブラウザのクッキー保存の実装コードの問題と考えられます。初期のバージョンはこの問題に対する緩和対策をしたコードにしていました。今は対タンパー性を上げる為にほぼ完全にバリデーションするコードになっています。（詳しくはコメント欄を参照）
どちらも一長一短で何とも言えないです。更新タイミングによるデータ損失が、どのブラウザで起きるのか、どのような使い方をすると起きるのか、どの程度あるのか、分らないので攻撃と誤検出するケースがある場合には教えていただけると助かります。※
※ 現コードはHMACで使用するクッキーをバリデーションしているので、更新タイミングによるデータ損失があると攻撃と誤検出します。きっちり正しく動作するコード ≠ きっちり厳格にバリデーションするコード、となる数少ないタイプのコードになります。ブラウザがRDBMSのトランザクションのように保存すれば済む話ですが。
(さらに…) -
データ検証をしない仕様には「脆弱性名」を付けた方が良いのでは？ – 未検証入力
危険な脆弱性であっても名前を付けないとなかなか認知してもらえない、といったことがよくあります。「データ検証をしないアプリ仕様」は危険で脆弱な仕様ですが、基本的な対策を実装しない危険性はあまり認知されてないと思います。例えば、とんでもないGDPR制裁金を支払うといったリスクが高くなります。
名前が必要なのかも知れません。
実は新しく考えなくても既にOWASPが名前を付けています。
- Unvalidated Input （未検証入力）
OWASP TOP 10 A1:2004 Unvalidated Inputとして第一番目の脆弱性として挙げています。
2007年版から消えていますが、これはセキュアコーディングとの兼ね合いで省略したのだと思われます。「2007年版から消えているので脆弱性ではなくなったのだ」とする自分勝手な解釈の解説を目にしたことがありますが、その2007年版には「リストから消したが変わらず重要な対策で、本年度版の脆弱性対策の手法としても記載」とする解説が書かれています。
標準的なセキュリティ対策の概念では「入力データ検証は非常に重要な脆弱性対策」です。
(さらに…) -
ITセキュリティ対策の構造化
ITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか？
システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。
何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セキュリティ対策」に終始しています。
-
入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0
基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。
Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義すれば、アプリケーション内で繰り返し同じ入力仕様をバリデーションできるように作られています。
Validate for PHPのスクリプト版をPre Alphaとしてリリースします。このブログのGitHubリポジトリのリンクは0.7.0ブランチに向いています。開発版はmasterブランチを参照してください。
(さらに…) -
それは”ただのバグ”なのか？それとも？
ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK！でしょうか？
ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。
(さらに…) -
なぜWebセキュリティはここまでダメなのか？
インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。
この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。（もしくは気付いていても公開していない）
侵入されたことを検知／対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか？を考えます。
※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。
(さらに…) -
OWASP TOP 10のセキュリティ対策
できれば全体をよく読む方が良いのですが、まとめとして対策を一覧できるようブログにしました。引用は2017年版 OWASP TOP 10からです。
(さらに…)
