Programming – ページ 7 – yohgaki's blog

Computer, Development, PHP Security, Programming, Secure Coding

セキュリティの原理、原則、ベストプラクティス

3月 15, 2018 #アンチプラクティス, #セキュアコーディング論理, #ベストプラクティス投稿者 yohgaki

「セキュリティの」と付けていますが、どの分野でも共通することだと思います。

何事でも論理的に何かのガイドライン／ルールを作る場合、まず変えることのできない

原理 – 事物・事象が依拠する根本法則

を見つけ、その原理から導き出される

原則 – 多くの場合に共通に適用される基本的なきまり・法則

を作り、さらに特定の条件下の具体的な事例として

ベストプラクティス – 最良の実践法。最善の方法。

を作ります。原理、原則、ベストプラクティスを理解していないと様々な問題がおきます。これらの基本的関係は

原理＞原則＞ベストプラクティス

です。しかし、適用範囲の広さは

原理＜原則＜　ベストプラクティス

です。例えば、ベストプラクティスは”例外的”に原則に反した方法が”最善の方法”となる場合も少なくないからです。よく混乱や誤解の元になりますが、条件を絞った場合（例外的なケース）のベストプラクティスも在ります。

例外的なケース（一般的で無いモノ=例外的な物）をベストプラクティスにすることには異論もありますが、結構狭い条件でしかベストプラクティスにならないモノが”ベストプラクティス”と呼ばれていることは多いです。¹

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding, Security

ソフトウェアはセキュリティの原理・原則から間違っている「入り口ノーガード設計」のままで良いのか？

3月 14, 2018 #アンチプラクティス, #セキュアコーディング, #リスク分析, #リスク管理投稿者 yohgaki

現在のWebアプリケーションのほとんどは「入り口対策」がない「入り口ノーガード設計」です。

※ アプリケーションの入力処理、つまりMVCアーキテクチャーならコントローラーレベルで「入り口対策」がない設計が「入り口ノーガード設計」です。

このような設計になっているので、本来は自然数だけのハズのHTTPヘッダーのContent-Length（やContent-Type／Content-Disposition）にプログラムが書けてしまったStruts2 Webアプリにより国内ではクレジットカード情報が何十万件も盗まれる、米国では1億4千万件以上の信用情報が漏洩する、といった事件が発生しています。

幸い、「入り口対策」がない「入り口ノーガード設計」でもこういった大規模インシデントになるような脆弱性の攻撃は多くありません。しかし、話題にならないだけで多数のインシデントが世界中で発生していると考えられます。

先の事例はStruts2／フレームワークのセキュリティ問題、と捉えられていることが多いと思います。しかし、これは本質的にセキュリティ原則を無視した「入り口ノーガード設計」の問題です。

コード検査していると「入り口対策」をしていて、本当に良かったですね！というケースに出会うことが少なくありません。

2018年5月からEUでGDPRが施行されます。GDPR違反となると2000万ユーロまたは全世界売上の4％のどちらか高い方が罰金（組織によっては1000万ユーロまたは全世界売上の2％）となります。GDPRには様々な要件が要求されていますが、国際情報セキュリティ標準であるISO 27000で”普及している”とされた”セキュアプログラミング技術”の原則さえ採用しないシステムで個人情報漏洩が起きた場合の被害は、簡単に会社を潰すレベルの損害になる可能性があります。

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

出力対策の3原則 + 1原則

3月 11, 2018 #エスケープ, #セキュアコーディング技術, #セキュアコーディング論理, #ベストプラクティス, #入力バリデーション投稿者 yohgaki

ソフトウェアの不具合／脆弱性を無くすためには、出力先に対して無害であることを保障する出力対策が重要です。どんな出力でも3つの方法で無害化できます。

このブログでは基本として、セキュアコーディングの概念に基き説明しています。先ずはよくある入力対策と出力対策の区別がついていない誤りから紹介します。

参考：IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding, Security

バリデーションには3種類のバリデーションがある〜セキュアなアプリケーションの構造〜

