Security – ページ 4 – yohgaki's blog

Computer, Development, PHP Security, Secure Coding, Security

Computer Programming Fundamentals and Principles – Input Validation

3月 28, 2018 #In English, #セキュアコーディング, #入力バリデーション投稿者 yohgaki

I had discussion on PHP dev mailing list. It appeared that not few developers misunderstand “What is Input Validations“. Therefore, I summarize computer programming fundamentals and basics to help understanding validations.

Without fundamentals and basics understanding, discussion is meaningless. “Input Validation” is one of the most important countermeasure for cyber attacks. The idea is strongly supported by notable computer scientists (e.g. CMU’s CERT) and security specialists, yet it is misunderstood by majority of developers. Therefore, almost all web applications are missed to have proper “Input Validation” currently.

I came across this discussion too often, so I summarize why, “Input Validation”, “Input Data Validation” or “Application Input Data Validation” especially, is fundamental and mandatory requirement for applications.

TL;DR;

“Application Input Data Validation” and “Business Logic Validation” are 2 different validations by fundamentals and principles. Except few exceptions, ALL web application input data can be validated by “Application Input Data Validation” without user interactions. This achieves more secure state and cleaner/manageable code structure. Thus, applications should implement “Application Input Data Validation” always.

Note: “Application Input Data Validation” is NOT a replacement of “Business Logic Validation”.

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

「脆弱性を局所的に潰す」はアンチプラクティス

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

本物の「セキュアコーディング」（セキュアプログラミング）を知ればもう議論など必要ない、と思っています。本物の「セキュアコーディング」を「知ろうとしない」と幾らでもアンチプラクティスを作ってしまいます。

議論は終り、と思っていたのですがそうも行かないようなので紹介します。セキュアコーディングの概念を全く知ろうとしないで、セキュリティを作るのは「ただの無駄」です。多数のアンチプラクティス／間違いが含まれるスライドの中から（一々指摘するとキリがない）

「脆弱性を局所的に潰す」

これ”だけ”だとアンチプラクティスです。

※ 契約プログラミングが流行らない理由はこいうアンチプラクティスも原因でしょう。特定の良いこと”だけ”を積み重ねても良い結果にならない、ことは合成の誤謬として知られています。

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

バリデーションですべきこと

3月 21, 2018 #セキュアコーディング技術, #入力バリデーション投稿者 yohgaki

このブログは、IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき、の「追加の情報」として書いた物を別エントリとしてまとめた物です。

CERTセキュアコーディングは

入力バリデーション（原則1）
”セキュアコーディング標準”による安全なロジック処理（+具体的な入力／出力処理）※ 原則10 「セキュアコーディング標準を採用する」＝自ら作るモノ
出力の無害化（原則7）※ IPA版は原則2

の3つが１つのセットとして成り立ちます。これ以外はセキュアコーディングではありません。

入力、ロジック、出力、これら全てにバリデーションが必要です。

参考：コンピュータは数値さえ正確に扱えない

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

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

3月 21, 2018 #アンチプラクティス, #セキュアコーディング, #セキュリティ標準投稿者 yohgaki

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

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

セキュアプログラミング／セキュアコーディングを要求するセキュリティ認証：

ISMS – 国際情報セキュリティ標準 ISO 27000 の認証規格
PCI DSS – クレジットカード情報を取り扱う場合の認証規格

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

しかし、残念ながらセキュアコーディングの第1原則の「入力バリデーション」は普及しているとは全く言えません。この状況には理由があります。

この状況に責任があるIPAは、IPAのセキュアプログラミング講座 ¹に基礎的な誤りがあったことを明示し、開発者に与えた誤解が正されるよう、最大限の努力をすべきでしょう。

IPAのあり得ないような基礎的誤りがどのような物だったか、ご覧ください。

追記： IPAは問題のページを更新／削除したようです。

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

プログラムから「想定外」を無くす方法

3月 17, 2018 #セキュリティ構造投稿者 yohgaki

ほとんどセキュリティ問題は「想定外の動作」が原因です。例えば、インジェクション攻撃は開発者にとって「想定外の動作」でしょう。ソフトウェア開発者が意図しない想定外の動作のほとんどは「想定外のデータ」が原因です。

この事実をから簡単に分かる「想定外」を無くす方法があります。たった2つの方法を”両方”行うだけで、現在あるアプリの9割程度の脆弱性が無くなります。

今まで出来る限り正確に「どうすれば想定外をなくせるか？」を紹介してきましたが、今回は出来る限り簡潔にどうすると良いのか、ダメなのか紹介したいと思います。もっと読む

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, 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, Development, PHP Security, Security

数値のバリデーションは無意味なのか？

3月 5, 2018 #セキュアコーディング技術, #入力バリデーション投稿者 yohgaki

数値の入力にはバリデーションは要らない、と考えているケースが少なからずあるようです。本当に数値に対するバリデーションは無意味なのでしょうか？

Computer, Development, PHP Security, Security

「出力対策だけのセキュリティ設計」が誤りである理由

3月 3, 2018 #セキュアコーディング論理, #セキュリティ構造, #リスク分析, #リスク管理, #出力対策投稿者 yohgaki

まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。

なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか？

Computer, PHP Security, Security

暗号学的ハッシュを安全に使うには？

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

2017年2月にGoogleがSHA1ハッシュの衝突に成功した、とアナウンスしました。¹

暗号学的に安全なハッシュ関数な場合、SHA2-256を使っていると思います。SHA3が利用可能になのでSHA3を利用している場合も多いと思います。SHA2もSHA3も暗号学的ハッシュ関数です。ざっくりとこれらのハッシュ関数を安全に使う方法を紹介します。

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