セキュアコーディング/セキュアプログラミングが流行らない理由

ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1

しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか?

なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます。

セキュアコーディング/セキュアプログラミングとは?という方は以下を参考にしてください。

“セキュアコーディング/セキュアプログラミングが流行らない理由” の続きを読む

「セキュアコーディング方法論再構築の試み」を再構築してみる

 

セキュアコーディングに関して大きな誤解がある資料があったのでこのブログを書いています。

一つ前のブログは二つ以上の議論を理解しながら読まなければならないので解りづらい、とご意見を頂いたので”「セキュアコーディング方法論再構築の試み」を再構築してみる”として書き直してみました。

“「セキュアコーディング方法論再構築の試み」を再構築してみる” の続きを読む

セキュアコーディングを理解できていない例

追記:解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。

セキュリティの専門家と呼ばれる人であってもセキュアコーディング/セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。

参考1:セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング/セキュアプログラミングの歴史は理解しておた方が良いかも知れません。

参考2:そもそも、原理的/論理的に入力対策を無視/軽視したセキュリティ対策は誤りです。

参考3:前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。

“セキュアコーディングを理解できていない例” の続きを読む

OWASPに対して失礼な誤解 – 入力バリデーションは重要なセキュリティ対策

OWASPに対して大変失礼な誤解をしている意見を見かけたのでブログに書いておきます。

OWASPは「入力バリデーション」とても重要な「セキュリティ対策」として考えていますが、OWASP的にはセキュリティ対策ではない、少なくとも重要なセキュリティ対策ではない、というとんでもない誤解はOWASPに対して大変失礼な誤解と言えます。

“OWASPに対して失礼な誤解 – 入力バリデーションは重要なセキュリティ対策” の続きを読む

「黒い」セキュリティだのみは捨て去る

「黒い」セキュリティとはブラックリスト型セキュリティのことです。

ブラックリスト型セキュリティとは「ブラックリスト型対策でセキュリティを維持しよう」とする概念です。セキュリティ対策では、ブラックリスト型対策はできる限り使わず、可能な限りホワイトリスト型対策を使う、が基本です。しかし、ブラックリスト型の「黒いセキュリティ」対策が理想的な対策である、と考えている人が少くないようです。

「黒いセキュリティ」に頼ったITセキュリティは基本的に捨て去るべきです。

“「黒い」セキュリティだのみは捨て去る” の続きを読む

セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!

セキュアコーディング/セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。(※ 対策の目的が何か?などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません)

どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング/セキュアプログラミングのガイドラインなどがどうなっているのか?紹介します。

このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング/セキュアプログラミングとは何か?は過去のブログをご覧ください。

“セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!” の続きを読む

セキュアプログラミング・コーディング”だけ”でセキュアなプログラムが作れない理由

記事を探すことができなかったのですが、少し前に元記事が英語で日本語訳された記事に「セキュアプログラミング・コーディングはハイプ(誇大な宣伝)である」とする記事がありました。これには全く賛同できません。

なぜセキュアプログラミング”だけ”でセキュアなプログラムが作らないのか?理由を考えてみたいと思います。

“セキュアプログラミング・コーディング”だけ”でセキュアなプログラムが作れない理由” の続きを読む

セキュリティ対策の目的と手段 〜 根本的誤りの元 〜

目的と手段、これを取り違えて大きな誤りを犯してしまうことはよくあります。これはセキュリティ対策に限ったことではありません。

対策をセキュリティ対策の目的と手段を取り違えると、根本的な誤りを犯してしまいます。

備考:目的と手段の取り違えが根本的な原因と言えますが、「セキュリティ対策」定義を取り違えているとこのブログの内容は理解しずらいかも知れません。セキュリティ対策に「緩和策」や「リスク増加」が含まれることを認識されていない方はまずセキュリティ対策の定義を確認ください。

参考:「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由

“セキュリティ対策の目的と手段 〜 根本的誤りの元 〜” の続きを読む

「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由

このブログを継続的に読んでいる方なら私が「個々のセキュリティ脆弱性対策も重要だが、基本的考え方や概念はより重要である」と考えていることがわかると思います。「個々の脆弱性対策だけやれば良い」とする議論がありますが、これには色々な欠陥があります。このため、「個々の脆弱性対策だけやる」では効果的なセキュリティマネジメントができません。つまり、より危険なセキュリティになってしまいます。

