セキュリティ対策が論理的に正しいか検証する方法

全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。

しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。

“セキュリティ対策が論理的に正しいか検証する方法” の続きを読む

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

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

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

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

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

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

アプリケーションのセキュリティと必要十分条件

セキュリティと必要十分条件については他のエントリでも書きました。以前書いたエントリではミクロの視点から単純な加算関数で考えました。今回はもう少し大きなマクロの視点、アプリケーションのセキュリティの必要十分条件を考えてみます。

論理的なセキュリティを考える為には必要なので書きました。ここに書いたことは読み物としては退屈かも知れませんが、重要な事だと考えています。

“アプリケーションのセキュリティと必要十分条件” の続きを読む

戸締りと金庫とセキュリティ

ずっと感じてきたことですが、ブログにしていませんでした。具体的には

戸締りする前に、金庫を買うセキュリティ対策

です。

IT技術者以外の方向けに書いています。最近問題だ、と話題のStruts2というソフトウェアを引き合いに書いていますが、技術的なことはほとんど書いてありません。

“戸締りと金庫とセキュリティ” の続きを読む

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

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

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

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

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

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

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

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

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

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

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

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

参考:

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

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

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

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

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

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

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

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

アプリケーション仕様?セキュリティ仕様?

アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。

セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基本概念です。

“アプリケーション仕様?セキュリティ仕様?” の続きを読む

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

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

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

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

インジェクション脆弱性の発生原理と対策 + ISO標準

インジェクション脆弱性の発生原理は簡単です。エンジニアではないマネージャー向けに作った資料を基に原理を紹介します。

インジェクション脆弱性は、その種類に関わらず原理は同じです。原理が同じということは、対策も同じです。一つ一つのインジェクション脆弱性がどのように作られ、攻撃されるのか?は少しずつ異なりますが、基本的な部分は同じです。別々に考えるより、一まとめに考えて理解した方が応用もでき、新しい仕組みなどが生まれた場合にも対応できます。

“インジェクション脆弱性の発生原理と対策 + ISO標準” の続きを読む

セキュリティ対策の目的と手段 〜 根本的誤りの元 〜

目的と手段、これを取り違えて大きな誤りを犯してしまうことはよくあります。これはセキュリティ対策に限ったことではありません。

対策をセキュリティ対策の目的と手段を取り違えると、根本的な誤りを犯してしまいます。

備考:目的と手段の取り違えが根本的な原因と言えますが、「セキュリティ対策」定義を取り違えているとこのブログの内容は理解しずらいかも知れません。セキュリティ対策に「緩和策」や「リスク増加」が含まれることを認識されていない方はまずセキュリティ対策の定義を確認ください。

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

“セキュリティ対策の目的と手段 〜 根本的誤りの元 〜” の続きを読む

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

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

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

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

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

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

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

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

参考:

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

今時の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” の続きを読む