PHPのmysqlndの圧縮プロトコルについてのメモ - hnwの日記
PHP+PDO+MySQLの環境では、PHP-MySQL間の通信についてzlibを使った圧縮プロトコルを利用することができます。この機能は、DBサーバのCPU利用率に十分余裕があり、かつPHP-MySQL間のネットワーク帯域が逼迫している状況で有用です。 MySQLの圧縮プロトコルとそのマニュアル PHP+MySQLの環境で、圧縮プロトコルは下記のようなコードで利用できます。 <?php $options = [ PDO::MYSQL_ATTR_COMPRESS => true ]; $db = new PDO($dsn, $user, $pass, $options); MySQLドライバとしてmysqlndを利用している場合*1、PHP 5.3.11（2012年4月リリース）以降であれば圧縮プロトコルに対応しています。このことはPHPマニュアルにも下記の通り記載があります。 PDO::
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接続するとなると、どこでク
PHP: MySQL (PDO) - Manual
はじめに PDO_MYSQL は、PHP から MySQL データベースへのアクセスを可能にするための PHP Data Objects (PDO) インターフェイス を実装したドライバです。 PDO_MYSQLは、 デフォルトでエミュレートされたプリペアドステートメントを使います。 MySQL 8 PHP 7.1.16 より前のバージョン、もしくは PHP 7.2.4 より前の 7.2系の PHP では、 MySQL 8 サーバーのデフォルトパスワードプラグインを mysql_native_password に設定するようにしてください。 さもないと、 The server requested authentication method unknown to the client [caching_sha2_password] のようなエラーを見ることになります。たとえあなたが cach
fuelphpに挑戦したところ文字化けで爆ハマり
色々なことをやりすぎてどれが根本原因だったのかわからなかったです＼(^o^)／ が、試した過程を残して大体このあたり感を出します＼(^o^)／ fuelphpは全く悪くないです＼(^o^)／ 現象：DBから取得した内容が文字化けする。 環境： fuelphp 1.7 centos 6.5 php 5.3.3 myql 5.5系 調査１：DBの文字コード設定 mysqlに接続して中の値を見ると、ちゃんと表示されていました。 よくありがちなこの時点で?になるパターンではなかったのですが、 方々を見て一部追加。 [mysqld] character-set-server = utf8 はしていた。 ※この時点でのshow variablesの結果は覚えていないです。スイマセン・・・。 追加 [mysqld] skip-character-set-client-handshake [client]
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の場合
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
第70回PHP勉強会で浮動小数点数の話をしました - hnwの日記
7月22日に開催された第70回PHP勉強会で発表してきました。以下が発表資料です。 浮動小数点数周りのトピックを3点紹介する内容でしたが、思ったより反応が良かったように思います。 ただ、面白おかしく話そうとして、聞いている方々に無駄に恐怖を与えてしまったかもしれません。冷静に読み返していただければ、怖いように見える内容もレアケースの話題が多いことがわかるかと思います。 また、PDOの挙動については誤解を与えてしまったかと思いますので、プレゼン資料の25ページ目を大幅に差し替えてアップロードしました。 この点についてもう少し説明します。PDOでプリペアードクエリを利用する際、プレースホルダに値を埋め込むのにPDOStatement::bindValueメソッドを利用することができます。この際、bindValueメソッドの第3引数で利用でPDO::PARAM_INT定数を指定しても、第2引数の
SQLインジェクション対策:偽プリペアドステートメントに注意 | beroの日記 | スラド
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 -単にプリペアドステートメントを使え -絶対に文字列結合でSQLを構築しようとしてはいけない -IPAの「安全なSQLの呼び出し方」を読むこと とあるが、 - 本物のプリペアドステートメントであることを確かめる を付け加えたい。(まあ『IPAの「安全なSQLの呼び出し方」を読むこと』を守れば、そこに書いていることではあるが) IPA本では本物のプリペアドステートメントを「静的プレースホルダ」偽物（エミュレーション）を「動的プレースホルダ」と呼んでいるが、 後者はプリペアドステートメントぽい記述をライブラリ内で文字列結合してSQLを構築している。 偽プリペアドステートメントも無意味ではない。 少なくとも自前で文字列連結するのに比べ、単純なバグやエスケープ忘れは無くなる（ことが期待できる）。 しかし文字コードの違
tenya.info
FC2ブログからMT5.2.7に引っ越す このブログも開発継続する気ないので引っ越… 開拓日誌ブログ上 me | コメント(0) Vyatta 6.6R1でやったーぶいっｖ もうルータ買わない！… 開拓日誌ブログ上 me | コメント(0) PHP 5.5の新機能 最近ぜんぜん注視してなかったけど、センス… 開拓日誌ブログ上 me | コメント(0)
MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう : DSAS開発者の部屋
「DSAS for Social を支える技術」 というネタでadvent calendar に挑戦します。 methane です。 PDOで MySQL を使うときは、みなさん $stmt = $con->prepare("..."); して $stmt->execute($values); とかしてプリペアドステートメントを利用されていると思います。 実は、このプリペアドステートメント、パフォーマンス的にはあまり良くありません。1つのクエリを実行するために、プレースホルダ付きのクエリを投げた後に、それに値をバインドして実行するコマンドを投げるので、1回のクエリを実行するのに2往復の通信が必要になるのです。 プリペアドステートメントにはパフォーマンスの利点（同じクエリを何度も発行するときにDBサーバーがクエリの解析を繰り返さないでもすむ）というものと、SQLインジェクション対策になる（正
PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり - 徳丸浩の日記(2011-03-22)
_PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり PHP5.3.6からPDO/MySQLにてデータベースの接続文字列にて文字エンコーディングが指定可能となりました。この機能を検証した結果、Linux上では正常な動作を確認しました。Windows版でも一見動作するようですが、動的プレースホルダ内部のエスケープ処理に不備があり、Shift_JISでデータベースと接続している際にSQLインジェクション脆弱性の可能性があります。 きっかけ @haruyamaさんのツイートがきっかけで、PHP5.3.6からPDOの文字エンコーディング指定が有効となったことを知りました。 PHP 5.3.6以降では PDO/MySQLのDSNでのcharset指定が有効になったようです. (MySQL 4.1.11以降, MySQL 5.0.7以降, もし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP :: Request #54638 :: PDO_MYSQL Always Uses Emulated Prepared Statements