Phalcon 1.3 と 2.0のベンチマーク
Phalcon Adventカレンダー15日目のエントリです。Phalcon 1.3と2.0でどの程度性能差があるか簡単なベンチマークを取ってみました。
Phalcon Adventカレンダー15日目のエントリです。Phalcon 1.3と2.0でどの程度性能差があるか簡単なベンチマークを取ってみました。
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。
安全なAPI過信症候群(同類にプリペアードクエリ過信症候群など):「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。
このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。
現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。
このエントリはPhalcon PHP Advent Calendar 2014 4日目のエントリです。2日目としてPhalcon 1.xのRPMパッケージを作っています。今回はPhalcon2のRPMパッケージをphp-phalcon2.xパッケージとして作ります。多分動くと思いますが、ほとんどテストしていないので問題があったらコメントをお願いします。
php-phalconとphp-phalcon2パッケージは同時にインストールできないので注意してください。
最近、ファイルアップロード/ダウンロード対策に関する検索が増えているようなので書きました。PHPの場合、スクリプトがアップロードされ実行されてしまうと致命的です。アップロードされたファイルを公開ディレクトリに保存することは好ましくありあせん。しかし、既にそうなっているアプリケーションの場合、改修が困難な時もあります。このような場合もより安全に利用できる設定を紹介します。
参考:「スクリプトアップロード対策」も合わせてどうぞ。
PHP最速フレームワークのPhalconですが、RPMパッケージを使ったシステムへのインストールは最速ではありません。Ubuntuの場合、パッケージがあってapt-getで一発インストールできるのですが、デフォルト/EPELリポジトリにはRHEL/CentOS/Fedora用のRPMパッケージはありません。そこでPhalconのRPMパッケージを自分で作る手順を紹介します。
このエントリはPhalcon PHP Advent Calendar 2014 2日目のエントリです。
追記:SRPMファイルのダウンロードリンクを忘れていました。次のURLでダウンロードできます。
私が普段使っている環境はビルドツールが全て揃っています。もし依存性(BuildRequires、Requires)などが足りなかったら教えてください :)
password_hash関数はcrypt関数のラッパーです。パスワードを簡単かつ安全にハッシュ化するための関数です。現在のPHPマニュアルにはpassword_hash関数の重要な制限が未記載であったため追加しました。 もっと読む
今時、ファイルアップロードに脆弱であることは珍しいので WordPress MailPoet (wysija-newsletters) Unauthenticated file Upload として知られている脆弱性を調べてみました。 もっと読む
モジュールにパッチを当てていたことを忘れてVmware Workstation 9をバージョンアップしてしまいました。当然ですがモジュールがビルドできないので使えない状態になってしまいました。現在、利用しているVmware Workstation 9用のパッチは検索しても簡単には見つからないようなので、手元に残っていたモジュールソースのアーカイブを利用して使えるようにしました。
かなり無責任なエントリですが、Linux 3.14カーネルとVmware Workstationを利用されている方なら参考にはなると思います。また忘れそうなので自分用のメモです。
数年ぶりにLinuxをインストールしているメインPCにしているPCのマザーボードを交換、同時にCPU、メモリ、ディスクも新しい物にしました。近々このマザーボードは別のマザーボードに交換すると思います。SSDも交換するかも知れません。Linuxユーザーの為に情報を共有したいと思います。
Linuxは大抵の環境で動作しますが、まだまだいろいろある、という話です。
詳細な調査を行ったのではありません。取り敢えず自分が使う環境を整備する為に試した時のメモ程度だと理解してください。コメント歓迎します。
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
以前にJavaScript文字列のエスケープ関数を紹介しました。試しにPhalconのZephirで書いてみました。
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われる物のみをピックアップしました。
ここ数年だけでもSSLに対する攻撃方法やバグが何度も見つかっています。SSLで通信を暗号化していてもパスワード認証時のトラフィックを解読されてしまえば、パスワードが漏洩していまいます。パスワードが判ってしまえば、攻撃者は何度でも被害者のアカウントを利用できます。
脆弱性でなくても、SSLも無効化したMITM(中間者攻撃)も可能です。SSLだから安心、とは考えられません。これを何とかできないか、考えてみます。
参考:
Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。
この仕様の違いはデータのバリデーションに大きく影響します。
参考: PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。