yohgaki's blog

カテゴリー: Programming

  • 攻撃可能面（アタックサーフェス）の管理 – セキュリティの基本

    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

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

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

    (さらに…)

  • 開発者の自由を許容するセキュリティ、自由を束縛するセキュリティ

    アプリケーション開発におけるセキュリティ対策は大きく別けて、自由を制限するセキュリティ対策と自由を許容するセキュリティ対策の2種類に分けられると思います。

    「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。

    (さらに…)

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

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

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

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

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

    (さらに…)

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

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

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

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

    (さらに…)

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

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

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

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

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

    Wikipediaの定義では

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

    となっています。

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

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

    (さらに…)

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

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

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

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

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

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

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

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

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

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

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

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

    (さらに…)

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

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

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

    の両方が必要です。

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

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

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

    https://blog.ohgaki.net/secure-coding-structure-principle

    (さらに…)

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

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

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

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

    (さらに…)

  • PHPセッションとSameSiteサポート – CSRF, XSS対策

    PHPのセッションID用クッキーと他のクッキー関数にSameSiteサポートが追加されます。

    https://wiki.php.net/rfc/same-site-cookie

    これによりクロスサイト・リクエスト・フォージェリ攻撃（CSRFやXSS）などを緩和できます。

    (さらに…)

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

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

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

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

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

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

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

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

    (さらに…)

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

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

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

    (さらに…)

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

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

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

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

    https://blog.ohgaki.net/3-principles-for-output-handling

    (さらに…)

  • とあるネットワーク技術者の防御法

    今回は「とあるネットワーク技術者がいかにしてネットワークシステムのセキュリティを守っているのか？」という話です。

    「え？！」と思うハズですが、最後までお読みください。

    (さらに…)

  • 忘れられた入力処理と出力処理の責任

    入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。

    入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。

    脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。

    このエントリはデータからの視点で見たデータセキュリティの話です。

    (さらに…)

  • 入力バリデーションで許可した文字で発生するリスク

    入力バリデーションでほぼ全てのインジェクションリスクを回避／防止できるケースは以前書いたブログで紹介しています。

    今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。

    ※ ここで紹介する考え方は脆弱なブラックリスト型です。より安全な方法はホワイトリスト型の考え方です。参考： ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション

    (さらに…)