カテゴリー: Programming

  • 無視されているリスク分析

    炎上プロジェクトの主な原因の1つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。

    これと同じことが情報セキュリティ対策でも起きています。

    致命的な脆弱性が残っているシステムの主たる原因の1つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。

    漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。

    • ◯◯対策として△△を実施する

    といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。

    システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。

    特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。

    続きを読む
  • Railsのリモートコード実行脆弱性、今昔

    去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。

    ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。

    (さらに…)
  • PHP用のCookieセッションセーブハンドラー

    JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは

    • サーバー側のリソース(DBやファイルなど)を使わないので簡単にスケールする

    ことにあります。

    しかし、Cookieの保存は大きく分けて3つの問題があります。

    1. ネットワークが不安定だとデータが失われる場合がある(ネットワーク接続の問題)
    2. ロックがないのでデータが失われる場合がある(サーバー側の問題)
    3. 更新のタイミングによりデータが失われる場合がある(クライアント側の問題)

    ※ この問題はこのCookieを利用したセーブハンドラの問題ではなく、クッキー等のクライアント側にセッションデータを持たせるセッション管理の仕組み全般に存在します。

    このハンドラーはデータ改ざんを検出するようになっており、Cookieの問題により改ざん攻撃と誤検出する可能性があります。

    1、2は一般に広く認知されている問題でしょう。この場合はほぼ攻撃と誤検出されないと思われます。攻撃ではないのに攻撃と誤検出するのはほぼ3のケースだと考えられます。壊れ方によっては3ケースでも攻撃とは検出せず、仕様として単純にクッキーをリセットする場合もあります。タイミングによるデータ損失が100%攻撃と誤検出されるのではありません。

    調べたのはしばらく前になりますが、タイミングによって失われるケースも完全に無視してよい程度ではありませんでした。これはブラウザのクッキー保存の実装コードの問題と考えられます。初期のバージョンはこの問題に対する緩和対策をしたコードにしていました。今は対タンパー性を上げる為にほぼ完全にバリデーションするコードになっています。(詳しくはコメント欄を参照)

    どちらも一長一短で何とも言えないです。更新タイミングによるデータ損失が、どのブラウザで起きるのか、どのような使い方をすると起きるのか、どの程度あるのか、分らないので攻撃と誤検出するケースがある場合には教えていただけると助かります。※

    ※ 現コードはHMACで使用するクッキーをバリデーションしているので、更新タイミングによるデータ損失があると攻撃と誤検出します。きっちり正しく動作するコード ≠ きっちり厳格にバリデーションするコード、となる数少ないタイプのコードになります。ブラウザがRDBMSのトランザクションのように保存すれば済む話ですが。

    (さらに…)
  • ITセキュリティ対策の構造化

    ITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか?

    システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。

    何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セキュリティ対策」に終始しています。

    (さらに…)

  • 入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0

    基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。

    https://blog.ohgaki.net/there-are-3-types-of-validations

    Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義すれば、アプリケーション内で繰り返し同じ入力仕様をバリデーションできるように作られています。

    Validate for PHPのスクリプト版をPre Alphaとしてリリースします。このブログのGitHubリポジトリのリンクは0.7.0ブランチに向いています。開発版はmasterブランチを参照してください。

    (さらに…)
  • それは”ただのバグ”なのか?それとも?

    ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK!でしょうか?

    ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。

    (さらに…)
  • なぜWebセキュリティはここまでダメなのか?

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

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

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

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

    (さらに…)
  • データフロー分析とセキュリティ

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

    コールフローグラフ

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

    (さらに…)
  • OWASP TOP 10のセキュリティ対策

    できれば全体をよく読む方が良いのですが、まとめとして対策を一覧できるようブログにしました。引用は2017年版 OWASP TOP 10からです。

    (さらに…)
  • ゼロトラストとフェイルファースト

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

    私なら

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

    を挙げます。

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

    もう一つ追加するなら

    • 多層防御(縦深防御)

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

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

    (さらに…)
  • PHPのPharを使ったコード実行

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

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

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

    (さらに…)
  • OWASP Secure Coding Practices – Quick Reference Guideの訳語

    OWASP Secure Coding Practices  – Quick Reference Guideの訳語が不適切ではないのか?とメールを頂きました。

    ブログにして見ていただく方が良いと思ったので公開します。

    (さらに…)
  • セキュアコーディングの構造/原理/原則

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

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

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

    (さらに…)
  • セキュアコーディングは言語を問わず適用できる

    セキュアコーディングの基本概念は、言語のタイプを問わず、全てのプログラミング言語と互換性があります。

    (さらに…)
  • アプリとライブラリの「役割と責任」の違い – セキュリティの基礎

    アプリケーションとライブラリでは作り方/設計が大きく異なります。この違いを理解していないとセキュアなアプリケーションの構築が困難、というより不可能になります。

    (さらに…)