追記:このエントリだけではなぜマネジメントが大切なのかは伝わらないと思うので、容易に導入できるセキュア開発メソドロジー – OpenSAMM を書きました。こちらも参照ください。

“「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由” の続きを読む

入力バリデーションがセキュリティ対策かどうかは、”どうでもいい”!?

徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。

”セキュリティ専門家”という肩書を持つ方が非論理的/非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的/非科学的なのか簡単にコメントします。

 

“入力バリデーションがセキュリティ対策かどうかは、”どうでもいい”!?” の続きを読む

安全なAPI過信症候群 – 普通のRDBMS編

昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。

プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。

“安全なAPI過信症候群 – 普通のRDBMS編” の続きを読む

安全なAPI過信症候群の処方箋 – execv/SQLite3編

またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。

安全なAPI過信症候群(同類にプリペアードクエリ過信症候群など):「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。

このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。

現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。

追記:普通のRDBMS編も作りました。SQLiteの仕様でデータ型がどうなっているか簡単に説明しました。

“安全なAPI過信症候群の処方箋 – execv/SQLite3編” の続きを読む

オレオレSQLセキュリティ教育は論理的に破綻している

ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。

このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています
“オレオレSQLセキュリティ教育は論理的に破綻している” の続きを読む

ジョブセキュリティ:セキュリティ業界の為のセキュリティ対策ではありませんか?

追記:このエントリの背景となる根拠の一部となる開発者は必修、SANS TOP 25の怪物的なセキュリティ対策に書きました。こちらも合わせてご覧ください。

今日のエントリは「セキュリティ業界ジョブセキュリの為のセキュリティー対策になっていないか?」という話です。

ジョブセキュリティ

知らないと仕事にならないような、雇用を守る作用を持つ手法や知識のこと。

セキュリティ対策は様々な対象を守る為に行いますが、このエントリではアプリケーションセキュリティを維持することだけを考えます。

“ジョブセキュリティ:セキュリティ業界の為のセキュリティ対策ではありませんか?” の続きを読む

Webアプリの入力はバリデーションできない、という誤解

Webアプリの入力はバリデーションできない、と誤解している方は少なく無いようです。システム開発に関わる人でなければ誤解していても構わないのですが、システム開発者が誤解していると安全なシステムを作ることは難しいでしょう。

Webアプリの入力はバリデーションできない、と誤解している開発者にも理解できるよう噛み砕いて解説してみます。

“Webアプリの入力はバリデーションできない、という誤解” の続きを読む

入力バリデーションはセキュリティ対策の基本

徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。

http://tumblr.tokumaru.org/post/55587596019

私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。

結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。

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

参考:プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション(=セキュリティ対策)がない対策はあり得ない。

データのセキュリティ対策が無いセキュリティ対策?!

“入力バリデーションはセキュリティ対策の基本” の続きを読む

セッションアダプション脆弱性がないセッション管理が必要な理由

徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。

まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。

セッションアダプションに脆弱なセッション管理機構で困る代表的なケースは以下の通りでしょう。

  1. ログイン時にsession_regenerate_idを呼んでない
  2. 自動ログインなど通常のセッション用以外でsession_regenerate_idを呼んでいない
  3. session_regenerate_idを呼んでいても、途中で保存している
  4. session_regenerate_idを呼んでいても、途中で実行パスが変えられる

“セッションアダプション脆弱性がないセッション管理が必要な理由” の続きを読む

PHPのセッションアダプション脆弱性は修正して当然の脆弱性

PHPのセッションアダプション脆弱性がどのように影響するのか、広く誤解されているようです。セキュリティ専門家でも正しく理解していないので、一部のPHP開発者が正しく理解しなかったのは仕方ないのかも知れません。

Webセキュリティの第一人者の一人である徳丸氏は「PHPのセッションアダプション脆弱性は脅威ではない」と書いていますが、いろいろ間違いです。私は2005年頃から現在まで様々な機会に問題であると何度も繰り返し説明しており、しばらくすれば間違いに自分で気付くのでは?と思っていたので特に反論していませんでした。しかし、まだ気づかれていないようなので、幾つかある攻撃パターンのうち解りやすい例を1つだけ紹介しておきます。

“PHPのセッションアダプション脆弱性は修正して当然の脆弱性” の続きを読む

セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?

一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。

その間違いとは

  • 意図の取り違い – 誤読
  • 言語の仕様と実装の理解不足
  • HTTPやPHP仕様の理解不足
  • セキュリティ対策をすべき場所の理解不足

です。(※0)

“セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?” の続きを読む