The JSON SQL Injection Vulnerability
tl;dr Many SQL query builders written in Perl do not provide mitigation against JSON SQL injection vulnerability. Developers should not forget to either type-check the input values taken from JSON (or any other hierarchical data structure) before passing them to the query builders, or should better consider migrating to query builders that provide API immune to such vulnerability. Note: 問題の発見者による日
とある診断員とSQLインジェクション
7. 通常のWebサーバとの通信 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vultest@example.jp<BR> 性別:男<BR> （以下略） </html> POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp&gender=1 HTTP Response HTTP Request 8. 色々いじってみてどういう応答があるか確認 POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
sqlのwhere in って、複数条件(カラム)を指定できるんですね - end0tknr's kipple - web写経開発
http://blog.fusic.co.jp/archives/1765 ↑postgresの記事ですが、mysqlでも同様に実行できました。 SELECT * FROM test_table WHERE (col,co2) IN -- 複数のカラムを指定 (SELECT subcol1,subcol2 -- 副問いの戻り値も複数のカラムを指定 FROM subtable WHERE id > 10 ) 知らなかったなんて、お恥ずかしい ※手元にあるmysqlはv.5.1.61ですが、v.4.1から使えるらしい sqlの仕様として、mysqlのdocでは分かりませんでしたが、sql99から利用可らしい http://dev.mysql.com/doc/refman/5.1/ja/comparison-operators.html ↑では、分かりませんでしたが、次のurlよれば、sql99
SELECT COUNT(*) FROM (SELECT 1 FROM xxxx)が、SELECT COUNT(*) FROM (SELECT item_id FROM xxxx)より速い理由 - walf443's blog
とあるサービスでslow logをみていたら、どこかの記事で読んだことのあるクエリがでてきたのだけど、もうちょっと速くできないものか、と考えてみた。 結論を言えば、 BEFORE: SELECT sql_no_cache COUNT(*) FROM (SELECT item_id FROM category2item WHERE category_id = '2' group by item_id ) AS t; 1 row in set (2.06 sec) AFTER: SELECT sql_no_cache COUNT(*) FROM (SELECT 1 FROM category2item WHERE category_id = '2' group by item_id ) AS t; 1 row in set (1.89 sec)という感じで、SELECT item_idではなく
「SQL アンチパターン」を読んだ - tsucchi の日記 2nd season
概要 割ともう書評も出揃ってる感がありますが、ようやく読み終わったので書こうと思います。 この本は SQL や DB 設計でやってしまいがちな、ダメダメなパターンを体系化して、名前をつけたものです。また、なぜそうなってしまうのか、どうやって回避するのか、使っても良い場合があるとしたらどういう場合か、も書いてあります。 PoEAA なんかもそうなのですが、わりと「知ってたわー、N年前から知ってたわー」という感想なのですが、それは僕自信がここ数年、それなりに真面目に DB 設計やったり SQL 書いたりしてたから言えるわけで、Nが 0 ならそれに越したことはないと思います。 DB とか SQL とか自信ない人は是非読むべきです。DB 設計とか長くやってる人も、読んだほうがいいでしょうね。デザパタなんかと同様に、今後はパターン名知らないと、話が通じなくなっちゃう可能性がありますから。 経験の少な
#mysqlcasual vol.4 でカジュアルに発表してきました · さよならインターネット
April 18, 2013 MySQL Casual Talks vol.4 で発表してきました。 お声がけしていただいた@myfinderさん 会場提供していただいたOracleさん 業務中にSQLの勉強してるのを暖かく見守っていていてくれた弊社のみなさま @fujiwaraさん ありがとうございました。 発表内容 順番が@saisa6153さんの次という並び順でよかった。 カジュアルにSQLを勉強するには〜的な話が続けられて最高だった。 今回は初参加の人が半数以上いて、これはもしやいけるのでは！？って思って 発表はじめる前に、会場でSQL書いたことのない人いますか？ って聞いて、誰も手を上げなくて、会場で話す意味合いなくなって インターネットの向こう側とか、まだ見ぬエンジニアに向けてみたいな発表になった。 インターネットの向こう側へ話したこと(2週間で何ができたか) 本を買った 「初
データベースへのクエリをトレースする PSGI ミドルウェア - tokuhirom's blog
これをつくってる途中で、DBIx::QueryLog がめんどくなってきて DBIx::Tracer をつくってしまったのでした。 なんか無駄に threashold_sum_total_cnt とかで設定できるようになってるけど、手でいじって適当に自分のプロジェクトにぶっこんだ方が便利な気がします。 とくに CPAN にあげたりする予定はありません。 package Plack::Middleware::DBProfile; use strict; use warnings; use utf8; use 5.10.0; use parent qw(Plack::Middleware); use Plack::Util::Accessor qw(path_re threashold_sum_total_cnt threashold_total_time threashold_total_c
簡易2WaySQL - blog.nekokak.org
2WaySQLというものがあるわけです。 2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation を参考にしてもらうとして、 超絶簡単に説明すると、実行可能なSQLを書いておいて（where句の値もデフォルト値を書いておくので実行可能となる） プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。 どんなSQLかというと SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)こういう感じ。 普通に実行可能ですよね。 これを、 my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1
SQL::Object
というのを作ってみた。(結構前に) https://github.com/nekokak/p5-SQL-Object コンセプトは 生のSQL（基本where句）をプログラマブルに結合出来るようにすることです。 （namespaceが微妙という説もあるけどSQL::Stringとかもにたようなもんだよね！） 使い方： use SQL::Object qw/sql/; my $sql = sql('foo.id=?',1); $sql->as_sql; # 'foo.id=?' $sql->bind; # qw/1/ $sql->and('foo.name=?','nekokak'); $sql->as_sql; # 'foo.id=? AND foo.name=?' $sql->bind; # qw/1 nekokak/ $sql->as_sql; # 'foo.id=? AND foo
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
LIKE節におけるエスケープ文字とDBIx::PrintfもしくはDBIx::Printf::Named - blog.nomadscafe.jp
SQLのLIKE節では「%」と「_」の2文字をワイルドカードとして利用します。「%」「_ 」を通常の文字として使いたい場合、以下のようにエスケープを行います % => like 'foobar\%%' _ => like 'foobar\__' ただし、デフォルトでbackslashにてエスケープが行われるのは、少し調べたところMySQLとPostgreSQLあたりで、SQLiteやOracleではエスケープされません。別途エスケープ文字を指定する必要があります。それがLIKE .. ESCAPEです LIKE 'foobar\%%' ESCAPE '\' LIKE 'foobar$%%' ESCAPE '$' 上のように、エスケープに利用する文字を指定できます。もし、エスケープをしないなら空文字にすれば良いそうです LIKE '_foobar%' ESCAPE '' あまりないとは思いま
SQL::Makerで動的に SQLを生成する - Articles Advent Calendar 2010 Hacker
どうもこんにちは。hacker track がやる気なさすぎるのでもう一回かくよ!というわけで tokuhirom ですこんにちは。こんにちは。 さて、最近つくった SQL::Maker というモジュールについて紹介します。SQL::Maker は、要は SQL::Abstract みたいなやつです。じゃあなんで SQL::Abstract じゃなくて SQL::Maker なの？ってことになるわけですが、 SQL::Abstract は実績があるし、非常に便利なんですが、いかんせんコードがまじよみづらいっていうかこれよむの無理じゃね!!ってことをおもうので、あたらしくつくったという次第。 また、SQL::Maker は method chain で SELECT 文を構築する機能もついてます。あらべんり。こんなかんじ↓↓ my $sql = SQL::Maker::Select−>new
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
第36回 SQL::Abstract：簡単なSQLはより簡単に | gihyo.jp
DBIの泣き所 いわゆるLAMPないしそれに似た環境でウェブサービスばかり書いている方にはあまり実感がないかもしれませんが、あちらの現場ではOracleを、こちらの現場ではMicrosoft SQL Serverを、はたまた別の現場では組み込みのSQLiteを、といった受託系の仕事をしている人にとって、SQLの方言問題は避けては通れないもののひとつです。 典型的なところでは、たとえばSELECTで取得するデータの件数を制限したい場合、PostgreSQLなどでは「LIMIT ... OFFSET ...」のように書きますが、OracleではROWNUMを使いますし、MS SQL serverならSET ROWCOUNTやTOPを使います。また、いまでこそPostgreSQLとの互換性を確保するため「LIMIT ... OFFSET ...」と書けるようになっているMySQLにしたところで、
異なるDBMS間のSQLを変換してくれるモジュール SQL::Translator - Perl勉強メモ アルパカDiary出張版
こういうの無かったらつくってみようかなーと思ったんですが、やっぱりありましたね。 テスト用で使ったsql文(oracle) CREATE TABLE EMP (EMPNO NUMBER(4) NOT NULL, ENAME VARCHAR2(10), JOB VARCHAR2(9), MGR NUMBER(4), HIREDATE DATE, SAL NUMBER(7, 2), COMM NUMBER(7, 2), DEPTNO NUMBER(2), CONSTRAINT PK_EMP PRIMARY KEY(EMPNO), CONSTRAINT FK_DEPTNO FOREIGN KEY (DEPTNO) REFERENCES DEPT ); CREATE TABLE DEPT (DEPTNO NUMBER(2), DNAME VARCHAR2(14), LOC VARCHAR2(13)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
