当たり前?非常識?開発者必修のセキュリティ概念 Top 10

ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング/セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。

ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。

順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。

参考:思いの外、長くなったのでショート版を作りました。

“当たり前?非常識?開発者必修のセキュリティ概念 Top 10” の続きを読む

SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会

第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。

関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。

PDFはこちらからダウンロードできます。

 

勉強会で使ったスライドは、面白おかしく柔らかい(?)スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。

なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策

強いデータ型を持つ言語は弱いデータ型の言語(PHPやJavaScriptなど)に比べよりセキュアなのか?「なぜよりセキュアなのか?」簡単に解説します。

結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。

“なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策” の続きを読む

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

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

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

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

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

ホワイトリストの作り方

ホワイトリストの考え方/作り方は難しくありません。しかし、間違えていることが少なくないようです。

GoogleがCSP(Content Security Policy – ホワイトリスト型のJavaScriptインジェクション対策)の利用状況を調べたところ以下のような結果が得られました。

we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.

なんと、約95%のCSP利用サイトがCSPの保護が無効になるような設定になっていた、としています。

“ホワイトリストの作り方” の続きを読む

セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!

セキュアコーディング/セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。(※ 対策の目的が何か?などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません)

どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング/セキュアプログラミングのガイドラインなどがどうなっているのか?紹介します。

このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング/セキュアプログラミングとは何か?は過去のブログをご覧ください。

“セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!” の続きを読む

ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション 〜 ただし出力対策も必須です 〜

入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか?を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか?

ソフトウェア開発者が知っておくべきセキュリティの定義/標準/ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。

厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。

重要:セキュア/防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。

重要 その2:ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。

重要 その3あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を(エスケープ/API/バリデーションで)無害化するです。セキュアコーディングはISMS/PCI DSSなどの認証規格の要求事項です。

なぜこのようなブログを書いたか?というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化/防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。

参考:

“ほぼ全てのインジェクション攻撃を無効化/防止する入力バリデーション 〜 ただし出力対策も必須です 〜” の続きを読む

開発者でなくても解るセキュリティ対策 – 入力バリデーション編

ITシステムに限らずセキュリティ対策で最初に行うべき対策は境界防御(契約による設計と信頼境界線標準と基本概念開発者は必修SANS TOP 25)です。ソフトウェアにおける境界防御の第一番は入力の確認(入力の確実な制御)です。このブログでは何度も取り上げていますが、最も重要なセキュリティ対策である境界防御の概念と入力の確認が正しく認識されていない場合がよくあります。

開発者であるから「これで解るはず」と思い書いたエントリは幾つか(「合成の誤謬」の罠エンジニアに見られるセキュリティ対策理解の壁など)ありますが、どうも成功しているとは言えないようです。今回は開発者でなくても理解できるよう努力してみます。

ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

“開発者でなくても解るセキュリティ対策 – 入力バリデーション編” の続きを読む

ホスト名バリデーションのやり方

徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。

特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。

“ホスト名バリデーションのやり方” の続きを読む

SQLiteデータ型の仕様とセキュリティ問題

SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。

普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。

追記:論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析/対応できるようになります。

“SQLiteデータ型の仕様とセキュリティ問題” の続きを読む

フィルター/デコード時のセキュリティ対策の鉄則

ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 ではバリデーション時の注意点をまとめに書きました。

ホワイトリスト型のバリデーションを行う場合でも以下の項目に注意しなければなりません。

  • 特殊な意味を持つ文字を許可する場合、細心の注意を払う
  • そもそも特殊な意味を持つ文字は許可しない方が良い
  • 絶対の自信が無いのであれば、特殊な意味を持つ文字を許可してはならない

ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 でパストラバーサルを禁止するようなフィルター処理(ブラックリスト型サニタイズ処理)は基本的には行うべきではありません。しかし、どうしてのフィルター/デコード処理が必要になる場合があります。
“フィルター/デコード時のセキュリティ対策の鉄則” の続きを読む

エンジニア必須の概念 – 契約による設計と信頼境界線

少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。

契約による設計(契約プログラミング)(Design by Contract – DbC)は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
“エンジニア必須の概念 – 契約による設計と信頼境界線” の続きを読む

入力バリデーションはセキュリティ対策として*あてにする*ものではありません

ブログを書き出すと、次々に書きたくなるので困ったものです。

徳丸さんに返信した前のエントリのリンクに「もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう」とあったので補足しておきます。

そもそも入力バリデーションは「あてにする」ような物ではありません。セキュリティ対策としては「転んだ時に役立つかも知れない杖」と捉えるべきです。役立つか役立たないかは分かりませんが、SANS/CWE TOP 25で「怪物的な緩和策」(Monster Mitigation)のNo 1として挙げられているセキュリティ対策です。

つまり、毎年多数登録されるソフトウェア脆弱性データベースであるCVEデータベースのセキュリティ問題に対して、最も効果があるセキュリティ対策である、という事です。運任せでも統計的に役立つ事が実証されているセキュリティ対策を導入しないのは効果的なセキュリティ対策であるとは言えません。

入力バリデーションは「あてにする」ような物ではありませんが、セキュリティ対策として必ずやるべき対策です。運任せなので、より幸運にも脆弱性が攻撃できない状況になるよう、ホワイトリスト方式で厳格にバリデーションするのが正しいやり方です。

入力バリデーションはセキュリティ対策の基本

徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。

http://tumblr.tokumaru.org/post/55587596019

私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。

結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。

ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

参考:プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション(=セキュリティ対策)がない対策はあり得ない。

データのセキュリティ対策が無いセキュリティ対策?!

“入力バリデーションはセキュリティ対策の基本” の続きを読む

セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?

一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。

その間違いとは

  • 意図の取り違い – 誤読
  • 言語の仕様と実装の理解不足
  • HTTPやPHP仕様の理解不足
  • セキュリティ対策をすべき場所の理解不足

です。(※0)

“セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?” の続きを読む

ホワイトリストはどう作る?

まずホワイトリストの基本中の基本は”デフォルトで全て拒否するであることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません

例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1

私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力/出力の両方にホワイトリスティング対策をお勧めしています。3

“ホワイトリストはどう作る?” の続きを読む