3月 7, 2018 #セキュアコーディング技術, #セキュリティ構造, #ベストプラクティス, #リスク管理, #入力バリデーション投稿者 yohgaki

バリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。

バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に

バリデーションはモデルで集中的に行うべきだ！
なのでコントローラー（入力）でバリデーションなんて必要ない！
モデル集中型バリデーション以外の方法／場所でバリデーションするのは非効率で馬鹿馬鹿しい考えだ！

があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。¹

実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故？と思った方はぜひ読み進めてください。

流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます（ました）

入力データはバリデーションはできない！
どんな入力でもWebアプリは受け付けて”適切”に処理しなければならない！
入力バリデーションにホワイトリスト型は無理、適用できない！
ブラックリスト型とホワイトリスト型のバリデーションは等しいセキュリティ対策！
入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない！
脆弱性発生箇所を直接または近い個所で対策するのが本物のセキュリティ対策である！

全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない！」とする考え方の問題点は”セキュリティ対策の定義” ² を理解していないと問題点は見えないかも知れません。

セキュリティ対策（＝リスク管理）とはリスクを変化させる全ての施策で、多くの場合はリスクを廃除／軽減させる施策だが、それに限らない。

このセキュリティ対策の定義はISO 27000／ISMSの定義をまとめたモノです。

TL;DR;

何事も原理と基本が大切です。基礎的な事ですがプログラムの基本構造と動作原理を正しく理解しておく必要があります。

セキュアコーディングの構造／原理／原則

入力対策と出力対策は両方必要でバリデーションはセキュアなソフトウェア構築には欠かせません。

原理1：コンピュータープログラムは「妥当なデータ」以外では正しく動作できない
原理2： 何処かでエラーになるから、ではセキュアにならない（遅すぎるエラーはNG）

アプリケーションの入り口で入力バリデーション（入力検証）をしていないアプリはセキュアでない構造です。

入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化（エスケープ／無害化API／バリデーション）が必須です。

プログラムは妥当なデータでしか正しく動作できない。入力バリデーションは原理的に必須。
出力対策は必須の物とフェイルセーフ対策の物がある。フェイルセーフ対策の場合は下層の多層防御です。そもそも”データが妥当でない場合”（＝フェイルセーフ対策）のエラーは起きてはならない。当然ですが出鱈目なデータを処理するのもNG。

多層防御 ³ は重要なのに勘違いされているソフトウェアセキュリティ要素の１つです。

バリデーションには3つの種類があります。

入力バリデーション – 正しく動作する為に必須（主に形式検証）
ロジックバリデーション – 正しく動作する為に必須（主に論理検証）
出力バリデーション – 大半が上の2つに失敗した場合のフェイルセーフ対策（追加の対策 – 安全な特定形式のみ許可の場合）

※ 出力時のエスケープ／エスケープが不必要なAPIの利用によるデータの無害化は、必須の対策が半分、フェイルセーフ対策が半分です。

※ “入力ミスの確認”を”バリデーション”と考えたり、言ったりすると混乱の元です。”入力ミス／論理的整合性の確認エラー”は処理の継続、”あり得ないデータによるバリデーションエラー”では処理の中止、が必要なので区別する方が良いです。

※ ソフトウェア基本構造の入力処理では”あり得ないデータによるバリデーションエラー”、ロジック処理では”入力ミス／論理的整合性の確認エラー”、になります。

※ リスク分析の経験があれば自然にセキュアな構造を思い付くことも可能だと思います。

リスク分析とリスク対応をしよう

イメージ図：

参考：データもコードも一文字でも間違い／不正があるのはNG

https://blog.ohgaki.net/programs-cannot-work-correctly-one-char-is-enough

もっと読む

