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

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

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

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

hash_hkdf()が脆弱なAPI仕様になってしまった主な原因は、開発者がハッシュ関数を利用して鍵を導出する場合に知っておくべきFS/PFSの概念を知らなかったことにあります。(秘密鍵のセキュリティ維持にSaltが必須であるとの理解が足りなかったことも原因)

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

もっと読む

Fedora/LinuxでZFS on Linuxを使う

Fedora(Linux)でボリューム管理、スナップショット、圧縮、RAID5以上の性能と可能性を持つファイルシステムで”安定しているファイルシステム”となるとZFSしかありません。

機能的にはBtrfsも同等の機能を持っています。しかし、少なくともこのブログを書いている時点では、RAID56はカーネルがクラッシュした場合などにファイルシステムが壊れてしまう問題があります。2017年8月に修正パッチが提案されていますが、12月現在でも運用環境では使用しないように、と注意書きがあります。

ZFS, Btrfsは両方ともデータの整合性のチェックが可能です。一般にログファイルシステムと呼ばれているファイルシステム(NTFS, XFS2, Ext4など)はディレクトリ情報などのメタデータの整合性をログで維持しています。ZFS、Btrfsはメタデータの整合性に加え、データ自体の整合性もハッシュでチェックしています。冗長性を持たせていない場合でも、HDDのセクタ不良でどのファイルが壊れたのか確実に判ります。

HDDは普通一気に使えない状態になりません。RAID1で冗長性を持たせていても、どちらかのHDDのセクタ不良の場合はどちらのデータが正しいのか?判断できません。ZFSやBtrfsなら、どちらのデータが正しいのか判断できます。

データ整合性の保証はZFS、Btrfsの大きなメリットです。

※ Fedora用に記載していますが、UbuntuやCentOSなど、他のLinuxでZFSを使う場合も基本は同じです。

もっと読む

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

追記:書き直しました。新しい方をご覧ください。

セキュアコーディングの原則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に脆弱でないか検証してから使わないとなりません。

もっと読む

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

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

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

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

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

もっと読む

実は守れていないローカルネットワーク

ファイアーウォールで守っている、プロキシも使っている、だからインターネットからローカルネットワークは守られている!

半分あたりですが、半分はずれです。よくあるネットワークシステムではローカルネットワークはインターネットから半分くらいしか守っていません。

まだ対策をしていない場合は実施することを強くお勧めします。

クロスサイト攻撃からローカルネットワークを守ることは簡単です。簡単なので会社、特にシステム開発/運用部門は必ずローカルネットワークへのクロスサイトアクセスを禁止&検出すべきです。クロスサイト攻撃とはクロスサイトスクリプティング(XSS)やクロスサイトリクエストフォージェリ(CSRF)の事です。基本的な対策ですが、意外に実施されていることが少ないようです。

クロスサイト攻撃はWebシステムに対するよくある攻撃手法です。少しの手間でインターネットからローカルネットワークに対するクロスサイト攻撃を完全に防止することが可能です。

もっと読む

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

PostgreSQL 10からICU(International Components for Unicode)のロケール/コレーションがサポートされました。

これまでサポートされてきた、libcのja_JPロケールの貧弱な日本語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日本語や他の言語での照合順序を柔軟に変更できます。

  • マトモな日本語ソート順でソートする(かなり重要)
  • 数字を後にソートする
  • 大文字を先にソートする
  • 仮名を先にソートする
  • 自然ソートする
  • これらをまとめて特別なソート順にする

といったことがPostgreSQL 10から行えます。

もっと読む

実は知られていない?リスク対策の原則?

ISO 31000(リスクマネジメント標準規格)はa)からk)まで、11のリスク管理の原則を定めています。

ITエンジニアであればISO 27000(情報セキュリティマネジメント標準規格)を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎/基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。

情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。

リスク対策の原則が知られていない?ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。

もっと読む

H29年度 岡山大学ビジネスマインドセミナー ~ 知られざる情報セキュリティの危機的状況とその対策 ~

H29年度 岡山大学ビジネスマインドセミナー 「経営者/マネージャーが知るべきセキュリティ」

ここ5年ほど(?)行っている岡山大学ビジネスマインドセミナーの講師を本年も担当しています。今年は内容を大幅に更新しています。

席数は十分にあるはずなのでconnpassでも登録できるようにしました。今週末(11月11日土曜)13:00~です。お気軽に受講ください!

セミナー内容の一部紹介

本年度のセミナー内容を少しだけ紹介します。

  • 「セキュリティ設計」を考えてみたい方
  • 現状で「安心している」方
  • 現状で「安心できない」方
  • ITシステムを提供している方
  • ITシステムを利用している方
  • エンジニア/プログラマ/マネージャーの方

お待ちしています!

私のブログを読んでいる方は技術者が多いと思うので、少し技術よりの部分を紹介します。セミナーはプログラミング知識なしで理解できる内容になっています。

一枚一枚のスライドに紹介・説明すべき内容が多すぎて書ききれません。詳しくは受講をお願いします!

4種類の信頼境界とセキュリティ構造 – 構造設計なしのセキュリティ対策?

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

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

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

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

※ 信頼境界を越えて検証されたモノ(物/人/データなど)が「全面的に信頼できると誤解される」ことがよくあります。検証されたモノであっても、検証された範囲/内容までしか信頼できません。全面的に信頼できるモノはほぼ無い、とゼロトラストで考える必要があります。

もっと読む

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

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

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

もっと読む