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

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

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

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

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

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

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

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

ゼロトラストをより細かく分解する

セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。

※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。

“ゼロトラストをより細かく分解する” の続きを読む

知っておくべきITセキュリティ概念Top 10 〜ショート版〜

ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。

では開発者必修のセキュリティ概念 Top 10です。

※ 長くなったので短い版を作りました。ロング版はこちら

“知っておくべきITセキュリティ概念Top 10 〜ショート版〜” の続きを読む

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

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

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

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

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

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

5分で解るセキュアコーディング

セキュアコーディングで最も重要な部分を理解するのは簡単です。スライドを作ったので公開します。

出力対策だけのセキュリティ対策は”誤り”です。

「出力対策だけのセキュリティ設計」が誤りである理由

確証バイアスのせいか、”セキュリティ専門家”を含め、この基本原理が理解できないケースが多いです。

 

信頼境界線の引き方と防り方 – セキュリティの構造と設計

信頼境界線Trust Boundary)と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」(≒効率的なセキュリティ対策)ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。

このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方(≒セキュリティ構造/設計)、ついて紹介します。かなり長いエントリになりましたがお付き合いください。

“信頼境界線の引き方と防り方 – セキュリティの構造と設計” の続きを読む

Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由

Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)

  • HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる

という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか?気になったので調べたメモです。

コード実行ができた理由は「国際化(翻訳)用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。

 

“Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由” の続きを読む

ISO 27000の入力データ妥当性確認

セキュリティ標準では入力データの妥当性確認(入力バリデーション)が要求されています。具体的な方法はBS 7799(英国のJIS規格のような物、2000年に国際標準化)が作られた時(90年代後半)から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。(日本では普及していないような。。)

セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。

かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて(?)ブログにします。

“ISO 27000の入力データ妥当性確認” の続きを読む

完全なSQLインジェクション対策

不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。

  • プリペアードクエリ/プレイスホルダを使ったSQLインジェクション対策でOK

は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。

簡単な証明:プリペアードクエリ”だけ”では、識別子(カラム/テーブル等)を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ/バリデーションが必須。(問題はコレだけはありません)

似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。

出力対策”のみ”のセキュリティはアンチプラクティス

アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません

参考:

“完全なSQLインジェクション対策” の続きを読む

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

セキュアプログラミングの7つ習慣

セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。

ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。

“セキュアプログラミングの7つ習慣” の続きを読む

ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単

セキュリティ問題のほとんどはインジェクション問題と考えることができます。インジェクション問題として考えられるセキュリティ問題のモデル化を考えます。

実際のセキュリティ問題は多種多様で非常に複雑ですが、シンプルなモデルで考えると理解り易く、多くのセキュリティ問題を体系的に理解できます。

“ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単” の続きを読む

ISO 27000とセキュアプログラミング

セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。

ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS(Information Secuirty Management System – 情報セキュリティマネジメントシステム)認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる!といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で4646組織の認証登録があります。

 

“ISO 27000とセキュアプログラミング” の続きを読む

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

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

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

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

今時のShellcodeとセキュア/防御的プログラミング

コンピュータセキュリティのことを考えるとShellcode(シェルコード)のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています

Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。

私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。

“今時のShellcodeとセキュア/防御的プログラミング” の続きを読む

CERT Top 10 Secure Coding Practices

CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング(防御的プログラミング)の歴史をざっと振り返るを参照してください。

CERTはSecure Coding Standardsとして

を公開しています。その中でもセキュアコーディング(セキュアプログラミング/防御的プログラミング)で最も重要なトップ10をTop 10 Secure Coding Practicesとしてまとめています。

日本語訳が無いようなので資料として利用できるよう私訳しておきます。
(追記:IPAのセキュアコーディングガイドは入力対策が出鱈目でした。 2017年からやっとIPAがCERT Secure Coding Practicesをセキュアコーディングの”原則”として紹介するようになりました。CERT版では出力対策を7番目に記載しています。IPAは順序を変えて2番目にしています。トップ10の原則とする際に順序を入れ替えるのは混乱の元です。オリジナルの順序のままにすべきだと思います。順序を変えると外国人とコミュニケーションが取れなくなります。)

よく勘違いされているので書いておきます。入力対策と出力対策は”独立したセキュリティ対策”です。間違えないようにしましょう。

入力バリデーションが第1位の対策であるのは科学的論理的原理的な理由が根拠となっています。最も重要な対策ですが、よく誤解されています

参考:

“CERT Top 10 Secure Coding Practices” の続きを読む