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

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。

アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策(=リスク管理)は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。

※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的/構造的にどうすればリスクを効果的に削減できるのか?を考えると理解るはずです。

“出力対策”のみ”のセキュリティはアンチプラクティス” の続きを読む

まだ誰も知らない脆弱性/攻撃に備える方法

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ/形式は厳格にバリデーションすべきです。1

厳格なバリデーションは開発者が意識/把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。

適切なバリデーションは最強のセキュリティ対策の1つ2です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家3以外にはあまり評価されていないように感じます。

今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。

“まだ誰も知らない脆弱性/攻撃に備える方法” の続きを読む

HKDF, HMACなどのハッシュ関数を使う場合に知っておくべきFS/PFS

PHPにHKDF関数、hash_hkdf()が追加されましたが、そのシグニチャは褒められるモノではありませんでした。

出鱈目なシグニチャのhash_hkdf関数を安全に使う方法

hash_hkdf()が脆弱なAPI仕様になってしまった原因は、開発者がハッシュ関数を利用して鍵を導出する場合に知っておくべきFS/PFSの概念を知らなかったことにあります。

FS/PFSはハッシュ関数を利用した安全な鍵導出に必須の知識です。簡単な概念なので直ぐに理解できると思います。

“HKDF, HMACなどのハッシュ関数を使う場合に知っておくべきFS/PFS” の続きを読む

第一のソフトウェアセキュリティ原則さえ普及しない最大の理由とは?

セキュアコーディングの原則1は「入力バリデーション」です。セキュアコーディングの原則1はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。

入力バリデーションを第一のセキュリティ対策としているガイドライン

90年代初めから提唱された防御的プログラミングから数えると四半世紀を越える月日が経っています。

“第一のソフトウェアセキュリティ原則さえ普及しない最大の理由とは?” の続きを読む

ホワイトリスト派とブラックリスト派 〜 セキュアコーディングが行われない理由

セキュアコーディングの原則1は「信頼できない入力を全てバリデーションする」です。この原則は国際情報セキュリティ標準でも当たり前の要求事項となっています。しかし、残念ながら「信頼できない入力を全てバリデーションする」が正しく実装されているアプリケーションはほとんどありません。

独自の定義や自分勝手なセキュアコーディング解釈をしているケースが散見されます。ここでいう「セキュアコーディング」とはCERTのセキュアコーディング、ISO 27000が要求しているセキュアプログラミングを指します。

“ホワイトリスト派とブラックリスト派 〜 セキュアコーディングが行われない理由” の続きを読む

PHPとXML eXternal Entity(XXE)対策

2017年版OWASP TOP 10がリリースされました。新しくA4としてXXE、A10としてInsufficient Logging & Monitoringが入りました。今回はXXE対策を紹介ます。XXE対策は簡単です。

XXEは「リクエストのインジェクション」と考えると解りやすく、「リクエストのインジェクション」と理解すれば他の類似攻撃パターンにも応用できます。

自分で直接XMLモジュールのクラス/関数を使ってXML処理している場合は問題箇所は判り易いですが、ライブラリなどを使う場合は知らずにXXEに脆弱になりえます。外部XML文書を処理する場合、XML処理ライブラリは盲信するのではなく、XXEに脆弱でないか検証してから使わないとなりません。

“PHPとXML eXternal Entity(XXE)対策” の続きを読む

PostgreSQL 10のICUコレーションとJIS X 4061

PostgreSQL Advent Calendar 9日目用のエントリです。

PostgreSQL 10のICUコレーション(照合順序)サポートの概要と基本的な使い方は以下のエントリに記載しています。ICUコレーションの使い方は以下を参照してください。

PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる

今回は日本語ソート順のJIS規格である JIS X 4061-1996にどの程度対応しているのか確かめてみます。

“PostgreSQL 10のICUコレーションとJIS X 4061” の続きを読む

ソフトウェアセキュリティ対策の不思議 – 設計なしのセキュリティ対策

セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。

これは一般開発者の問題というより、セキュリティ専門家やセキュリティに詳しい開発者の問題でしょう。セキュリティ問題は十分に複雑な問題であることに異論はないと思います。複雑な問題を解くにはアーキテクチャー(構造化)と適切な設計が重要です。設計どころかアーキテクチャーさえないのは明らかに問題でしょう。設計となると細かな仕様が必要となります。ここではアーキテクチャーだけでも十分なのでこれだけを考慮します。

重要な事なので最初に書いておきます。セキュリティアーキテクチャー作る、は信頼境界線を書くことです。信頼境界の中に入れたモノ(入力やその他のモノ)であっても、普通は”何をしても安全なモノ”ではありません。安全性の為に更に詳細な入力検証が必要だったり、特定の権限を持つモノだけ許可したりするモノ、条件付きで信頼境界の中に入れるモノが普通にあります。また、信頼境界から出る時(出力)のセキュリティ対策は入力対策とは独立した対策です。これはよくある誤解なので注意しましょう。

信頼境界は”防衛線”です。”防衛線”での防御はITセキュリティ対策に限らず、全てのセキュリティ対策共通した防御策です。”防衛線”の”中に在るモノ”は”信頼できるモノ”であることを可能な限り保証します。”防衛線”を越えて”入るモノ”と”出るモノ”は可能な限り安全性を保証します。これが全てのセキュリティ対策共通の基本です。

 

“ソフトウェアセキュリティ対策の不思議 – 設計なしのセキュリティ対策” の続きを読む

ソフトウェアセキュリティのアンチパターン

アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。

このエントリは不定期にメンテナンスするつもりです。

“ソフトウェアセキュリティのアンチパターン” の続きを読む