SQLインジェクションとは何か？その正体とクラッキング対策。
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
union allがデフォルト。unionは特殊な場合のみ使う - 極北データモデリング
重複行を削りたいならunionを使う。重複行を生かしたいならunion allを使う。 ここまではよいとして、どっちでもよい場合、例えば 重複行があり得ない場合 IN句のサブクエリなので重複行があってもなくても結果に影響しない場合 にどうするか。 以前はunionをデフォルトにして、重複行を生かしたいときだけunion allしていたが、今は逆に、union allをデフォルトにして重複行を削りたいときだけunionする、という方針にしている。理由はいくつかあるが、allを付けると Sort->Unique の処理が走らないのでパフォーマンス上有利になるはず、というのが大きい。 絶対に重複行が発生しないことが分かっているクエリでも、unionを使うとSort->Uniqueの処理が走ってしまうDBMSは多い。 例えばPostgreSQL： UNION bench=# explain ana
日常用語でnullを理解する(2) - 極北データモデリング
SQLにおけるnullは「値があることは分かっているが、それが何なのかはわからない」という意味だ。 「値がない」という意味ではない、ということに注意しなくてはならない。 nullは「値がない」ではない nullを「値がない」という意味だと考えてしまうと、 'a'と'b'とnullを連結した結果が、nullになる 1 + nullがnullになる といったSQLの挙動の意味が理解できなくなる。 nullが「値がない」という意味なら select 'a' || 'b' || null の結果には少なくとも'ab'が含まれているはずあって、「値なし」になってしまうのはおかしい。 また select 1 + null の結果が「値なし」になってしまうのも何だかよくわからない。 つまりSQLは、nullを「値がない」という意味のものとしては扱わない。 が、「値がない(まだない or あり得ない)」と
SQLインジェクション攻撃はDB上の任意データを盗み出す - ockeghem's blog
前回に引き続き、Think IT上の連載「SQLインジェクション大全」の第4回：ケース別、攻撃の手口を読んで感じたことを書きたい。 まず、この記事は以下のような書き出しから始まっている。 本記事は、システムを防御するにはまず敵を知らなければならない、という意図の下に、攻撃手法を紹介する。 dfltweb1.onamae.com – このドメインはお名前.comで取得されています。 この趣旨に異論があるわけではないが、しかしこの表現は誤解を生みやすいものだと思う。 というのは、「敵」(攻撃方法)を知ったからと言って、防御の方法が導き出せる訳ではないからだ。例えば、開発者が「最近のSQLインジェクションの自動化攻撃にはT-SQLのDECLARE文が用いられる」という情報を得て独自に対策を考えた場合、DECLAREという単語をチェックしてエラーにしたり、単語を削除することを考えがちだと思う。現に
結合方式とインデックスの関係 - 極北データモデリング
ネスト化ループ結合/マージ結合/ハッシュ結合は、それぞれインデックスをどのように使うのか、を整理する。 マスタのｘｘコードとトランザクションの同名の列を等結合にするSQLについて、 インデックスが片側(マスタ側のみ) インデックスが両側 インデックスなし の3条件で、各結合方式の実行速度を計測してみる。 テスト内容 PostgreSQL8.3.5で以下のSQLを実行する。 explain analyze select * from tellers t -- 1000件のマスタ inner join history h on h.tid=t.tid -- 1000万件のトランザクション結合方式は以下の手順で制御する。 ふつうに実行すると、プランナはハッシュ結合を選択する。 set enable_hashjoin to off を実行すると、プランナはマージ結合を選択する。 さらに set e
select * は禁じ手で、必ず列名を列挙すべしとされている理由 - 極北データモデリング
select * from ... と書いてはダメ、たとえ全列取得する場合でも select a, b, c, d from ... と書くのが常識、という話をずいぶん前に聞いたことがあって、意味がわからないので人力検索に投げてみた。 いただいた回答を整理しておく。 テーブル内の一部の列を参照したい場合 例えばクライアント側では1列しか見ないのにワイルドカードで全列取得することには、パフォーマンス上の問題がある。 select * from ... でも select a from ... でもディスクI/Oのコストは基本的に変わらないが*1、それ以外のところに問題がある。 ネットワークの問題。DBサーバからクライアントに転送するデータが無駄に大きくなる メモリの問題。DBMSのデータキャッシュやOSのファイルキャッシュが無駄遣いされる テーブルの全ての列を参照したい場合 全列取得したい場
INをEXISTSに書き換えると速くなるサンプルSQLを作るのは難しい - 極北データモデリング
「INをEXISTSに書き換えると速くなる」という話が、DBMSやそのバージョンを限定せずにSQL一般の話として語られることがあるけど、実感としてそれはないだろうと。 そこでどういう場合に速くなるのか確認しようと思ったけどうまくいかなかったので、どういう場合に速くならないかを書いてみます。 速くならない(1) - 同一の実行計画になる SQL Server 2005で以下のSQLを流すと、IN/EXISTSで同一の実行計画が出てきた。 IN select count(*) from 受注 t where 商品CD in (select 商品CD from 商品) EXISTS select count(*) from 受注 t where exists (select * from 商品 where 商品CD=t.商品CD) 実行計画 |--Compute Scalar(DEFINE:([
JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5（通貨記号としての￥）が、他の文字コードに変換される際にバックスラッシュ「\」（日本語環境では通貨記号）の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL
【YQL 速攻レビュー】米 Yahoo! が SQL っぽく色んなデータを取ってこれるAPIを出した - てっく煮ブログ
米 Yahoo! が Yahoo! Pipes みたいに自由度が高くて、またちょっと毛色が違うサービスが出てきた。題して、Yahoo! Query Language。YQL と呼ぶようだ。SQL 風の言語を REST で投げて、結果を XML や JSON で受け取ることができる。具体的にやってみないと分かりにくいので、とりあえず試してみた。RSS からデータ取得YQL を使って RSS から最新のタイトル10個を取ってきてみる。こんな YQL になるらしい。 select title from rss where url='http://d.hatena.ne.jp/nitoyon/rss' rss テーブルに対して select を発行している。実際にこの YQL を試すには YQL 用の console を利用するとよい。（※要ログイン）console の左上に YQL を入力して
「RDBMSの時代の終わりが見えてきた」についてそろそろ一言言っておくか - ひがやすを技術ブログ
2008-12-12 いくつか誤解を生みそうな表現があるので、それをまずは指摘しましょう。 プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。ORマッピングがそれです。 これが、意図的かはわからないけど、ミスリードを生んでいます。「RDBMSの時代の終わりが見えてきた」というタイトルで、こういう書き方をすると、「ORマッピングによって、すでにRDBMSからの脱却の準備は始まっている」という風に読めるでしょう。これが、ミスリード。 JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。 これをもう少し、噛み砕くと、JPAのJPQL(SQLもどき)を使えば、SQLとしては統一されていない複
DBMSでテーブル名とフィールド名をクォートした際の挙動を知る - Sooey
database Originally uploaded by Tim Morgan PEAR::MDB2のリードメンテナであるLorenzo Alberton氏による、DBMS identifiers and case sensitivityが興味深い。DBMSで「テーブル名やフィールド名をダブルクォートで囲んだ」場合に大文字小文字がどのように扱われるのかということをちゃんと意識しないとダメですよ、という内容。 SQL:2008とSQL-99では「クォートしない限りケースセンシティブにはならない」（大文字小文字を区別しない）としており、DB2、Oracle、Interbase（Firebird）はこれに合致している。PostgreSQLの挙動も同様だが、前者が「非クォート時に大文字」となるのに対して、こちらは「非クォート時に小文字」になる点が異なる。 MySQLはテーブルがファイルシステ
ウノウラボ Unoh Labs: PL/SQLを浅く紹介
こんにちは。中村です。 先日、社内勉強会でPL/SQLがどういうものかを浅く紹介しましたので、そのときのスライドを公開します。 ウノウの入る前のことですが、受託開発をやっていたときの経験では、Oracleの現場が8割、SQL Serverの現場が1割、その他の現場が1割という印象でしたが、ウノウも含めてWebサービスではMySQLやPostgreSQLなどのOSSを使うことの方が圧倒的に多いようです。 そういう訳で、Webサービスの構築ではOracleで動作するPL/SQLを触る機会がめっきり少ないかもしれませんが、どういうものかを知っておくのは良いかもしれません。私自身もかなり忘れてしまっていたので、復習もかねて取り上げてみました。 plsql - Upload a Document to Scribd 参考情報: アプリケーション開発者用のPL/SQL
PostgreSQL テーブル LOCK MODE 関係図|てくめも@ecoop.net
テーブルロックモードの関係を把握しやすいように図で表してみました。 () 内はそのロックを自動的に獲得するクエリです。 ■ロックとトランザクション SQL における排他制御の方法として、トランザクションとロックが挙げられます。 複数のクエリをトランザクションでひとつにまとめることで、(デフォルトのトランザクションレベル READ COMMITTED の場合)コミット済みの結果のみ参照されるようになり、トランザクション中の内容を外部からは見えなくなるため一見アトミック性が守られるように見えます。 しかし、複数の接続で同時に既存の同じレコードに対して参照と更新を分けて実行する場合などはトランザクションだけでは限界があるのも事実です。 たとえば以下のテーブルを考えてみましょう。 CREATE TABLE foo ( id int NOT NULL, — 商品の識別番号 price int NOT
SELECT * from sqlbooks WHERE fun = 1 -- 書評 - Head First SQL : 404 Blog Not Found
2008年06月08日00:00 カテゴリ書評/画評/品評iTech SELECT * from sqlbooks WHERE fun = 1 -- 書評 - Head First SQL オライリー矢野様より献本御礼。 Head First SQL Lynn Beighley 佐藤直生監訳 / 松永多苗子訳 初出2008.06.03; 販売開始まで更新 これはすごい。ここまで分かりやすく、楽しく、それでいてきちんと完結している入門書は、SQLの入門書に限らず前代未聞。 オライリー、おそるべし。 本書Head First SQLは、SQLを「頭と体で理解する」入門書。というか、もし他のHead Firstシリーズも本書レベルだとしたら、オライリーは入門書を再定義してしまったとすら言える。入門書2.0だ。 目次 - oreilly.co.jp -- Online Catalog: Head
SQLエスケープにおける「\」の取り扱い
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://tokumaru.org/d/20090327.html
リレーショナル・データベースの世界
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/12/mysql_order_by_limit.php