Pharファイルを利用したコード実行 – POP攻撃
Pharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。
PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。
もっと読む特定の処理を行うデータを渡すURLの作り方
Webアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。
例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。
もっと読むPHP 7.3
PHP 7.3が今月（2018/12）リリース予定です。新機能や機能変更は小振りですが、結構多くの追加／変更があります。ソースコード中のUPGRADINGに変更点は記載されています。ここでは独断と偏見で選んだ重要度が高い追加／変更を紹介します。 ※ PHP 7.3.0 RC6時点のUPGRADINGから紹介します。
記載していない変更の方が多いです。詳しくはリリース版のUPGRADINGを参照してください。
もっと読むPHP用のCookieセッションセーブハンドラー
JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは
- サーバー側のリソース（DBやファイルなど）を使わないので簡単にスケールする
ことにあります。
しかし、Cookieの保存は大きく分けて3つの問題があります。
- ネットワークが不安定だとデータが失われる場合がある（ネットワーク接続の問題）
- ロックがないのでデータが失われる場合がある（サーバー側の問題）
- 更新のタイミングによりデータが失われる場合がある（クライアント側の問題）
※ この問題はこのCookieを利用したセーブハンドラの問題ではなく、クッキー等のクライアント側にセッションデータを持たせるセッション管理の仕組み全般に存在します。
このハンドラーはデータ改ざんを検出するようになっており、Cookieの問題により改ざん攻撃と誤検出する可能性があります。
1、2は一般に広く認知されている問題でしょう。この場合はほぼ攻撃と誤検出されないと思われます。攻撃ではないのに攻撃と誤検出するのはほぼ3のケースだと考えられます。壊れ方によっては3ケースでも攻撃とは検出せず、仕様として単純にクッキーをリセットする場合もあります。タイミングによるデータ損失が100%攻撃と誤検出されるのではありません。
調べたのはしばらく前になりますが、タイミングによって失われるケースも完全に無視してよい程度ではありませんでした。これはブラウザのクッキー保存の実装コードの問題と考えられます。初期のバージョンはこの問題に対する緩和対策をしたコードにしていました。今は対タンパー性を上げる為にほぼ完全にバリデーションするコードになっています。（詳しくはコメント欄を参照）
どちらも一長一短で何とも言えないです。更新タイミングによるデータ損失が、どのブラウザで起きるのか、どのような使い方をすると起きるのか、どの程度あるのか、分らないので攻撃と誤検出するケースがある場合には教えていただけると助かります。※
※ 現コードはHMACで使用するクッキーをバリデーションしているので、更新タイミングによるデータ損失があると攻撃と誤検出します。きっちり正しく動作するコード ≠ きっちり厳格にバリデーションするコード、となる数少ないタイプのコードになります。ブラウザがRDBMSのトランザクションのように保存すれば済む話ですが。
もっと読む入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0
基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。
Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義すれば、アプリケーション内で繰り返し同じ入力仕様をバリデーションできるように作られています。
Validate for PHPのスクリプト版をPre Alphaとしてリリースします。このブログのGitHubリポジトリのリンクは0.7.0ブランチに向いています。開発版はmasterブランチを参照してください。
もっと読むPHP 5.6.38他で修正された任意コンテンツ送信脆弱性について
PHP 5.6.38/7.0.32/7.1.22/7.2.10でApache2handler SAPIのセキュリティバグが修正されました。
13 Sep 2018
Apache2:Fixed bug #76582 (XSS due to the header Transfer-Encoding: chunked).
http://php.net/ChangeLog-5.php#5.6.38
攻撃者が送った出鱈目な攻撃用データがPHPプログラムに関係なくブラウザに出力されてしまう問題が修正されました。
この脆弱性の影響が正しく伝わっていないようなので、簡単に紹介します。
もっと読むPHPのPharを使ったコード実行
phar（PHPプログラムを１つのアーカイブファイルにまとめて利用するファイル形式）のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。
pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。
BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。
もっと読むDrupalのwebformモジュールの更新
Drupal 8のwebfromのバージョンアップをサボっていると、バージョンアップするとパラメータのデータ型が異なる、と致命的なエラーになり動作しなくなります。
最初、エラーメッセージで検索すれば対応策が直ぐに見つかる、と思って検索しました。しかし、的確な対応方法を記載したページが検索されません。対応策は簡単です。FAQ的な情報ですが、誰かの役に立つと思うので対応策を記載します。
問題の原因はデータベーススキーマの更新です。他のデータベーススキーマ更新が必要なモジュールの場合も同様の方法で更新できるはずです。
もっと読むRisk of the session adoption
Abstract
Session management is the center of web security. However, many session management in web application/framework ignored the risk of session adoption for years. PHP 5.5.4 fixed session adoption vulnerability. This article explains the reason why session adoption fix is mandatory for secure web application.
「フェイルセーフ」とは何なのか？
「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。
フェイルセーフを一言で言うと
何かに失敗しても致命的な問題に至らないよう安全に失敗させる
これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。
フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。
となっています。
こんな単純な概念は間違いようがないでしょ？
と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。
PHPのserialize()/unserialize()を安全に利用する方法
serialize()でシリアライズしたデータを外部に送信／保存1し、それをunserialize()すると危険です。
アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わない”ことになっています。
しかし、外部データでもunserialize()を安全に利用する方法はあります。
PHPセッションとSameSiteサポート – CSRF, XSS対策
PHPのセッションID用クッキーと他のクッキー関数にSameSiteサポートが追加されます。
https://wiki.php.net/rfc/same-site-cookie
これによりクロスサイト・リクエスト・フォージェリ攻撃（CSRFやXSS）などを緩和できます。
PHPの危い関数リスト
一応、PHPの危い関数リスト、は存在します。例えば、以下のような物があります。
後者は主にホスティング環境（？）でリスクがある関数の一覧を作るプログラムのようです。
ファイルを操作する関数、コマンドやスクリプトを実行する関数などのリスクは自明だと思います。少し趣向を変え、間違えて使うと危い関数の一覧を独断と偏見で作ってみました。
【重要】こういった「危険な物」を定義するのはブラックリストです。ブラックリストは仕組的に危険です。ブラックリストに頼るのは脆弱性を作るような物です。ブラックリスト”だけ”で安心しないでください。最後にどうすれば良いのか？を書きます。
PHPでCSRF対策を自動的に行う方法
PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを１つインクルードする以外、ほとんど何も行う必要がありません。
覚えないパスワードは生成する物 〜 余計な文字数制限などは有害 〜
Webサイトにはパスワードの登録に余計な制限をかけているサイトが少なからずあります。特に最悪なのはたった20文字程度のパスワードしか許可しないサイトです。
Webサイトのパスワードは基本的には覚える必要がありません。安全性を第一に考えると十分過ぎるくらいの長さのランダムパスワードを設定する／設定できるようにすると良いです。
TL;DR;
パスワード用のランダム文字列が必要でアクセスした方は以下のURLを参照してください。生成されたランダム文字列の一部、90文字くらい、をパスワードとして使うと安全です。
パスワード用のランダム文字列生成ページ （ランダム文字列を表示します）