PostgreSQL 8.2をインストール

OWASP Secure Coding Practices – Quick Reference Guide

OWASPのガイドラインはPCI DSSでも参照するように指定されているセキュリティガイドラインです。その中でも比較的簡潔かつ体系的にセキュアプログラミングを解説した資料がOWASP Secure Coding Practices – Quick Reference Guide (v2) です。

日本語訳がないようなので一部未訳ですが訳しました。CC-BY-SAライセンスです。クリエイティブコモンズライセンスに従って自由に配布できます。

チェックリスト形式になっているので、自分のコーディング/開発スタイルがどの程度適合しているのか、簡単にチェックできるようになっています。コーディングスタイルのみでなく、運用はシステム構成に関連する物も含まれています。私が解説/紹介しているセキュリティ対策を行っている開発チームであればこれらの殆どに適合しているはずです。どのくらい適合していたでしょうか?

イントロダクションでは、開発者に対して少々厳しいことが書いてあります。

この技術的不可知論文書は一般的なセキュアコーディングを実践に必要な要素をソフトウェア開発ライフサイクルに統合可能なチェックリストとして定義します。

「技術的不可知論文書」(不可知論:物事の本質は人には認識することが不可能である、とする立場のこと ※ )としているのは、この文書が取り扱うセキュアコーディングの本質が理解されていない、理解されることがない、と嘆いていることを意味します。セキュアコーディングの本質の解説は諦めて作ったチェックリストであることを示唆しています。私も同じ感覚を共有しています。興味がある方はぜひ以下の参考資料を参照してください。原理と原則を知った方が応用範囲が広がります。

正確な直訳より分かり易さを優先しました。見直しをする時間まではありませんでした。誤り、誤解を招く訳などの指摘を歓迎します。

※ Agnostic(不可知論)について: このガイドは2010年に公開された文書です。最近、agnosticは「〜に依存しない」「〜に関わらず」「〜を問わず」「汎用的」「プラガブル」「詳しく知らなくても使える」といったコンテクストで割と一般的なIT用語として利用されています。2010年頃は哲学的意味が強かったと思いますが、現在は先に書いたような意味で使われているケースが多くあります。

参考資料:

もっと読む

PHP本体でタイミング攻撃を防御できるようになります

PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。

タイミングセーフな文字列比較関数はhash_equalsとして実装されました。
http://php.net/manual/es/function.hash-equals.php

もっと読む

XPathクエリ(2)

XPathクエリ(1)の続きです。

現在のPHPのXPathクエリの問題はXPath 1.0である事です。通常の仕様書であれば特殊文字のある文字列の場合はエスケープ方法やエスケープAPIが定義されています。エスケープ方法が定義されていなければ「特殊文字を入力することができない」からです。エスケープ方法が無い場合は「エスケープが必要ないAPI」を用意すべきです。

しかし、XPath 1.0ではエスケープ方法もエスケープAPI、エスケープが必要ないAPIも定義されていません。このような場合、仕様を実装しているライブラリの実際の挙動を確認して利用することになります。PHPのSimpleXML、XMLXpathクラスの場合はlibxml2を利用しているので、libxml2の動作を確かめる必要があります。

もっと読む

gmailのメール送信のTLSエラーの修正

gmailの仕様が変更され自己署名証明書が使えなくなりgmail設定の「アカウントとインポート」で設定したメールアドレスからの送信が使えなくなったようです。結構困っている人が多いようですが判ってしまえば直す方法はそれ程難しくありません。

エラーメッセージで検索するとどうもこの4月くらいから仕様変更されているようです。qmailを使っているのでqmailでの修正方法です。postfixなどでもやる事はあまり変わりません。

もっと読む

特定の処理を行うデータを渡すURLの作り方

Webアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。

例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。

もっと読む

今さら聞けない「コード」と「データ」の話

ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード(機能)」と「データ」の話として、もっと単純化してみます。

当然の話なのですが、現実には当たり前ではなかったりします。

「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード(機能)」のセキュリティに偏重した構造と対策になっています。

安全なプログラムの作成には「コード(機能)」と「データ」のセキュリティを分けて考える必要があります。

もっと読む

エンジニア必須の概念 – 契約による設計と信頼境界線

少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。

契約による設計(契約プログラミング)(Design by Contract – DbC)は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
もっと読む

7PK – APIの乱用とは?

7PKとは「Seven pernicious kingdoms: a taxonomy of software security errors」の略でソフトウェアセキュリティ領域の分類の一つです。CWEのビューのCWE-700としても利用されています。CWE-700となっているので、ISO 27000などのセキュリティ標準で要求される「セキュアコーディング」の基礎知識として知っておくべき分類方法/概念です。

入力バリデーションの次に重要な領域である「APIの乱用/誤用」を紹介します。

※ 入力バリデーションが第一番目である理由は、入力データの妥当性が保証されていなとプログラムは絶対に正しく動作しないからです。不正な入力で動作しているように見えても、誤った出鱈目な結果を返しているだけです。プログラムが脆弱性なく正しく動作する為には入力バリデーションが欠かせません。

もっと読む

RFID防止財布の作り方

RFIDでトラッキングされる事が気になる方は是非どうぞ。
# これなら缶にカードを入れたほうがまし?!

追記: ブログ移行でリンク先が消えたので補足します。RFIDは強い規定以上の強い電磁波を使えば読み取り距離が数ミリのRFIDでも、10メートル以上離れた場所から読み取りが可能だったりします。RFID情報を読み取ることにより誰が入店したのか?などの情報をどんどん集めることが可能になります。RFID情報と所有者の個人情報を結びつけられると詳細な利用情報を得られます。

こういったRFIDカード情報の収集を防ぐにはRFIDカードに対する余計な電磁波を遮断する必要があります。元々付けていたリンク先にはRFID情報の不正読み取りを防ぐ財布の作り方が記載されていたと思います。

エネミー・オブ・アメリカ」でジーンハックマンがやっていたように、アルミで出来ているポテトチップスの袋でも代用可能ですが、現在だとAmazonなどで「RFID 保護 財布」などをキーワードに検索すると、色々な製品を売っています。