(Last Updated On: 2019年2月17日) 徳丸さんが独自のCWE-20（≒入力バリデーション）解説を行っているので、CERT（1989年に米カーネギーメロン大学に設置された世界最古のコンピューターセキュリティ専門機関）が30年くらい前から提唱し、ISO 27000／NIST SP-800-171／PCI DSS等で要求されているCWE-20の解説を改めて書きます。 CWE-20（入力バリデーション）がなぜ重要なのか？それはCERT／MITRE／ISOが入力バリデーションをどのように解説しているかを見れば解ります。いずれも最も重要／一番最初の対策としています。（※ MITREはCWEを管理する組織で、CWEの本家と言える組織です） 徳丸さんのブログより前に、このブログでもCWE-20について以下のブログで既に書いています。CERT（≒米カーネギーメロン大学のコンピューターサ

(Last Updated On: 2019年2月5日) 7PKという用語を聞いた事がある開発者も多いと思います。7PKは業界標準のソフトウェアセキュリティ分類です。まだの方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えます。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。 ※ 7PKやCERTセキュアコーディング原則を知らなくても、セキュアなソフトウェアを作ることも可能かも知れません。しかし、それはかなり遠回りになるでしょう。 7PK 〜 Seven pernicious kingdoms: a taxonomy of softw

(Last Updated On: 2021年6月17日) CWE-20とは何か？と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か？もあまり知られていないかも知れません。 実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。 ※ CWE: Common Weakness Enumeration (共通脆弱性タイプ) CWEは脆弱性識別子のCVEで有名なMITRE（米国でのIPAの様な組織）が管理するソフトウエア脆弱性パターンを列挙したドキュメント／データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。 CWE-20の解説 – CWE/SANS Top 25 Monster Mitigation M1 実は態々私

(Last Updated On: 2022年10月1日) Attack Surface （攻撃可能面=攻撃可能な箇所）の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。 攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析（＝リスク分析）します。その上でできる限り攻撃可能な箇所を削減（＝リスク削減）します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。 Attack Surface (攻撃可能面) The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attack

(Last Updated On: 2018年8月3日)ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1 コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。 正しく動作するプログラムには正しい（妥当な）データが必須 プログラムに対するインジェクション攻撃は攻撃用の入力データが原因です。そして攻撃用入力データの大半が不正／無効なデータです。まず入力が「正しい（妥当な）データ」であることを保証する事からセキュリティ対策が始まります。そもそもプログラムは「正しい（妥当な）データ以外」では正しく動作しません。このため入力データの妥当性確認は2000年から国際ITセキュリテ

(Last Updated On: 2018年8月3日)先日、ソフトウェアセキュリティ対策が”雑”である、という話題になり「どのようなソフトウェアセキュリティ対策が”雑”なのか？」を説明しておかないとならないと感じました。 雑 ［名］いろいろなものが入りまじっていること。区別しにくい事柄を集めたもの。「雑の部」「雑収入」 ［形動］大まかで、いいかげんなさま。ていねいでないさま。粗雑。粗末。「雑な仕事」「雑に扱う」 プログラムが正しく（＝脆弱性がなく）動作するには 正しいコード 正しいデータ の両方が”必ず”必要です。このため、丁寧なソフトウェアセキュリティ対策には「コード」と「データ」の両方を丁寧に扱う必要があります。 今あるWebアプリの多くは「データ」の取り扱いが”雑”です。 “雑”なソフトウェアセキュリティの代表例 「SQLインジェクション対策にはプリペアードクエリ／プレイスホルダだ

(Last Updated On: 2018年11月15日)形式的検証とは 形式的検証（けいしきてきけんしょう）とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法や数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである 英語ではFormal Verificationとされ formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. と説明されていま

(Last Updated On: 2018年8月13日) Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。 テーマは「SQLクエリと識別子エスケープ」です。 とあるブログの結論として “「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり プリペアドクエリでSQL発行は行うこと この場合変数のバインドは必ずプレースホルダを用いること。 SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう” と書かれていました。しかし、私はこの意見に対して 実践的なSQLクエリを書いたことが全くない開発者なのでしょう？？ ソートカラム、抽出カラムを指定するSQLクエリでは「識別子（カラム名）が変数」になります。 初歩的なSQLクエリですが”自分が書いたこ

(Last Updated On: 2018年11月9日)セキュアコーディングの第1原則は「入力をバリデーションする」です。セキュアコーディングの第1原則はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。 入力バリデーションを第一のセキュリティ対策としているガイドライン： CERT Top 10 Secure Coding Practices OWASP Secure Coding ‐ Quick Reference Guide CWE/SANS Top 25 Monster Mitigations IPA セキュアプログラミング講座（NEW 2017年～） セキュアプログラミング／セキュアコーディングを要求するセキュリティ認証： ISMS – 国際情報セキュリティ標準 ISO 27000 の認証規格 PCI DSS – クレジットカード情報を取り扱う場合の認証規格 9

