カテゴリー: Security

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

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

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

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

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

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

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

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

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

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

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

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

    (さらに…)
  • データ検証をしない仕様には「脆弱性名」を付けた方が良いのでは? – 未検証入力

    危険な脆弱性であっても名前を付けないとなかなか認知してもらえない、といったことがよくあります。「データ検証をしないアプリ仕様」は危険で脆弱な仕様ですが、基本的な対策を実装しない危険性はあまり認知されてないと思います。例えば、とんでもないGDPR制裁金を支払うといったリスクが高くなります。

    名前が必要なのかも知れません。

    実は新しく考えなくても既にOWASPが名前を付けています。

    • Unvalidated Input (未検証入力)

    OWASP TOP 10 A1:2004 Unvalidated Inputとして第一番目の脆弱性として挙げています。

    2007年版から消えていますが、これはセキュアコーディングとの兼ね合いで省略したのだと思われます。「2007年版から消えているので脆弱性ではなくなったのだ」とする自分勝手な解釈の解説を目にしたことがありますが、その2007年版には「リストから消したが変わらず重要な対策で、本年度版の脆弱性対策の手法としても記載」とする解説が書かれています。

    https://blog.ohgaki.net/owasp-and-input-validation

    標準的なセキュリティ対策の概念では「入力データ検証は非常に重要な脆弱性対策」です。

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

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

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

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

    (さらに…)

  • PHP 5.6.38他で修正された任意コンテンツ送信脆弱性について

    PHP 5.6.38/7.0.32/7.1.22/7.2.10でApache2handler SAPIのセキュリティバグが修正されました。

    13 Sep 2018
    Apache2:

    Fixed bug #76582 (XSS due to the header Transfer-Encoding: chunked).

    http://php.net/ChangeLog-5.php#5.6.38

    攻撃者が送った出鱈目な攻撃用データがPHPプログラムに関係なくブラウザに出力されてしまう問題が修正されました。

    この脆弱性の影響が正しく伝わっていないようなので、簡単に紹介します。

    (さらに…)
  • なぜ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への攻撃方法が記載されています。

    (さらに…)
  • プライバシーの8原則

    日本はOECD加盟国としてOECDプライバシー8原則を尊重する国です。OECDプライバシー8原則とは1980年にOECD(経済協力開発機構)で、個人情報保護の基本となる原則として定められました。

    1980年頃には企業のオンライン化と顧客情報の集積が進むに伴い、個人のプライバシー情報を無制限に企業が利用することへの懸念が高まっていました。先進国間でプライバシーの概念が異なると困ります。先進国の間で同じ概念に基づくプライバシー保護を実現するためにプライバシー勧告が行われました。

    (さらに…)

  • セキュアコーディングは言語を問わず適用できる

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

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

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

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

    (さらに…)

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

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

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

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

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

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

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

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

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

    (さらに…)