タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

MySQLとSQLとsecurityに関するclavierのブックマーク (6)

  • SQL識別子エスケープのバグの事例

    昨日のエントリに続いてSQL識別子のエスケープの話題で、今回は著名アプリケーションにおけるSQL識別子のエスケープ処理のバグについてです。 MySQL Workbenchには識別子のエスケープに関するバグがあった 以下の画面は、MySQLが提供するMySQL Workbenchの旧バージョン(5.2.34)の様子です(CentOS6.5上で動作)。MySQL WorkbenchはWebアプリケーションではなく、下図からも分かるようにGUIツールです。 下図では a`b というテーブルの内容を表示しようとして、エラーが表示されています。 生成されているSQL文は下記の通りです。 SELECT * FROM `db`.`a`b`; これは駄目ですね。SQL識別子中に引用符がある場合は、引用符を重ねるのがルールでした。つり、正しくは以下であるべきです。 SELECT * FROM `db`.`a

    SQL識別子エスケープのバグの事例
  • 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インジェクション攻撃の文脈で複文が使える組み合わせを調べたことがあり、PHPMySQLという組み合わせでは、複文は使えないと思っていましたので、この攻撃は成立しないのではないかと思いました。 しかし、決めつけも良くないと思い手元の環境で動かしてみたところ、あっさり動くではありませんか。 PDOを用いてMySQLを呼び出す場合は複文が実行できると気づきましたが、なぜPDOの場合

  • MySQL の SQL エスケープ - tmtms のメモ

    この記事は MySQL Casual Advent Calendar 2013 の15日目の記事です。 今、空前の SQL エスケープブームみたいなので、このビッグウェーブに乗っかってみます。 でも面倒なのでセキュリティについての話はしません。カジュアル! 文字列リテラルとエスケープ MySQL では SQL 中の文字列リテラルは次のように表現します。 'abc' -- シングルクォートで括る "abc" -- ダブルクォートで括る 0x616263 -- 16進数 x'616263' -- 16進数 0b011000010110001001100011 -- 2進数 b'011000010110001001100011' -- 2進数 各表記で charset を指定することができます _utf8 'abc' _utf8 "abc" _utf8 0x616263 _utf8 x'6162

    MySQL の SQL エスケープ - tmtms のメモ
  • パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと

    ■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ

  • Mundane Life: MySQL の Prepared Statement

    Sunday, April 10, 2011 MySQL の Prepared Statement けさは、SQL インジェクションを少しだけ勉強したので、それに関して、ごく私的なメモを書き残しておこうと思う。情報処理推進機構 (IPA) の 「安全なウェブサイトの作り方」 では、SQL インジェクションの脆弱性を予防するための根的解決として、まず第一に 「SQL 文の組み立ては全てプレースホルダで実装する」(改訂第5版 p.9) と述べている。 プレースホルダーには、動的プレースホルダーと静的プレースホルダーがあって、これらについては IPA の 「安全な SQL の呼び出し方」 が詳しい。 また、最近刊行された 『体系的に学ぶ 安全な Web アプリケーションの作り方』(徳丸浩著 ソフトバンククリエイティブ ISBN978-4-7973-6119-3) にも詳しい解説が載っている。大

  • PHPでaddslashes()でエスケープしてもSQLインジェクションな穴

    ■data uri変換機 これはそそります。なるほどぉ。 data:text/html;charset=utf-8;base64,aHR0cDovL2xhLm1hLmxhL21pc2MvanMvZGF0YS5odG1s ■FirefoxでWindowsのクリップボードに値を設定する方法 上を踏まえて。 http://la.ma.la/misc/js/setclipboard_for_firefox.html http://la.ma.la/misc/js/setclipboard.txt Opera8.5でもいけてる気がします。 外部のサーバを利用せずにHTML単体でいけているのは、dataスキームが有効だからですね。IE7ではまだdataスキームって有効じゃないのでしたっけ? え?オーバーフローするかって?しないでしょ(笑) Firefoxでテキストをクリップボードにコピーする方法::最

    PHPでaddslashes()でエスケープしてもSQLインジェクションな穴
  • 1