1
PHP開発者MLで議論したのですが、紹介したような議論をした方が少なからず居ました。少し続くとすかさず「そもそもActiveRecordパターンでないモデルも多数あるし、ActiveRecordパターンのモデルだけのバリデーションだと遅すぎ、その間に実行させる機能が悪用されるケースは山程あって、しかもそれが奥深いライブラリのどこで起きるか分らんだろ」的なツッコミがあるところは日本での議論とは異なった点です。
2
セキュリティ対策＝リスク管理、にはリスクを増加させる施策も含め、定期的にレビューしなければならないです。（ISO 27000／ISMSの要求事項）リスクを増加させる施策、例えば認証にパスワードを利用など、は定期的にレビューしその時々の状況に合ったリスク廃除／軽減策をタイムリーに導入しなければならない。リスク増加要因を管理しないセキュリティ対策＝リスク管理は”欠陥のある管理方法”です。
3
ソフトウェアに限らずセキュリティは多層で防御します。必ず必要な対策と無くても大丈夫なハズの対策（フェイルセーフ対策）の2種類がある。フェイルセーフ対策は万が一の対策であり、本来フェイルセーフ対策は動作してはならない。動作した場合はプログラムに問題がある。「動作してはならない」は「必要ない」ではない。実用的なプログラムは複雑であり失敗してしまうケースは十分にある。入力バリデーションが甘い／無いプログラムだとフェイルセーフ対策が機能してしまうことは当たり前に起きる。

Computer, PHP Security, Programming, Secure Coding

PHPのHTMLエスケープ

3月 3, 2018 #JavaScriptインジェクション, #PHP, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

いろいろなコンテクスト用のエスケープ方法を書いてきましたが、HTMLコンテクスト用のエスケープ方法エントリは古いままでした。今のPHPのHTMLエスケープを紹介します。

参考：他のエスケープ方法は以下のエントリを参照してください。

PHP文字列のエスケープ

もっと読む

Computer, PHP Security, Programming

PHPの文字マッチ性能比較

2月 13, 2018 #PHP, #ベンチマーク投稿者 yohgaki

バリデーションコードを書いていると文字にマッチするパターンは結構多いです。簡単なベンチマークコードで性能を比較してみました。

もっと読む

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

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

2月 8, 2018 #アンチプラクティス, #セキュアコーディング, #セキュリティ構造, #リスク分析, #リスク管理投稿者 yohgaki

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

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

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

もっと読む

Computer, Development, PHP Security, Programming, Security

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

2月 6, 2018 #セキュアコーディング論理, #セキュリティ構造, #入力バリデーション, #脆弱性投稿者 yohgaki

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

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

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

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

もっと読む

Computer, Development, PHP Security, Programming, Security

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

1月 24, 2018 #PHP, #セキュアコーディング技術, #暗号投稿者 yohgaki

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

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

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

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

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding, Security

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

12月 20, 2017 #セキュアコーディング, #セキュリティ標準, #入力バリデーション投稿者 yohgaki

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

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

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

90年代初めからコンピューターサイエンティストのセキュリティ専門家は「入力バリデーション」を重要であるとしてきました。「入力バリデーション」は論理的にセキュアな構造のソフトウェアを作る為に欠かせない必須の要素だからです。防御的プログラミングから数えると四半世紀を越える月日が経っています。

もっと読む

Computer, Development, PHP Security, Programming, Security

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

12月 18, 2017 #アンチプラクティス, #セキュアコーディング投稿者 yohgaki

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

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

もっと読む

Computer, Development, PHP Security, Programming, Security

PHPとXML eXternal Entity（XXE）対策

12月 12, 2017 #PHP, #XXE, #セキュアコーディング技術投稿者 yohgaki

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

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

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

もっと読む

Computer, Database, Programming

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

12月 9, 2017 #PostgreSQL, #文字エンコーディング投稿者 yohgaki

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

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

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

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

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

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

11月 13, 2017 #アンチプラクティス, #セキュアコーディング論理, #セキュリティ標準, #ベストプラクティス, #リスク分析, #リスク管理, #入力バリデーション投稿者 yohgaki

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

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

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

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

もっと読む

Computer, Development, PHP Security, Programming, Security

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

10月 23, 2017 #セキュアコーディング論理, #セキュリティ構造投稿者 yohgaki

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

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

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

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

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

もっと読む