開発者必修の7PKとは？
(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: 2018年9月13日)ISO 27000（ISMS）をはじめ、セキュアコーディング／セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1 しかし、広く使われているフレームワークでさえセキュアコーディング／セキュアプログラミングをサポートする機能が無かったり／不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも？と言えるのはセキュアコーディング／セキュアプログラミングでは枝葉末節にあたるコーディング技術（ああすべき／こうすべき）くらいではないでしょうか？ なぜセキュアコーディング／セキュアプログラミングが普及していないのか？考えられる理由を挙げます
2017年度版 OWASP TOP 10 で変るWebセキュリティのルール
(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
IoTでリクエストフォージェリが問題となる
(Last Updated On: 2018年8月4日)今後WebシステムをインターフェースとするIoTデバイスが続々と出てくると思われます。その中で特に危惧しているセキュリティ問題があります。その１つがリクエストフォージェリです。 リクエストフォージェリとは？ リクエストフォージェリと聞いてCSRF（クロスサイトリクエストフォージェリ）を思い浮かべる方はWeb開発者でしょう。リクエストフォージェリについては既にリクエストフォージェリ – SSRFとCSRFを書きました。簡単に言うとシステム／ユーザーが持っている権限を利用して不正に機能を使う攻撃です。認証／認可を正しく管理していても、システム構成やプロトコルなどによって権限を悪用できる脆弱性ががリクエストフォージェリです。 Web開発者が注意しなければならないリクエストフォージェリはCSRF（あえてクライアントサイドリクエストフォージェリ
CERT Top 10 Secure Coding Practices
(Last Updated On: 2019年1月7日)CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング（防御的プログラミング）の歴史をざっと振り返るを参照してください。 CERTはSecure Coding Standardsとして SEI CERT C Coding Standard CERT C++ Coding Standard AndroidTM Secure Coding Standard SEI CERT Oracle Coding Standard for Java SEI CERT Perl Coding Stand
セキュアなアプリ開発 – もしあなたが開発を丸投げするなら？
(Last Updated On: 2018年8月4日)もし「新規開発を丸投げしセキュアなWebアプリ開発を実現してください」と依頼されたらどうするでしょうか？開発者として開発に参加するのではなく、開発主体、つまりアプリの運営者としてして「新規開発を丸投げしセキュアなWebアプリ開発を実現すること」が目的です。開発プロジェクトのディレクションを担当し、開発は丸投げなので自分が開発に一切関わらないことが前提条件です。 セキュア開発を行うには？を考えたメモです。 選択肢 自分が開発しないアプリは信用できないのでWAFを導入する セキュアな開発が行われる要求／仕様を開発条件として付ける 1の選択肢は有り得ません。アプリ開発おけるWAFの利用は「追加のセキュリティ対策」であり、最初からWAFで防御しようと考えるのは良い選択ではないです。そもそもWAFは根本対策でない上、大抵の場合大きなコストがかか
アプリケーション仕様とセキュリティ仕様の関係
(Last Updated On: 2018年8月8日)アプリケーション（ソフトウェア）仕様とセキュリティ仕様の関係とその特徴は正しく理解しておく必要があります。この関係と仕様の特徴を正しく理解しておかないと根本的な部分での間違いにつながります。 アプリケーション仕様とセキュリティ仕様の関係は簡単です。アプリケーション仕様が優先されます。 アプリケーション仕様 ＞ セキュリティ仕様 なぜアプリケーション仕様が優先されるのか？理由は簡単です。世の中にはセキュリティ対策などどうでも良いので「とにかく速い」ソフトウェアが必要だったり、教育目的でセキュリティ対策は取り入れないで作るソフトウェアもあります。基本的には「アプリケーション仕様＞セキュリティ仕様」です。 要するに「セキュリティはどうでも良い」というアプリケーション仕様も正しい仕様として存在します。 ソフトウェアのセキュリティ仕様はアプリケ
実は標準の方が簡単で明解 – セキュリティ対策の評価方法
(Last Updated On: 2018年8月8日)なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。 以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。 @yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です — 徳丸 浩 (@ockeghem) February 6, 2015 どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。 セキュリティ対策の評価方法 – 標準編 まず
開発者は必修、CWE/SANS TOP 25の怪物的なセキュリティ対策
(Last Updated On: 2018年11月3日)SANS TOP 25 の解説はもっと後で行うつもりでした。しかし、現在のアプリケーション開発者向け教育に対する疑念のエントリへの反響が大きいようなので書くことにしました。 やるべきセキュリティ対策には優先順位があります。効果が大きい対策から行うべきです。セキュリティ対策は全体的に行うべきものですが、最も効果的な対策を除いて対策を行うようでは全体的な対策など行えません。 CWE/SANS TOP 25とは？ SANS TOP 25の正式名称はCWE/SANS TOP 25 Most Dangerous Software Errorsです。名前の通り最も危険なソフトウェア脆弱性のトップ25を挙げ、その対策を解説したセキュリティ対策のガイドラインです。SANS TOP 25は米国のセキュリティ教育・認証・研究機関であるSANSが不定期に
ニュートン力学と相対性理論 – エンジニアに見られるセキュリティ対策理解の壁
(Last Updated On: 2018年8月4日)以前からセキュリティ対策の本質や定義について何度かブログを書いたり、講演もしてきましたがなかなか理解できない方も多かったです。その構造は ニュートン力学と相対性理論の理解の壁 これと似ているのでは？と思い書き始めました。「エンジニアのセキュリティ対策理解の壁」は「ニュートン力学と相対性理論の理解の壁」と同類ではないでしょうか？ 特に入力バリデーションはセキュリティ対策の基本ではない、と勘違いしている方は続きをご覧ください。 エンジニアのセキュリティ対策理解の壁 「セキュリティ対策≒リスク削減策／排除策」と誤解している方がいます。セキュリティ対策の本質は緩和策です。「セキュリティ対策≒リスク緩和策」です。これはISOでも明確に定義されています。 以前から何度ものこのことを伝えてきましたが、なかなか理解してもらえない。その原因は基本的な論
標準と基本概念から学ぶ正しいセキュリティの基礎知識
(Last Updated On: 2018年11月6日)今回は一部の技術者が勘違いしているセキュリティ概念の話です。技術者とはWebアプリケーションのソフトウェア技術者を指していますが、他の分野の技術者にも同じ勘違いが多いかも知れません。常識であるべき知識が常識でないのが現状のようです。全ての技術者が知っておくべきセキュリティの基礎知識です。 残念ながらセキュリティ対策の定義どころか、プログラムの構造・動作原理も正しく理解されていないと言える状態です。 セキュアコーディングの構造／原理／原則 ゼロトラストとフェイルファースト ソフトウェア開発には膨大な知識が必要です。目的（ソフトウェアを作ること）以外の知識を取り入れる機会や余裕が無かった方も多いと思います。セキュリティ基礎知識を知らなかった方、安心してください！基本は簡単です。一度知ってしまえば忘れるような難しい事ではありません。勘違い
IoT時代のセキュリティ対策に必須 – ISOでも定義する入力バリデーションの方法
(Last Updated On: 2018年8月4日)項目を切り出して独立したブログエントリにしておく方が良いと思い書きました。IoT時代（IoT時代でなくてもですが）に最も必要なセキュリティ対策は厳格な入力バリデーションです。 IoTソフトウェアのバージョンアップは非常に困難、不可能である場合も多い ソフトウェアには未知の危険性が存在している セキュリティ対策としの入力バリデーションはIoTでは更に厳格に行う必要があります。 IoT時代のセキュリティ対策として入力バリデーションが強化が必要なのは、クラウドやレンタルサーバーサービスでWAFを導入する必要性が高いことと同じ理由です。これらのサービス業者はIoTと同様にソフトウェアをバージョンアップすることが非常に困難です。入力バリデーションを強化するのはソフトウェアのバージョンアップより更に困難です。このため、効率悪くや確実な防御が困難な
開発者はセキュリティ問題を自己解決できるのか？
(Last Updated On: 2018年8月4日)ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。 開発者はセキュリティ問題を自己解決できない 開発者はセキュリティ問題を自己解決できないことを前提とした場合 全ての開発者に安全な処理の基礎知識を教えるのは無理である 従って、開発者には「安全に処理する作法」を教えてそれを守らせる といった方針になります。 ”特定の処理”に関する安全性を向上させるにはこのアプローチは効果的です。開発者は何故ソフトウェアに脆弱性が発生するのか考える必要がないこともメリットです。 例えば、SQLクエリのパラメータによりSQLインジェクションを防ぐには、全てのパラメータをプリペアードクエリのパラメータとしてSQL文からデータを分離すると教えて守らせる、JavaScriptにパラ
根本的なセキュリティ対策とは？
(Last Updated On: 2018年8月4日)何年間も下書きのまま塩漬けになっていたエントリを多少修正して公開します。 プログラミングではホワイトリスティングが基本ではプログラミング/システム開発とセキュリティに対する基本的な考え方をまとめて説明していませんでした。手短にこれらの基本的な考え方・解決策を紹介します。 このエントリでは「アプリケーション開発における根本的なセキュリティ対策」を考えています。 問題を知る 多くのセキュリティ上の問題は複数のシステムがデータ交換う場合に発生します。データ交換を伴わない認証の問題、システムの安定性の問題などもセキュリティ問題です。脆弱性報告されるセキュリティ問題の8割、9割は入出力の問題です。入出力以外、つまりアプリケーションロジックの問題も重要な問題ですがこのエントリでの考察は省略します。省略はしますが紹介するセキュアな開発プロセスを実施
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
