PHPはスクリプトアップロードに弱いシステムですが、PHPアプリにはファイルアップロードをサポートしているアプリが数多くあります。WordPressなど自動更新を行うアプリも増えてきました。
PHPアプリの場合、MVCフレームワークなどを使っていてもエントリポイントにはPHPファイルが必要です。ファイルアップロードをより安全に使うための設定も可能ですが、WordPressのようなファイル配置で自動更新を行っているアプリの場合、攻撃を完全に防ぐ事ができません。
しかし、簡単な方法でドキュメントルート以下のPHPファイルの実行をホワイトリストで防御することができます。
ITシステムに限らずセキュリティ対策で最初に行うべき対策は境界防御（契約による設計と信頼境界線、標準と基本概念、開発者は必修SANS TOP 25）です。ソフトウェアにおける境界防御の第一番は入力の確認（入力の確実な制御）です。このブログでは何度も取り上げていますが、最も重要なセキュリティ対策である境界防御の概念と入力の確認が正しく認識されていない場合がよくあります。
開発者であるから「これで解るはず」と思い書いたエントリは幾つか（「合成の誤謬」の罠、エンジニアに見られるセキュリティ対策理解の壁など）ありますが、どうも成功しているとは言えないようです。今回は開発者でなくても理解できるよう努力してみます。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
今すぐできる、Webサイトへの2要素認証導入と2要素認証のTOTPとHOTP、どちらがより安全か？で紹介したGoogleAuthenticatorですが、ソースコードを確認ところタイミング攻撃に脆弱でした。Pull Requestを後で送る予定ですが、利用される場合は脆弱性を修正してから使ってください。
今すぐできる、Webサイトへの2要素認証導入では簡単に2要素認証が導入できること、2要素認証には
があることを紹介しました。Google認証は両方をサポートしています。※
※ 今すぐできる、Webサイトへの2要素認証導入で紹介したライブラリはTOTPのみサポートしています。
Google、Facebook、Amazon(AWS)、Githubなど、大手Webサービス会社が2要素認証を取り入れてしばらく経っています。自分のWebサイトでも2要素認証を導入したい！と思ったことは無いですか？
簡単に可能です！
パスワード認証だけではもう安全とは言えません。ぜひ2要素認証を自分のサービス／プロダクトに導入してください。
PHP 7から基本的なデータ型（整数型、浮動小数点型、配列型）タイプヒントが追加されます。直感的に書くコードと正しいコードには乖離があります。PHP7でタイプヒントを使う場合のベストプラクティスを紹介します。
タイプヒントとタイプヒントの問題点については前回のブログを参照してください。
PHP7からint/float/arrayの基本的データ型のタイプヒントが導入されます。タイプヒントには困った問題があります。その問題を更に複雑にするjson_decode関数のデータ型変換問題があります。
JSONデータの数値型データ※が特定の型に変換される問題はPHPのjson_decode関数に限った問題ではなく、JSONを利用する処理系を作る全ての開発者が注意すべき問題です。
※正確には数値型データと書くより「数値型リテラル」と記述するべきですが、「数値型データ」とします。
PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。
データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。
参考
アプリケーション（ソフトウェア）仕様とセキュリティ仕様の関係とその特徴は正しく理解しておく必要があります。この関係と仕様の特徴を正しく理解しておかないと根本的な部分での間違いにつながります。
以前にSQLite3のデータ型は基本的には全てテキスト（例外は整数型プライマリーキー ※）である、という解説をしました。
どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。
※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。
参考：SQLite3のカラム仕様を理解している必要があります。
Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。
Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。
なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。
以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。
@yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です
— 徳丸 浩 (@ockeghem) February 6, 2015
どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。
項目を切り出して独立したブログエントリにしておく方が良いと思い書きました。IoT時代（IoT時代でなくてもですが）に最も必要なセキュリティ対策は厳格な入力バリデーションです。
セキュリティ対策としの入力バリデーションはIoTでは更に厳格に行う必要があります。
IoT時代のセキュリティ対策として入力バリデーションが強化が必要なのは、クラウドやレンタルサーバーサービスでWAFを導入する必要性が高いことと同じ理由です。これらのサービス業者はIoTと同様にソフトウェアをバージョンアップすることが非常に困難です。入力バリデーションを強化するのはソフトウェアのバージョンアップより更に困難です。このため、効率悪くや確実な防御が困難なWAFであっても導入しているサービスが多いです。
IoTデバイスを作る場合、非常に厳格な入力バリデーションを行うべきです。
参考：Onion Omega
本来、現在のISO 27000を紹介するべきですが元のブログは敢えて古い標準を使いたかったのでISO 17799を紹介しています。基本的な部分は変わっていません。
以前からセキュリティ対策の本質や定義について何度かブログを書いたり、講演もしてきましたがなかなか理解できない方も多かったです。その構造は
ニュートン力学と相対性理論の理解の壁
これと似ているのでは？と思い書き始めました。「エンジニアのセキュリティ対策理解の壁」は「ニュートン力学と相対性理論の理解の壁」と同類ではないでしょうか？
特に入力バリデーションはセキュリティ対策の基本ではない、と勘違いしている方は続きをご覧ください。
徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。
特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。