メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
こんにちは、SQLを愛してやまないmoriyoshiです。 ストアドプロシージャは、一連のSQL文をサブルーチンのようにDBサーバに記録しておき、後からそれを呼び出すことができるようにする仕組みです。近代的なRDBMSには標準的に備わっている機能といえます。 制御構造などもSQL文で記述することができるので、結果的に、あらゆるロジックをSQLのみで記述することができます。手続き型プログラミングにどっぷり浸かった現場の方から愛用されていると言われています。 今回は、ストアドプロシージャの応用として、Webスクレイピングを行なってみましょう。Webスクレイピングとは、特定のWebサイトにアクセスし、そのページの内容 (HTML) を取得、解析し、必要な情報を取り出すという一連の操作を自動化することです。Webスクレイピングを効果的に活用すると、人間がブラウザに向かって単純作業を繰り返す必要がな
S2JDBC(やS2Dao)では、2Way SQLにIFやBEGINコメントを埋め込んで動的にWHERE句を組み立てていました。 select ... /*BEGIN*/ where /*IF foo != null*/ foo = /*foo*/1 /*END*/ /*IF bar != null*/ and bar = /*bar*/1 /*END*/ /*END*/このSQLコメントを使った動的なSQL生成は、評判の良かった機能ですが、SQL文にロジックが入るとコンパイラでチェックできないので、何とかしたいと思っていました。 そこで、Slim3 JDBCで考え付いたのが、WHEREコメントを使って、Javaから動的にWHERE句を組み立てる方法です。SQLはこんな感じ。 select ... /*WHERE*/WHERE句は、Conditionオブジェクト(S2JDBCのWhereオ
SQL::Translator is a group of Perl modules that manipulate structured data definitions (mostly database schemas) in interesting ways, such as converting among different dialects of CREATE syntax (e.g., MySQL-to-Oracle), visualizations of schemas (pseudo-ER diagrams: GraphViz or GD), automatic code generation (using Class::DBI), converting non-RDBMS files to SQL schemas (xSV text files, Excel sprea
クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB
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
Railsの勉強がしばらくストップしてしまったので、今日はビデオを見てお勉強。Rails Envyの「ActiveRecord Tutorial」は長さも２５分とちょうど良いし、「ActiveRecordとはなんぞや」を具体例を交えて簡潔に教えてくれるのでとても良い勉強になる。 英語だが、冒頭の部分を乗り越えればあとはプログラミングの話なので、日本人にもそれほど難しくないはず。念のため、オープニングの部分のみ、超訳しておいた。 ActiveRecordのアイデアは、いったいどこから来たのか？ まずは"Active Record"の意味から （ActiveRecordではない点に注意） "Active Record"とは、デザイン・パターンの一つ。 どうやってデータベースにアクセスするか？ SQLにプログラムから直接アクセスする方法もあるが...ちょっと不便 データベースのテーブルをオブジェ
はてなブックマークのコメントより。 昨日お伝えしたGladius DBの対抗馬として紹介したい。こちらもまた、テキストファイルをDBとして扱うことができる。さらにGladius DBへの挑戦なのか、ベンチマークを公開している。 今回紹介するオープンソース・ソフトウェアはtxtSQL、テキストベースのデータベースソフトウェアだ。 txtSQLはGladius DBとは異なり、SQL文を解釈しない。独自の関数にアクション（SELECT/INSERT/UPDATE/DELETE等）、テーブル名、データ、WHERE句などを指定して渡す必要がある。 そのため、既存のアプリケーションを乗り換えるには修正が必要になってしまうのが難点だ。だが、新規開発であれば関係ないだろう。また、その結果として高速性が売りだ。Gladius DBの10倍近いパフォーマンスが出ている。 面白いのは、サンプルアプリケーション
はじめに SQLのクラスを教えるとき、最大の課題の一つが、生徒たちがそれまでに手続き型言語から身に付けたことを、一度「頭から追い出す（unlearn）」ことだ。私がそのとき採る一つの方法は、処理を「レコード単位」ではなく、集合という観点から考えるよう強調することである。 ――――J.セルコ SQLの考え方を習得するときに最大の障壁となるのが、私たちの多くが慣れ親しんだ手続き型言語の考え方（ソート、ループ、分岐、代入、等々）です。SQLの本質を理解するには、私たちの心に強固に貼り付いてしまった思考パターンを、一度ベリベリと引き剥がし、更地に戻してやる必要があります。それが、セルコが「unlearn」という言葉に込めたニュアンスです。セルコ自身、Fortranからプログラマとしてのキャリアを開始し、C、Algol、Pascalと手続き型言語を渡り歩いた後にSQLを身に付けた人物だけに、言葉に
はじめに 関係モデルのデータ構造には、「順序」という概念がありません。必然的に、その実装であるリレーショナル・データベースのテーブルやビューにも、（たてまえ上）行列の順序がありません。同様にSQLも、順序集合を扱うことを直接的な目的とはしていません。 そのため、SQLでの順序集合の扱い方は、最初から順序を扱うことを目的とした手続き型言語とファイルシステムのアプローチとはかなり異質なものになります。しかし、異質ではあるものの、そこに確固たる原理が存在することも確かです。一言で言えば、集合と述語――特に「量化子」（quantifier）と呼ばれる特別な述語の使い方が鍵になります。 本稿では、SQLを使って、数列や日付などの順序を持つデータを扱う方法を解説します。単にTipsを列挙するだけでなく、できれば、解法に共通する基本的な原理を取り出し、未知の問題に取り組むときにも適用できる一般的な指針と
某所でのネタだったんですが、少し追加情報があったのでここに書いてみます。 以下、mysql4.1での話。それ以外では、確認してないどころかどうなのか想像すらつきません(postgresとかほとんど触ったことない)。 なぞなぞ 次のようなテーブルがあるとします。 CREATE TABLE ( user_id INT NOT NULL, item_id INT NOT NULL, price INT NOT NULL, PRIMARY KEY (user_id, item_id) );mysql> select * from test; +---------+---------+-------+ | user_id | item_id | price | +---------+---------+-------+ | 1 | 100 | 30 | | 1 | 200 | 80 | | 2 |
Begin transaction Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Goto 便所 便所: Rollback INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れの精液)
はじめに SQLが集合論に立脚する言語であるということは、この連載で一貫して強調してきたテーマの一つです。その特性のゆえに、SQLは「集合指向言語」と呼ばれていますし、実際、集合的な観点から見たときに初めて、その強力さが理解できると私は考えています。しかし現実には、SQLのこの側面は長らく無視されてきました。 その背景には、SQLにも責任の一端があります。というのも、SQLはちょっと前まで、高校で習う程度の基本的な集合演算子すら持っていなかったからです。和（UNION）こそSQL-86からの古参ですが、交差（INTERSECT）と差（EXCEPT）が標準に入ったのはSQL-92ですし、除算（DIVIDE BY）が未だに標準化されていないことは、前にも述べました。だから、SQLが言語として不完全だという批判は、理由のないものではなかったのです。 しかし、現在では標準SQLに基本的な集合演算子
はじめに SQLというのは変わった言語です。こういう印象は人によって差があると思いますが、おそらく最初に手続き型言語を学んだ正統派のプログラマやSEほど強くそう感じると思います。 SQLに違和感を感じる理由は、いくつか考えられます。第一に、SQLが「集合指向」という発想に基づいて設計された言語で、この設計方針を持つ言語が少ないことです。そして第二に、それに劣らず大きいのが、最初に学んだ言語のスキーマ（概念の枠組み）が心理的モデルとして固定され、それを通して世界を見るようになるため、異なるスキーマを持つ言語の理解が妨げられることです。 本稿では、HAVING句のさまざまな応用方法を紹介していきますが、その際、手続き型言語とSQLの考え方を比較します。それによって、私たちが手続き型言語で身に付けた無意識の心理的モデルを自覚し、集合指向という発想に感じる違和感を軽減したいと考えています。 今回は
0-DAY - SIMPLE SQL INJECTION あるオープンソースのCMSのセキュリティホールを探る際のFlashムービー。 映画のイントロのように始まり、怪しげな音楽と共にムービーが再生される等、あやしい雰囲気たっぷりに作られています。 IRCチャットで依頼が始まり、ソースのDL〜grepしてSQLインジェクションの脆弱性を見つけ、実際にIDとpassを取り出すまで。 こういう手口で脆弱性が発見されるんだな、というのがハッキリと分かります。 もちろん、ソースなど見なくてもURLから類推したりその他のパターンも多数あると思いますが、オープンソースの場合はこんな感じでソースをgrepされたりするんでしょうね。 SQLインジェクション対策の参考に。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く