ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29)
id:hasegawayosuke氏にそそのかされるような格好で、「はじめてのPHPプログラミング基本編5.3対応」という書籍を購入した。 本書は、ウノウ株式会社の下岡秀幸氏、中村悟氏の共著なので、現役バリバリのPHP開発者が執筆しているということ、下記のようにセキュリティのことも少しは記述されているらしいという期待から購入したものだ。 目次から抜粋引用 07-07 Webアプリケーションのセキュリティ [セキュリティ] 08-04 データベースのセキュリティ [SQLインジェクション] 09-13 セキュリティ対策 [セキュリティ] 本書をざっと眺めた印象は、「ゆるいなぁ」というものであるが、その「ゆるさ」のゆえんはおいおい報告するとして、その経過で致命的な脆弱性を発見したので報告する。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」
Matzにっき(2008-01-29): PHP使いの反論
<< 2008/01/ 1 1. 年賀状 2. ゴビウス 3. [Ruby] ZSFA -- Rails Is A Ghetto 2 1. 新年会 3 4 1. The Mythical 5% 5 6 7 8 1. [言語] Substroke Design Dump 2. [言語] A programming language cannot be better without being unintuitive 3. [OSS] McAfee throws some FUD at the GPL - The INQUIRER 9 1. [言語] Well, I'm Back: String Theory 2. [言語] StringRepresentations - The Larceny Project - Trac 10 1. [Ruby] マルチVMでRubyを並列化、サンと東大が
すごいリロード対策 - p4lifeのメモ
メモ, PHP【PHP TIPS】 58. すごいリロード対策紹介されているのはシンプルなワンタイムトークン．単純なリロード対策であれば ticket の値は乱数でなくても良い．ここを乱数にすることで CSRF 対策も兼ねている．ただこの方法は，場合によってはフォームを正常に送信できなくなってしまう問題がある． 例えば，入力画面→入力確認画面と遷移してから別のウィンドウで入力画面→入力確認画面と遷移すると，前の入力確認画面のフォームは ticket が無効になり，フォームを送信できなくなる（複数画面同時編集ができない）． 解決策としては，発行したトークンを全て記憶しておき，POST されたトークンと照合する方法がある． confirm.php session_start(); $token = sha1(uniqid(mt_rand(), true)); // トークンをセッションに追加す
ふつうのリロード対策
一般的な登録フォームの画面遷移は、 入力画面→入力確認画面→完了画面 であるかもしれないけど処理の流れとしては、 入力画面表示処理→入力確認画面表示処理→登録(メール送信)処理→完了画面表示処理 になる。 処理を分けることにより、完了画面でリロードされても、二度も登録処理が行われることはない。 個人的には、完了画面で登録(メール送信)処理を行うのは、あまり好きではない。 登録(メール送信)処理と完了画面表示処理を同一処理上で行おうとすると、面倒なリロード対策を行わなくてはいけない。 それで件のページの内容に行き着く。 すごいリロード対策 件のページの内容が『すごい』というのはCSRF(クロスサイトリクエストフォージェリ)対策を同時に行っている点でしょう。 CSRFは、通常のフローを通らずに登録処理だけを行おうとする攻撃である。コメントスパムなんかがよい例。 CSRF対策としては、『リファラ
58. すごいリロード対策
まず、日本のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
