OTP（ワンタイムパスワード、2要素認証）とタイミング攻撃
今すぐできる、Webサイトへの2要素認証導入と2要素認証のTOTPとHOTP、どちらがより安全か？で紹介したGoogleAuthenticatorですが、ソースコードを確認ところタイミング攻撃に脆弱でした。Pull Requestを後で送る予定ですが、利用される場合は脆弱性を修正してから使ってください。
2要素認証のTOTPとHOTP、どちらがより安全か？
今すぐできる、Webサイトへの2要素認証導入では簡単に2要素認証が導入できること、2要素認証には
- 時間ベースのOTP（TOTP：Time-based One Time Password RFC 6238)
- カウンターベースのOTP（HOTP：HMAC-based One-Time Password RFC 4226）
があることを紹介しました。Google認証は両方をサポートしています。※
※ 今すぐできる、Webサイトへの2要素認証導入で紹介したライブラリはTOTPのみサポートしています。
今すぐできる、Webサイトへの2要素認証導入
Google、Facebook、Amazon(AWS)、Githubなど、大手Webサービス会社が2要素認証を取り入れてしばらく経っています。自分のWebサイトでも2要素認証を導入したい！と思ったことは無いですか？
簡単に可能です！
パスワード認証だけではもう安全とは言えません。ぜひ2要素認証を自分のサービス／プロダクトに導入してください。
Laravelエキスパート養成読本
PHP用Webアプリケーションフレームワークとして人気を得つつあるLaravelの入門書「Laravelエキスパート養成読本」を献本頂きました。Software Design Plusのムック本になっています。
岡山大学大学院平成27年度ビジネスマインド養成講座のご案内
追記：平成29年度の講座の情報は
をご覧ください。
岡山大学大学院 平成27年度ビジネスマインド養成講座のご案内です。想定している対象は大学教職員、学生およびIT関連のマネジメントを行う社会人を対象とした無償の講座ですが、ITにはマネジメントが欠かせません。IT技術者の方にも有用な講座です。
岡山でも技術系／交流系の勉強会が色々行われていますが、マネジメント系を対象とした物は少ないと思います。講義は岡山大学の島津キャンパスで行われます。お誘い合わせの上、お申し込みをお願いいたします。
追記：残席があるようです。この日でもまだ参加できるようなので、いつでもご連絡ください。手配致します。2015/6/25
PHPポケットリファレンスのサポートページ
PHPポケットりファンレス
- [改訂第3版]PHPポケットリファレンス
（アマゾン）
- ［改訂第３版］PHPポケットリファレンス （電子版）（技術評論社）
の正誤表などを記載した個人的なサポートページを作りました。
間違いや解りずらい点などは気軽にメールでお知らせください。
PHP7のタイプヒントベストプラクティス
PHP 7から基本的なデータ型（整数型、浮動小数点型、配列型）タイプヒントが追加されます。直感的に書くコードと正しいコードには乖離があります。PHP7でタイプヒントを使う場合のベストプラクティスを紹介します。
タイプヒントとタイプヒントの問題点については前回のブログを参照してください。
PHP7とjson_decodeとjson_encodeの困った仕様 – 数値型データの問題
PHP7からint/float/arrayの基本的データ型のタイプヒントが導入されます。タイプヒントには困った問題があります。その問題を更に複雑にするjson_decode関数のデータ型変換問題があります。
JSONデータの数値型データ※が特定の型に変換される問題はPHPのjson_decode関数に限った問題ではなく、JSONを利用する処理系を作る全ての開発者が注意すべき問題です。
※正確には数値型データと書くより「数値型リテラル」と記述するべきですが、「数値型データ」とします。
PHP7で追加される整数型、浮動小数点型タイプヒントの問題点
PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。
データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。
参考
PHPポケットリファレンス改訂第三版
PHP5.6にも対応したPHPポケットリファレンス改訂第三版が今月初め頃から購入可能になっています。こちらの案内もブログを書く時間がなく、ここに記載できていませんでした。
- [改訂第3版]PHPポケットリファレンス
- ［改訂第３版］PHPポケットリファレンス （電子版）（技術評論社） もっと読む
Webアプリケーションセキュリティ対策入門の付録を更新
既に執筆してから10年ほど経っている「Webアプリケーションセキュリティ対策入門」ですが、サンプルコードがおかしいという指摘がありました。しばらく前からWikiに載せているのですが、時間がなくブログは書いていませんでした。
コードが随分おかしいという指摘は今まで私にまで届いておらず、何かバグがあったのだろうくらいに思ってっていました。しかし、実際にコードを見てみるとおかしなことだらけで、とんでもないミスをしていがことが分かりました。
アプリケーション仕様とセキュリティ仕様の関係
アプリケーション（ソフトウェア）仕様とセキュリティ仕様の関係とその特徴は正しく理解しておく必要があります。この関係と仕様の特徴を正しく理解しておかないと根本的な部分での間違いにつながります。
SQLite3の全てのカラムがテキスト型である問題に対する誤解
以前にSQLite3のデータ型は基本的には全てテキスト（例外は整数型プライマリーキー ※）である、という解説をしました。
どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。
※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。
参考：SQLite3のカラム仕様を理解している必要があります。
徳丸浩氏との長年の議論に終止符 – 論理的／体系的セキュリティとそれ以外
私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。
徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「アプリのバリデーションはセキュリティ対策ではない」としている方がWAFを売りやすいからです。
徳丸さんにもこのブログを書いたことを連絡し、もし誤解している部分があるのであれば反映したいと思います。これから紹介するように論理矛盾が明らかになった直後、今後議論をされないことを表明されましたが、この長いブログでも手法や論理的矛盾の誤りを指摘し尽くしていないので議論いたします。徳丸さん、反論を書かれるようであればご連絡ください。
追記：”原理／原則などに根拠がない”ことが判ったので議論することは無いのですが、IPAが誤りを正した後の2017年に間違ったセキュアコーディングを啓蒙されていました。これは指摘せざるを得ないのでブログに書きました。
科学的に出鱈目なセキュリティ対策で得をするのは、サイバー犯罪者とセキュリティ業者だけす。
TL;DR;
論理的思考で導ける必要条件と十分条件を理解している方にはここで解説している内容は読まずとも理解されていると思います。
Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能
Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。
Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。