PHPのheader関数とheaders_remove関数の注意点
PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。
PHPへのメールヘッダーインジェクション
メールヘッダーインジェクションによる攻撃は一昔前に流行った攻撃です。最近ではあまり聞きませんが、PHPのmail/mb_send_mail関数はメールヘッダーインジェクションに対して十分に安全でしょうか？
実は十分に安全と言える対策は最近になって追加しました。１つは随分前に、もう１つは最近修正しています。それらの修正を紹介します。
正規表現でのメールアドレスチェックは見直すべき – ReDoS
前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。
結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー）
追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。
PHPの制限一覧
PHPには他の言語と同様に様々な制限があります。まとまった資料が見つからなかったのでまとめておきます。PHPの制限と言っても実行時間の制限のようにマニュアルに記載されているINI設定などは記載していません。
正規表現インジェクション
一文字でも意味がある文字があるとインジェクション攻撃が可能な場合が多いです。正規表現も例外ではありません。
セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない？！
セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）
どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。
このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。
メソッド／関数呼び出しによるコード実行問題とその対策
言語の機能としてシリアライズされた”データ”からオブジェクトを生成（PHPの場合、unserialize関数）したり、呼び出すメソッド／関数を指定できる機能（PHPの場合、call_user_func関数／call_method関数など）を使ったりすると意図しないメソッド／関数が呼ばれるケースを想定しなければなりません。
ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。
厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。
重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。
重要 その2：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。
重要 その3：あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を（エスケープ／API／バリデーションで）無害化する」です。セキュアコーディングはISMS／PCI DSSなどの認証規格の要求事項です。
なぜこのようなブログを書いたか？というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化／防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。
参考：
今時のShellcodeとセキュア／防御的プログラミング
コンピュータセキュリティのことを考えるとShellcode（シェルコード）のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています
Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。
私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。
PHP7のタイプヒントの使い方
PHP7で基本的なデータ型である”int”や”float”、”array”タイプヒント（データ型のヒント）がサポートされます。使い方を間違えると思ってもいない問題が発生することがあります。しかし、正しく使えば問題ありません。タイプヒントの使い方を簡単に紹介します。
不整合が起きてはならない場合、トランザクションはシリアライザブル
リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。
もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。
PHPスクリプトファイルアップロード攻撃を防止する方法
PHPはスクリプトアップロードに弱いシステムですが、PHPアプリにはファイルアップロードをサポートしているアプリが数多くあります。WordPressなど自動更新を行うアプリも増えてきました。
PHPアプリの場合、MVCフレームワークなどを使っていてもエントリポイントにはPHPファイルが必要です。ファイルアップロードをより安全に使うための設定も可能ですが、WordPressのようなファイル配置で自動更新を行っているアプリの場合、攻撃を完全に防ぐ事ができません。
しかし、簡単な方法でドキュメントルート以下のPHPファイルの実行をホワイトリストで防御することができます。
開発者でなくても解るセキュリティ対策 – 入力バリデーション編
ITシステムに限らずセキュリティ対策で最初に行うべき対策は境界防御（契約による設計と信頼境界線、標準と基本概念、開発者は必修SANS TOP 25）です。ソフトウェアにおける境界防御の第一番は入力の確認（入力の確実な制御）です。このブログでは何度も取り上げていますが、最も重要なセキュリティ対策である境界防御の概念と入力の確認が正しく認識されていない場合がよくあります。
開発者であるから「これで解るはず」と思い書いたエントリは幾つか（「合成の誤謬」の罠、エンジニアに見られるセキュリティ対策理解の壁など）ありますが、どうも成功しているとは言えないようです。今回は開発者でなくても理解できるよう努力してみます。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
2要素認証のTOTPとHOTP、どちらがより安全か？
今すぐできる、Webサイトへの2要素認証導入では簡単に2要素認証が導入できること、2要素認証には
- 時間ベースのOTP（TOTP：Time-based One Time Password RFC 6238)
- カウンターベースのOTP（HOTP：HMAC-based One-Time Password RFC 4226）
があることを紹介しました。Google認証は両方をサポートしています。※
※ 今すぐできる、Webサイトへの2要素認証導入で紹介したライブラリはTOTPのみサポートしています。
PHP7のタイプヒントベストプラクティス
PHP 7から基本的なデータ型（整数型、浮動小数点型、配列型）タイプヒントが追加されます。直感的に書くコードと正しいコードには乖離があります。PHP7でタイプヒントを使う場合のベストプラクティスを紹介します。
タイプヒントとタイプヒントの問題点については前回のブログを参照してください。