Session management is the center of web security. However, many session management in web application/framework ignored the risk of session adoption for years. PHP 5.5.4 fixed session adoption vulnerability. This article explains the reason why session adoption fix is mandatory for secure web application.
NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。
ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。
要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、
▽セキュリティー対策ソフトを入れる。
などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。
NHKが紹介した対策ページではスクリーンショット等も交えながら
▽アプリは公式アプリストアからのみダウンロードする。
としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。
確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。
このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。
Webシステムに限らず、SQLインジェクション脆弱性は絶対に作りたくない脆弱性の１つです。裁判でSQLインジェクション対策漏れよる損害賠償が契約金額を上回った事例もあります。
ソースコード検査ならSQLインジェクションが行えないことを保証することが可能です。私の会社ではソースコード検査サービスを提供していますが、これまでに検査証を発行したアプリケーションでSQLインジェクションが問題になった事はありません。 もっと読む
今回は「とあるネットワーク技術者がいかにしてネットワークシステムのセキュリティを守っているのか？」という話です。
「え？！」と思うハズですが、最後までお読みください。
RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。
プログラムが正しく動作する為には
が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。
SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。1
利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。
プログラムを作っているとOSコマンドを実行したくなる時があります。OSコマンドの実行に問題があり、不正なコマンドをインジェクションされると大変な事になります。
どのようなセキュリティガイドラインでも「OSコマンドの実行に注意する」と大抵書かれています。
多くの場合、「コマンド実行時、コマンドと引数を分離すれば安全に実行できるAPIを利用すれば安全に実行できる」としています。
この記述は間違ってはいないです。しかし、正しくは
です。
コマンドと引数を分離するAPI利用だけでは完璧とは言えないセキュリティ対策です。
一応、PHPの危い関数リスト、は存在します。例えば、以下のような物があります。
後者は主にホスティング環境（？）でリスクがある関数の一覧を作るプログラムのようです。
ファイルを操作する関数、コマンドやスクリプトを実行する関数などのリスクは自明だと思います。少し趣向を変え、間違えて使うと危い関数の一覧を独断と偏見で作ってみました。
【重要】こういった「危険な物」を定義するのはブラックリストです。ブラックリストは仕組的に危険です。ブラックリストに頼るのは脆弱性を作るような物です。ブラックリスト”だけ”で安心しないでください。最後にどうすれば良いのか？を書きます。
で構造化プログラミング／オブジェクト指向プログラミングの世界観（パラダイム）では、抽象化を行い問題を関数やオブジェクトの中に閉じ込める。つまり、プログラムの内部奥深くに”問題”を閉じ込めようとする。
セキュアコーディングの世界観では、”正しくないデータはどう処理しても正しく処理不可能である”プログラム原理と”失敗する物はできる限り早く失敗させる”Fail Fast原則に従い、できる限り問題となる”データ”を早い段階で廃除する、つまり問題を中に入れずに入り口で対策する、と紹介しました。1
一見すると相反するように見えますが、これら２つの世界観を持つ概念は二者択一ではありません。
PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを１つインクルードする以外、ほとんど何も行う必要がありません。
Webブラウザに対するJavaScriptコードのインジェクションは
で起きる可能性があります。ここでは主にクライアント側が関係するケースで注意しなければならない箇所を紹介します。
rustcを通らないコードは間違っているに以下のような記述があります。
「そのコードがRust wayではない」という点で「間違っている」。microなスタイルからmacroな設計まで、ありとあらゆる点でRust的なコードであることを暗黙的ではあるが極めて強く要求する。それがRustというプログラミング言語だ。
Rustはコンパイル時点で可能な限りの正しく実行できないコードが生成されないような言語になっていることは比較的良く知られていると思います。このブログはこの違いを「世界観」が異なるという視点でまとめています。
Rustの場合、マルチスレッドプログラミングでデータ競合が起きないような書き方をしなければならない制約があり、従来のプログラミング言語とは異なる考え方（＝世界観）が要求されている。自分のコードは正しくても「Rustの世界観では間違っている」としています。
「世界観」の違いで言語やプログラミング方式を捉える考え方は面白いと思います。
覚えなくて構わないパスワード（ブラウザなどのパスワードマネージャーに記憶させる最強のパスワード）の作り方は、
で紹介しました。最強のパスワードを自分で作るのが面倒な方はこのページのランダム文字列から90文字くらいをコピー＆ペーストして使ってください。
今回は覚えられる最強のパスワードの作り方です。
備考：あるニュース記事で”ブラウザのパスワード機能は使わない”とする記事がありました。その理由は、離席した場合などにパスワードが表示できる物もあるから、でした。しかし、PCをログインしたままロックもせずに離席すると、ログイン済みならアクセス仕放題、サードパーティー製のパスワードマネージャーを使っていても利用するサービスにはログイン仕放題、です。デバイスの物理セキュリティは何をしていてもある程度は使い方で保証しなければセキュリティは維持できません。
形式的検証とは
形式的検証（けいしきてきけんしょう）とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法や数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである
英語ではFormal Verificationとされ
formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.
と説明されています。形式手法として紹介されることも多いです。
参考： 形式検証入門 （PDF）
形式的検証は、記述として検証する方法から数学的にプログラムが正しく実行されることを検証する仕組みまで含みます。数学的な形式的検証では、可能な限り、全ての状態を検証できるようにしてプログラムが正しく実行できることの証明を試みます。
参考：ソフトウエアは硬い （日経XTECHの記事）
契約プログラミング（契約による設計 – Design by Contract, DbC）も形式的検証の１つの方法です。
形式検証の仕組みを知ると、厳格な入力バリデーションが無いと”組み合わせ爆発”により、誤作動（≒ セキュリティ問題）の確率も爆発的に増えることが解ります。
往年のWeb開発者であれば X-Content-Type-Options: nosniff はIE専用のオプションHTTPヘッダーだと理解している方が多いと思います。
この理解は正しかったのですが、現在は正しくありません。nosniffはChromeやFirefoxの動作にも影響与えます。このため、IEをサポートしないサイトであっても X-Content-Type-Options: nosniff は必要なHTTPヘッダーです。
Webサイトにはパスワードの登録に余計な制限をかけているサイトが少なからずあります。特に最悪なのはたった20文字程度のパスワードしか許可しないサイトです。
Webサイトのパスワードは基本的には覚える必要がありません。安全性を第一に考えると十分過ぎるくらいの長さのランダムパスワードを設定する／設定できるようにすると良いです。
パスワード用のランダム文字列が必要でアクセスした方は以下のURLを参照してください。生成されたランダム文字列の一部、90文字くらい、をパスワードとして使うと安全です。
パスワード用のランダム文字列生成ページ （ランダム文字列を表示します）