セキュリティを考慮していないWebアプリを安全に使う方法
世の中には仕様としてセキュリティを考慮していないWebアプリも多くあります。特に開発環境では多いのではないでしょうか？こういったアプリも安全に使う為には少しだけ工夫が必要です。本来、セキュリティを考慮しておいた方が良いWebアプリであっても、セキュリティが考慮されていない場合でもこの方法は利用できます。
セキュアなアプリケーションアーキテクチャ
セキュアなアプリケーションには共通したアーキテクチャがあります。基本的には防御的プログラミング（セキュアプログラミング）を行い、防御的プログラミングのテクニックの１つである契約プログラミングを実践したアーキテクチャがセキュアなアーキテクチャです。
アプリケーションのセキュリティ問題のほとんどはインジェクション問題です。インジェクション問題以外にもセキュリティ問題はありますが、ここではインジェクション問題のみを考慮します。
セキュアプログラミング・コーディング”だけ”でセキュアなプログラムが作れない理由
記事を探すことができなかったのですが、少し前に元記事が英語で日本語訳された記事に「セキュアプログラミング・コーディングはハイプ（誇大な宣伝）である」とする記事がありました。これには全く賛同できません。
なぜセキュアプログラミング”だけ”でセキュアなプログラムが作らないのか？理由を考えてみたいと思います。
PHPのmt_rand関数が壊れている問題
PHPのmt_rand関数のtwistマクロに一文字タイポがあり、修正されたのですが
http://git.php.net/?p=php-src.git;a=commitdiff;h=a0724d30817600540946b41e40f4cfc2a0c30f80
でリバートされてしまいました。
追記
PHP 7.1からMT randのコードが修正されています。ユーザーコード（PHPスクリプト）からはアルゴリズムは選べません。Cモジュールの場合、旧アルゴリズムと修正済アルゴリズムから選択できるようになっています。
この他にもPHPのmt_rand()実装の場合、本来MT randは2^19937の状態を取り得るのですが、PHPはたったの2^32の状態でしか初期化できません。つまり、MT randアルゴリズムに較べて2^19902くらいPHPのmt_rand()は初期値は弱いことになります。（＝比較にならないほどPHPのmt_rand()は予測し易い）
セキュアプログラミングの７つ習慣
セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。
ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。
PHPバイトコードキャッシュの性能 – Opcache
PHPの性能はバイトコードキャッシュにより数倍向上するのですが、久しぶりにopcacheをキーワードに検索してみると「それほど効果がない」と誤った評価をしているページもあったので、Opcacheによりどのくらい速くなるか簡単なベンチマークをします。
PostgreSQLでもカウンター処理を簡単に実装できる！
PostgreSQL 9.5がリリースされました。これに含まれるUPSERT機能を使えばPostgreSQLでも簡単にカウンター処理を実装できます。以前でもトリガーやルール、CTE(Common Table Expression)を使って実装できましたが、追加されたUPSERT機能を使った方が簡単です。
マイナンバーのチェックデジット確認
マイナンバーのチェックデジットを確認する必要があったのでPHP関数を作りました。
正規表現を使ったDoS – ReDoS
いつかは忘れるくらい前に正規表現のアルゴリズム自体を利用してDoS攻撃を行うReDoSが発表されていました。今まであまり気にしていなかったのですが、検索しても日本語のページが出てこないようでした。詳しく知るためのリンクなどを紹介します。
ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単
セキュリティ問題のほとんどはインジェクション問題と考えることができます。インジェクション問題として考えられるセキュリティ問題のモデル化を考えます。
実際のセキュリティ問題は多種多様で非常に複雑ですが、シンプルなモデルで考えると理解り易く、多くのセキュリティ問題を体系的に理解できます。
もし自分が自分に標的型攻撃を行うなら？
最近は標的型攻撃の話題で持ち切りですが、もし自分が自分に標的型攻撃を行うならどうするか？紹介します。
開発者／管理者／ユーザーが安全にWebシステムを利用する方法
Webシステムには様々なリスクがあります。より安全に利用するためのTipsを紹介します。
他の方も普通にこれから紹介する方法を使ってWebシステムにアクセスしている、と思っていたのですがそうでもないようです。これから紹介する方法でリクエストフォージェリやクロスサイトスクリプティングなどのリスクを排除／軽減できます。
リクエストフォージェリを再考 – リクエストのインジェクションと考える
リクエストフォージェリを再考してみたいと思います。リクエストフォージェリには
- SSRF（サーバーサイドリクエストフォージェリ）
- CSRF（クロスサイトリクエストフォージェリ）
- XXE(XMLエクスターナルエンティティ）
などがあります。これらは「リクエスト」を「偽装」（フォージェリ）する攻撃です。名前からは直感的にどのような攻撃なのかよく解らないですが、「攻撃リクエストのインジェクション」と考えると解りやすいと思います。
Fedora22用のPhalcon 2.0.6のSRPM
Fedora22用のPhalcon RPMパッケージを作ったのでダウンロードできるようにしておきます。