PHPのHTMLエスケープ
いろいろなコンテクスト用のエスケープ方法を書いてきましたが、HTMLコンテクスト用のエスケープ方法エントリは古いままでした。今のPHPのHTMLエスケープを紹介します。
参考：他のエスケープ方法は以下のエントリを参照してください。
暗号学的ハッシュを安全に使うには？
2017年2月にGoogleがSHA1ハッシュの衝突に成功した、とアナウンスしました。1
暗号学的に安全なハッシュ関数な場合、SHA2-256を使っていると思います。SHA3が利用可能になのでSHA3を利用している場合も多いと思います。SHA2もSHA3も暗号学的ハッシュ関数です。ざっくりとこれらのハッシュ関数を安全に使う方法を紹介します。
PHPの文字マッチ性能比較
バリデーションコードを書いていると文字にマッチするパターンは結構多いです。簡単なベンチマークコードで性能を比較してみました。
出力対策”のみ”のセキュリティはアンチプラクティス
「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。
アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策（＝リスク管理）は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。
※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的／構造的にどうすればリスクを効果的に削減できるのか？を考えると理解るはずです。
まだ誰も知らない脆弱性／攻撃に備える方法
セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ／形式は厳格にバリデーションすべきです。1
厳格なバリデーションは開発者が意識／把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。
適切なバリデーションは最強のセキュリティ対策の１つ2です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家3以外にはあまり評価されていないように感じます。
今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。
HKDF, HMACなどのハッシュ関数を使う場合に知っておくべきFS/PFS
PHPにHKDF関数、hash_hkdf()が追加されましたが、そのシグニチャは褒められるモノではありません。
hash_hkdf()が脆弱なAPI仕様になってしまった主な原因は、開発者がハッシュ関数を利用して鍵を導出する場合に知っておくべきFS/PFSの概念を知らなかったことにあります。（秘密鍵のセキュリティ維持にSaltが必須であるとの理解が足りなかったことも原因）
FS/PFSはハッシュ関数を利用した安全な鍵導出に必須の知識です。簡単な概念なので直ぐに理解できると思います。
第一のソフトウェアセキュリティ原則さえ普及しない最大の理由とは？
追記：書き直しました。新しい方をご覧ください。
セキュアコーディングの原則1は「入力バリデーション」です。セキュアコーディングの原則1はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。
入力バリデーションを第一のセキュリティ対策としているガイドライン：
- CERT Top 10 Secure Coding Practices
- OWASP Secure Coding ‐ Quick Reference Guide
- CWE/SANS Top 25 Monster Mitigations
- IPA セキュアプログラミング講座（NEW 2017年～）
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に脆弱でないか検証してから使わないとなりません。
実は守れていないローカルネットワーク
ファイアーウォールで守っている、プロキシも使っている、だからインターネットからローカルネットワークは守られている！
半分あたりですが、半分はずれです。よくあるネットワークシステムではローカルネットワークはインターネットから半分くらいしか守っていません。
まだ対策をしていない場合は実施することを強くお勧めします。
クロスサイト攻撃からローカルネットワークを守ることは簡単です。簡単なので会社、特にシステム開発／運用部門は必ずローカルネットワークへのクロスサイトアクセスを禁止＆検出すべきです。クロスサイト攻撃とはクロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）の事です。基本的な対策ですが、意外に実施されていることが少ないようです。
クロスサイト攻撃はWebシステムに対するよくある攻撃手法です。少しの手間でインターネットからローカルネットワークに対するクロスサイト攻撃を完全に防止することが可能です。
実は知られていない？リスク対策の原則？
ISO 31000（リスクマネジメント標準規格）はa)からk)まで、11のリスク管理の原則を定めています。
ITエンジニアであればISO 27000（情報セキュリティマネジメント標準規格）を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎／基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。
情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。
リスク対策の原則が知られていない？ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。
4種類の信頼境界とセキュリティ構造 – 構造設計なしのセキュリティ対策？
セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。
これは一般開発者の問題というより、セキュリティ専門家やセキュリティに詳しい開発者の問題でしょう。セキュリティ問題は十分に複雑な問題であることに異論はないと思います。複雑な問題を解くにはアーキテクチャー（構造化）と適切な設計が重要です。設計どころかアーキテクチャーさえないのは明らかに問題でしょう。設計となると細かな仕様が必要となります。ここではアーキテクチャーだけでも十分なのでこれだけを考慮します。
重要な事なので最初に書いておきます。セキュリティアーキテクチャー作る、は信頼境界線を書くことです。信頼境界の中に入れたモノ（入力やその他のモノ）であっても、普通は”何をしても安全なモノ”ではありません。安全性の為に更に詳細な入力検証が必要だったり、特定の権限を持つモノだけ許可したりするモノ、条件付きで信頼境界の中に入れるモノが普通にあります。また、信頼境界から出る時（出力）のセキュリティ対策は入力対策とは独立した対策です。これはよくある誤解なので注意しましょう。
信頼境界は”防衛線”です。”防衛線”での防御はITセキュリティ対策に限らず、全てのセキュリティ対策共通した防御策です。”防衛線”の”中に在るモノ”は”信頼できるモノ”であることを可能な限り保証します。”防衛線”を越えて”入るモノ”と”出るモノ”は可能な限り安全性を保証します。これが全てのセキュリティ対策共通の基本です。
※ 信頼境界を越えて検証されたモノ（物／人／データなど）が「全面的に信頼できると誤解される」ことがよくあります。検証されたモノであっても、検証された範囲／内容までしか信頼できません。全面的に信頼できるモノはほぼ無い、とゼロトラストで考える必要があります。
ソフトウェアセキュリティのアンチパターン
アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。
このエントリは不定期にメンテナンスするつもりです。
ゼロトラストをより細かく分解する
セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。
※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。
なぜセキュアなシステムが作れないのか？
なぜセキュアなシステムが作れないのか？この問いは
なぜバグフリーのシステムが作れないのか？1
と同類の問いです。一定規模を超えると完全にバグ／問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ／問題がないシステムは簡単には作れません。しかし、バグ／問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。
このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。
ポイントは
- 構造化が大事
- 基礎が大事
- 目的が大事
です。