(Last Updated On: 2018年10月24日)まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。 なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか？ 基礎概念から間違っている例 まず最初にセキュアコーディングの考え方から間違っている例を紹介します。 このセキュアコーディングの解説をしようとしているスライドの中では、入力の信頼境界で「無害化」フィルタを使うことがわからない、としています。 入力の信頼境界で「無害化」を行う、とするセキュアコーディングはありません。もしあるとするなら、少なくともそれはISMS/ISO 27000やPCI DSSが要求するセキュアコーディングではありません。 セキュアコーディングで行う入力信頼境界のセキュリティ対策は「入力の妥当性検証」です。その結果として無害化されるパラメーターが多数生まれますが、無害化は入力妥当性

(Last Updated On: 2018年10月13日)ISO 31000（リスクマネジメント標準規格）はa)からk)まで、11のリスク管理の原則を定めています。 ITエンジニアであればISO 27000（情報セキュリティマネジメント標準規格）を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎／基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。 情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。 リスク対策の原則が知られていない？ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。 ISO 31000:2009 （JIS Q

(Last Updated On: 2018年8月13日)全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション１つとっても本当に完全であるか？検証することは容易ではありません。プログラムが本当に思っているように動作するのか？検証する研究は、まだまだ研究段階です。 しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。 論理的な正しさを検証する方法 必要十分条件を使って考えると、使わない場合に較べ誤りを少なくできます。プリペアードクエリがSQLインジェクション対策として必要十分であるか考えてみます。SQLインジェクションはSQL文に変数が含まれる”動的クエリ”の場合に発生することを頭に入れておきます。 p – プリペアードクエリを使い全てのパラメー

(Last Updated On: 2018年8月16日)ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング／セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。 ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。 順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。 参考：思いの外、長くなったのでショート版を作りました。 1. ゼロトラスト ゼロトラスト（Zero Trust）とは何も信頼しないことです。 しかし、実際には何らかの信頼がなければ効率的にシステム／ソフトウェアを作ることはできません。信頼はそこ

(Last Updated On: 2019年2月18日)'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col']) SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。 多くの場合、速い SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい 特に初心者は「ついうっかり」が多い しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。 何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけ

(Last Updated On: 2018年8月8日)広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。 MS SQL Server（TransactSQL）の場合 例えば、MS SQL Serverはリテラル（SQL文中の変数）をエスケープする関数を持っていません。このためエスケープが必要な場合、REPLACEを使い自分で”置換”してエスケープしなければならない、と公式マニュアルにも書いてあります。 Never build Transact-SQL statements directly from user input; use stored procedures to validate user input.（決してユーザー入力から直接Transact-SQL文を生成し

(Last Updated On: 2018年8月8日)Slideshareで「ネットワークから学ぶソフトウェアセキュリティの基礎」を公開しました。 ネットワークの世界で”当たり前”のセキュリティアーキテクチャーですが、残念ながらソフトウェアの世界では”当たり前”ではありません。 必要なセキュリティ対策やアーキテクチャーは状況やニーズによって変わります。セキュリティについて様々な考え方を持つことは構わないのですが、基礎中の基礎は”適用しないとしても”普遍です。

(Last Updated On: 2018年8月8日)追記： 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。 追記2：12月現在ではPDF版がリリースされています。現時点ではWebページの内容はドラフト版になっています。リリース版では「A7-Insufficient Attack Protection」は「A10-Insufficient Logging & Monitoring」になり、緩い要求事項に変更されていますが、基本的な要求事項は変わりません。マトモな入力バリデーションがないと要求されるログと監視機能を提供できません。 OWASP（Open Web Ap

(Last Updated On: 2018年10月12日)信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。 このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。 セキュアコーディングの概念は解説していません。このエントリはセキュアコーディングの概念を理解してから読まないと理解が困難かも知れません。CERTのトップ10セキュアコーディング習慣を先に

(Last Updated On: 2018年9月1日)プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか？ プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか？ サンプルコード 簡単な整数足し算を行うコード（add.php）です。 <?php // ファイル名： add.php // 整数（符号付き64bit整数）の足し算を行うプログラム // 使用例： // php add.php 123 456 // 出力： // 579 // 足し算関数 function add($x, $y) { return $x + $y; } // メインプログラム echo add($argv[1], $argv[2]); コメントから、２つの符号付き64ビット整数を引数として加算して結果を出力するプログラムだと分かります。 このコードは正しく動く

(Last Updated On: 2018年8月4日)セキュリティ対策において対策が「根本的」な対策であるかどうか？はあまり重要ではないです。セキュリティ対策において重要なのは対策が「効果的」であるかどうか、が重要だからです。 この基本を押さえた上で、ソフトウェアの「根本的な対策」とは何かを考えてみます。 セキュアプログラミング／セキュアコーディングにおける根本的対策 セキュアプログラミングの基本概念ではソフトウェアのセキュリティを大まかに 入力の対策 出力の対策 処理の対策 の3つに分けて対策します。1 セキュアプログラミングのおける根本的な対策は、この3つで行います。 入力の対策 入力の対策がなぜ根本的になるのか？ソフトウェア誤作動の原因は”悪意のある入力”または”不正な入力”があるから2 3です。問題の原因を元から断つ、は根本的な対策であることに議論の余地はありません。 強いデータ