カテゴリー: Security

セキュアプログラミング(防御的プログラミング)の歴史をざっと振り返る

キュアプログラミング(防御的プログラミング)の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の1つ※です。古くからある概念ですが、誤解または理解されていない概念の1つではないでしょうか?

Defensive Programmingとして記載されています。

何故、一般に広く常識として理解されていないのか?その理由は防御的プログラミングの歴史にあるのかも知れません。

参考:

もっと読む

不整合が起きてはならない場合、トランザクションはシリアライザブル

リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。

もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。

もっと読む

開発者でなくても解るセキュリティ対策 – 入力バリデーション編

ITシステムに限らずセキュリティ対策で最初に行うべき対策は境界防御(契約による設計と信頼境界線標準と基本概念開発者は必修SANS TOP 25)です。ソフトウェアにおける境界防御の第一番は入力の確認(入力の確実な制御)です。このブログでは何度も取り上げていますが、最も重要なセキュリティ対策である境界防御の概念と入力の確認が正しく認識されていない場合がよくあります。

開発者であるから「これで解るはず」と思い書いたエントリは幾つか(「合成の誤謬」の罠エンジニアに見られるセキュリティ対策理解の壁など)ありますが、どうも成功しているとは言えないようです。今回は開発者でなくても理解できるよう努力してみます。

ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

もっと読む

今すぐできる、WordPressサイトへの2要素認証導入

このブログもWordPressです。パスワードの辞書攻撃、ブルートフォース攻撃を思われるアクセスが大量にあります。WordPressへの2要素認証導入はプラグインのインストールだけでできます。

開発者向けの2要素認証導入もブログに書いています。開発者の方は早めに自分のサイト/サービスに2要素認証を導入することをお勧めします。

 

もっと読む

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要素認証を自分のサービス/プロダクトに導入してください。

もっと読む

PHP7とjson_decodeとjson_encodeの困った仕様 – 数値型データの問題

PHP7からint/float/arrayの基本的データ型のタイプヒントが導入されます。タイプヒントには困った問題があります。その問題を更に複雑にするjson_decode関数のデータ型変換問題があります。

JSONデータの数値型データ※が特定の型に変換される問題はPHPのjson_decode関数に限った問題ではなく、JSONを利用する処理系を作る全ての開発者が注意すべき問題です。

※正確には数値型データと書くより「数値型リテラル」と記述するべきですが、「数値型データ」とします。

もっと読む

PHP7で追加される整数型、浮動小数点型タイプヒントの問題点

PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。

データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。

参考

もっと読む

Webアプリケーションセキュリティ対策入門の付録を更新

既に執筆してから10年ほど経っている「Webアプリケーションセキュリティ対策入門」ですが、サンプルコードがおかしいという指摘がありました。しばらく前からWikiに載せているのですが、時間がなくブログは書いていませんでした。

http://wiki.ohgaki.net/sample

コードが随分おかしいという指摘は今まで私にまで届いておらず、何かバグがあったのだろうくらいに思ってっていました。しかし、実際にコードを見てみるとおかしなことだらけで、とんでもないミスをしていがことが分かりました。

もっと読む

SQLite3の全てのカラムがテキスト型である問題に対する誤解

以前にSQLite3のデータ型は基本的には全てテキスト(例外は整数型プライマリーキー ※)である、という解説をしました。

どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。

※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。

参考:SQLite3のカラム仕様を理解している必要があります。

SQLiteデータ型の仕様とセキュリティ問題

もっと読む

徳丸浩氏との長年の議論に終止符 – 論理的/体系的セキュリティとそれ以外

私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格/ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。

徳丸さんがセキュリティ対策製品であるWAF(Web Application Firewall)を販売/推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか?と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「アプリのバリデーションはセキュリティ対策ではない」としている方がWAFを売りやすいからです。

徳丸さんにもこのブログを書いたことを連絡し、もし誤解している部分があるのであれば反映したいと思います。これから紹介するように論理矛盾が明らかになった直後、今後議論をされないことを表明されましたが、この長いブログでも手法や論理的矛盾の誤りを指摘し尽くしていないので議論いたします。徳丸さん、反論を書かれるようであればご連絡ください。

追記:”原理/原則などに根拠がない”ことが判ったので議論することは無いのですが、IPAが誤りを正した後の2017年に間違ったセキュアコーディングを啓蒙されていました。これは指摘せざるを得ないのでブログに書きました。

科学的に出鱈目なセキュリティ対策で得をするのは、サイバー犯罪者とセキュリティ業者だけす。

TL;DR;

論理的思考で導ける必要条件と十分条件を理解している方にはここで解説している内容は読まずとも理解されていると思います。

もっと読む