ホワイトリスト派とブラックリスト派 〜 セキュアコーディングが行われない理由

セキュアコーディングの原則1は「信頼できない入力を全てバリデーションする」です。この原則は国際情報セキュリティ標準でも当たり前の要求事項となっています。しかし、残念ながら「信頼できない入力を全てバリデーションする」が正しく実装されているアプリケーションはほとんどありません。

独自の定義や自分勝手なセキュアコーディング解釈をしているケースが散見されます。ここでいう「セキュアコーディング」とはCERTのセキュアコーディング、ISO 27000が要求しているセキュアプログラミングを指します。

“ホワイトリスト派とブラックリスト派 〜 セキュアコーディングが行われない理由” の続きを読む

実は知られていない?リスク対策の原則?

ISO 31000(リスクマネジメント標準規格)はa)からk)まで、11のリスク管理の原則を定めています。

ITエンジニアであればISO 27000(情報セキュリティマネジメント標準規格)を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎/基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。

情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。

リスク対策の原則が知られていない?ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。

“実は知られていない?リスク対策の原則?” の続きを読む

ソフトウェアセキュリティのアンチパターン

アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。

このエントリは不定期にメンテナンスするつもりです。

“ソフトウェアセキュリティのアンチパターン” の続きを読む

本当にプリペアードクエリだけを使っていますか?

SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。

  • 多くの場合、速い
  • SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
    • 特に初心者は「ついうっかり」が多い

しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。

何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。

例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。

こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。

特定カラムの抽出/ソート(これはエスケープでぼほOK)、テーブル指定をするクエリは当たり前に存在します。

“本当にプリペアードクエリだけを使っていますか?” の続きを読む

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

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アプリの入力はバリデーションできない、という誤解” の続きを読む