PDOに複文実行を禁止するオプションが追加されていた
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
突然のUnbuffered Query…PDO+MySQLで入り込んだ迷宮 - Qiita
CodeIgniterをバージョンアップしたところ、思わぬ形でPHPのバグを踏んでしまいました。 MySQLのバッファモード トラブルに見舞われるまで知らなかったのですが、PHPからMySQLを使う場合には、「バッファモード」と「非バッファモード」があります（リファレンス）。 バッファモード…SQLを発行すると、自動的にPHP側へ全データを取ってくる。デフォルト設定。 非バッファモード…SQLを発行した段階ではまだデータを取ってこない。 一見すると、非バッファモードのほうが便利そうに見えるのですが、1つ大きな問題があります。非バッファモードの場合、一度投げたクエリを始末し切るまで次のクエリが投げられないのです。もちろん、それを意識した上でPDOなりMySQLiなりを直接叩くのであればまだ使いでもあるのですが、（非バッファモードに対応しない）フレームワーク経由でDB接続するとなると、どこでク
備忘録：PDOStatement->fetch()をを2回使用する場合
ご訪問ありがとうございます。『INFINITY BLUE』は、WEB+DB開発の情報や仕事の実績などを紹介しています。 通常設定で下記のようにPDOStatement->fetch()を2回使用すると、エラーとなります。 コード： dsn = 'mysql:host=接続先;dbname=データベース名' $user = 'ユーザ名' $pass = 'パスワード' $dbh = new PDO($dsn, $user, $pass, array(PDO::ATTR_PERSISTENT => 1)); // エラーが発生した場合、PDOException を投げるように設定 $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); try { // QUERY $stmt = $dbh->prepar
ようするにMSSQLでPDOでODBCなんてしちゃいけないんだ - Life, Education, Death
まず http://bugs.php.net/bug.php?id=36561 2年くらいほって置かれているバグ。 このおかげで、PDOのメインの機能（だと思っている）プリペアドステートメントが使えないようだ。 どんなデータでも""つけて文字列として値をセットしてしまうようなエラー文に見える。 まだ状態がClosedにならないので、現在のPDO_ODBCでは解決されていなそう。 手元の環境では Message: SQLSTATE[22018]: Invalid character value for cast specification: 206 [FreeTDS][SQL Server]Operand type clash: text is incompatible with int (SQLExecute[206] at /usr/local/src/php-5.2.5/ext/pdo
PDOでの数値列の扱いにはワナがいっぱい（2） — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの18日目です。昨日は、takc923さんの「PHPのissetの罠」でした。 「PDOでの数値列の扱いにはワナがいっぱい」を書いたところ、以下のように結構反響がありました。 PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something http://t.co/kDJAWzdMqr | 先日思いっきりハマったところ。 — K.K. (@kkmym) December 16, 2013 他の方も書いてるけど、バインドで型を明示すればおｋ / “PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or somethin
PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能
基礎からのPHPという書籍を読んでおりましたら、SQLインジェクションの攻撃例として、以下のSQL文ができあがる例が紹介されていました。PHP+PDO+MySQLという組み合わせです。 SELECT * FROM tb2 WHERE ban=1;delete from tb2 2つのSQL文がセミコロンで区切って1つにまとめられていますが、これを「複文(multiple statement)」と言います。私は、SQLインジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPとMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合
PDOでの数値列の扱いにはワナがいっぱい — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの15日目です。 みなさん、史上空前のSQLのエスケープブームの中、いかがお過ごしでしょうか？ なお、「我が社のプリペアドステートメントは大丈夫なのか？」という疑問をお持ちの方には、以下の記事をお薦めします。 漢(オトコ)のコンピュータ道: SQLインジェクション対策に正解はない さて、あまりにエスケープが人気なので、プリペアドステートメントにもう少しがんばってもらいたい気がしました。そこで、今日は、以下の徳丸さんの大変に力作な記事に関連した、PDOでのプリペアドステートメントについての記事を書いてみたいと思います。 PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた | 徳丸浩の日記 一応、今でこそPDOは普通に使われていますが、細かい点までみていくと、仕様なのかバグなのか、あるいはこ
スクロール可能なカーソルとは？
What is PDO scrollable cursor? PDO の prepare メソッドのマニュアルに次のオプションが指定されているが、カーソルとは何かの説明がなかったので、検索したら stackoverflow の回答がでてきた。 $sth = $dbh->prepare($sql, [PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY]); スクロール可能なカーソルはイテレーションの巻き戻しが可能であり、同じ列に複数回アクセスできる。スクロール可能ではないカーソルはフォワードオンリーとしても知られ、列のフェッチは一度だけである。最後の列を取得すると SQLSTATE 02000 が返される。 PDO の定義済みの定数の説明では次のように書かれている。 PDO::CURSOR_FWDONLY は「前進のみ可能なカーソルを有する PDOStatemen
PDOにてMaster&Slaveのコネクションを操作するクラス(PHP)
皆様、ご無沙汰しております。笹亀です。 いよいよきたる、9/10に新しいiPhone5 S(仮名)が発表される予定ということで、iphone4を使っている自分は今回のタイミングで変更する予定なので、いまから発表が楽しみです。 さて、本日はフレームワークなどを利用している場合などであれば、あまり使用することはないですが、PDOを利用したレプリケーションしたデータベースのコネクションを切り分ける方法をご紹介したいと思います。PHPでも様々なフレームワーク（symfony,Cake,ZendFramwork）を使い開発をされるようになってきており、あまりレプリケーションの切り分けを考える必要がなくなってきておりますが、切り分けを行う方法（考え方）という視点で見ていただけますと幸いです。 ※尚、ご使用される場合は自己責任でお願い致します 概要について レプリケーションのコネクションを切り分けること
第70回PHP勉強会で浮動小数点数の話をしました - hnwの日記
7月22日に開催された第70回PHP勉強会で発表してきました。以下が発表資料です。 浮動小数点数周りのトピックを3点紹介する内容でしたが、思ったより反応が良かったように思います。 ただ、面白おかしく話そうとして、聞いている方々に無駄に恐怖を与えてしまったかもしれません。冷静に読み返していただければ、怖いように見える内容もレアケースの話題が多いことがわかるかと思います。 また、PDOの挙動については誤解を与えてしまったかと思いますので、プレゼン資料の25ページ目を大幅に差し替えてアップロードしました。 この点についてもう少し説明します。PDOでプリペアードクエリを利用する際、プレースホルダに値を埋め込むのにPDOStatement::bindValueメソッドを利用することができます。この際、bindValueメソッドの第3引数で利用でPDO::PARAM_INT定数を指定しても、第2引数の
PHP 5.5 で mysql 拡張モジュールが非推奨になり、将来において WordPress を筆頭にさまざまな CMS のアップグレード作業が必要になります
PHP 5.5 で mysql 拡張モジュールが非推奨になり、E_DEPRECATED エラーが表示されるようになりました。将来の PHP のバージョンで削除されます。 mysql 拡張モジュールに依存する CMS を使ってサイトを運用している場合、将来、運用サーバーに導入されている PHP のバージョンの切り替えに備えて、 mysqli もしくは PDO に対応した CMS のバージョンへのアップグレードするか、別の CMS やウェブサービスに切り替える必要があります。 多くの PHP 製の CMS が共有ホスティングにインストールされており、共有ホスティングは比較的古い PHP のバージョンのサポートを続ける傾向にありますが、古い PHP のバージョンを使い続ける場合、PHP のバグやセキュリティの未対応、より新しい PHP のバージョンを最小バージョンとするライブラリや CMS を導
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What is the difference between bindParam and bindValue?