「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。 フェイルセーフを一言で言うと 何かに失敗しても致命的な問題に至らないよう安全に失敗させる これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受け…

NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。 ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。 Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。 セキュリティベンダー広報担当者の説明を長々と回りく引用し…

正しく動作するプログラムには 正しい／妥当なデータ 正しいコード の両方が必要です。 仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。 当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう？ 参…

出力対策だけ行なえばOK！と考えてしまう原因は出力対策に3つの役割があることに気付かないからでは？と思ってこのエントリを書いています。 出力対策は”必須である場合”と”フェイルセーフ対策”である場合があります。 出力対策の基本はこちらです。 https://blog.ohgaki.net/3-principles-for-output-handling (さ…

今回は「とあるネットワーク技術者がいかにしてネットワークシステムのセキュリティを守っているのか？」という話です。 「え？！」と思うハズですが、最後までお読みください。 (さらに…)

入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。 入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介しま…

入力バリデーションでほぼ全てのインジェクションリスクを回避／防止できるケースは以前書いたブログで紹介しています。 今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。 ※ ここで紹介する考え方は脆弱なブラックリスト型です。より安全な方法はホワイトリスト型の考え方です。参考： ほぼ全てのインジェクション攻撃を無効化／…

ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1 コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。 (さらに…)

ソフトウェアを開発している時に困るのは、ソフトウェアが正しく動作しないケース、に対応する事です。 実用的なソフトウェア作るよりもプロトタイプを作る方が簡単であるのは、ソフトウェアが正しく動作しないケース、に対応する必要がないことが大きな理由です。ソフトウェアが正しく動作しないケースに対応するには、様々な例外的な状態（入力データとソフトウェアの内部状態）全てに…

インジェクション攻撃、とは言ってもそのインジェクション対象によって影響が異なります。インジェクション攻撃の対象によって2種類、コードとデータ、に分類できます。Webシステムの場合、リクエストのインジェクションを別のインジェクション攻撃と考えた方が解りやすいので、大まかに分類して3種類に分類できます。 インジェクション脆弱性は絶対に避けなければならない脆弱性で…

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。 プログラムが正しく動作する為には 正しいコードであること 正しい（妥当な）データであること が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。 SQLit…

脆弱性を呼ばれた側の責任にする、は常に通用する考え方ではありません。 ライブラリに脆弱性があるなら、ライブラリの脆弱性を直す（呼ばれた側の責任にする） 外部アプリケーションに脆弱性があるなら、外部アプリケーションの脆弱性を直す（呼ばれた側の責任する） は一見正しく見えます。しかし、通用しません。 理由は簡単で、セキュリティ上困った動作をするライブラリやプログ…

ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード（機能）」と「データ」の話として、もっと単純化してみます。 当然の話なのですが、現実には当たり前ではなかったりします。 「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード（機能）」のセキュリティに偏重し…

https://blog.ohgaki.net/programming-view-of-the-world で構造化プログラミング／オブジェクト指向プログラミングの世界観（パラダイム）では、抽象化を行い問題を関数やオブジェクトの中に閉じ込める。つまり、プログラムの内部奥深くに”問題”を閉じ込めようとする。 セキュアコーディングの世界観では、”正しくないデータ…

形式的検証とは 形式的検証（けいしきてきけんしょう）とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法や数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである 英語ではFormal Verificationとされ formal verification is the act…