アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。
このエントリは不定期にメンテナンスするつもりです。
タグ: セキュアコーディング
-
セキュアコーディング／セキュアプログラミングが流行らない理由
ISO 27000（ISMS）をはじめ、セキュアコーディング／セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1
しかし、広く使われているフレームワークでさえセキュアコーディング／セキュアプログラミングをサポートする機能が無かったり／不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも？と言えるのはセキュアコーディング／セキュアプログラミングでは枝葉末節にあたるコーディング技術（ああすべき／こうすべき）くらいではないでしょうか？
なぜセキュアコーディング／セキュアプログラミングが普及していないのか？考えられる理由を挙げます。
セキュアコーディング／セキュアプログラミングとは？という方は以下を参考にしてください。
-
5分で解るセキュアコーディング
セキュアコーディングで最も重要な部分を理解するのは簡単です。スライドを作ったので公開します。
https://www.slideshare.net/yohgaki/5-77628242
出力対策だけのセキュリティ対策は”誤り”です。
https://blog.ohgaki.net/reason-why-output-only-security-is-design-mistake
確証バイアスのせいか、”セキュリティ専門家”を含め、この基本原理が理解できないケースが多いです。
-
信頼境界線の引き方と防り方 – セキュリティの構造と設計
信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。
このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。
-
Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由
Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は
- HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる
という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか？気になったので調べたメモです。
コード実行ができた理由は「国際化（翻訳）用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。
-
ISO 27000の入力データ妥当性確認
セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
-
完全なSQLインジェクション対策
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
- プリペアードクエリ／プレイスホルダを使ったSQLインジェクション対策でOK
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
https://blog.ohgaki.net/output-only-security-is-anti-practice
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
-
セキュアコーディングを理解できていない例
追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。
セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。
参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。
参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。
参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。
-
セキュアプログラミング・コーディング”だけ”でセキュアなプログラムが作れない理由
記事を探すことができなかったのですが、少し前に元記事が英語で日本語訳された記事に「セキュアプログラミング・コーディングはハイプ（誇大な宣伝）である」とする記事がありました。これには全く賛同できません。
なぜセキュアプログラミング”だけ”でセキュアなプログラムが作らないのか？理由を考えてみたいと思います。
-
セキュアプログラミングの７つ習慣
セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。
ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。
-
ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単
セキュリティ問題のほとんどはインジェクション問題と考えることができます。インジェクション問題として考えられるセキュリティ問題のモデル化を考えます。
実際のセキュリティ問題は多種多様で非常に複雑ですが、シンプルなモデルで考えると理解り易く、多くのセキュリティ問題を体系的に理解できます。
-
ISO 27000とセキュアプログラミング
セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。
ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS（Information Secuirty Management System – 情報セキュリティマネジメントシステム）認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる！といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で４６４６組織の認証登録があります。
