このテックブログを「quine」で検索していただくとわかるんですが、エムスリーのエンジニアはわりとQuine好きです。Quine（クワイン）とは、文字列を打ち出すだけのプログラムであってその打ち出した文字列というのが自身のコードそのものになっているようなもののことです。 Perl, Python, Rubyなど、手続き型言語で書かれることの多いQuineなのですが、日頃業務でSQLを扱うことの多い私は思うわけです。SQLだって文字列を出力できる言語だぞ、Quine書けるんじゃと。エムスリーエンジニアリンググループUnit1（製薬プロモーション）／Unit9（治験臨床研究支援）エンジニアの三浦[記事一覧 ]です。日頃のお仕事からは離れてSQLでQuineを書いて遊んでみました。 基本方針 やっていく コード内にシングルクォーテーションを書かない プログラムの先頭側と末尾側をひとつの文字列デ
Transcript SQL 株式会社 AI Shift 三宅 悠太 1. データベース 2. SQL I 3.トランザクション 4. データベース設計 5. インデックス 6. 実行計画 7. SQL II データベース データベースとは “A database is an organized collection of inter-related data that models some aspect of the real-world “ (CMU) データベースとは、実世界のある側面をモデル化した、秩序 だった、相互に関連したデータの集まり DBMS • データベース管理システム（DBMS）は、データベースを管理するソフトウェア ◦ 例：MySQL, Oracle Database, SQLite, MongoDB • DBMSの目的は、アプリケーションが簡単にデータベースにデー
https://github.com/r7kamura/scheman 旅行を兼ねて沖縄に開発合宿に来ているので、1日目の成果を書き出しておく。 目的 Webアプリの開発フローで次のような状態を実現したい。 DBの変更のたびに変更用のSQLやMigrationファイルを人間が書かなくて良い migrationファイルを書く代わりに人間はスキーマを編集する スキーマはSQLで記述できる (DSLの使用を強制されない) SQL以外の言語でも記述できる (DSLを使用しても良い) 方針 次のような実装を試みた。 SQLを構文解析してスキーマデータに変換する (解析器は事前に実装済み) 適用すべきSQLを2つのスキーマデータの差分から自動で計算する SQL以外の解析器も作成可能に scheman diff scheman diffというコマンドを実装した。 これは変更前後の二つのスキーマの差分を標
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
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インジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる（「'OR'1」）ことを示しましたが、@masa141421356さんと、やまざきさん（お二人とも拙著のレビュアーです）から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います（id側に「'OR」, pwd側に「>' 」で6文字）。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
DBIのconnectのCallbacksなどでSQLを実行している時とかに、実際にSQLが流れているのかチェックしたい時がある。そういう時どうするのがベスト・プラクティスなのかわからないのだけど、DBIx::QueryLogを使ったら一応できたのでメモ。 テストしたい状況 package My::DBI; use strict; use warnings; use DBI; sub connect { my ($dsn, $username, $password) = @_; my $dbh = DBI->connect($dsn, $username, $password, { Callbacks => { connected => sub { my $dbh = shift; $dbh->do("SET NAMES utf8") or warn $dbh->errstr; retur
結論 SQLがどーのデータの持ち方がこーのというアプリ開発側の話題がメインのDB勉強会をやりたいからやるよという話 以下補足 コンテンツ アプリ開発者がDBを握らなければならない時代 DBを握るということ 勉強会について アプリ開発者がDBを握らなければならない時代 データ爆発の時代 データ爆発の時代がくると言われて久しいです。扱うデータの量が増えてきているだけでなく、データの構造も多種多様になってきていると感じています。これまではOne Size Fits AllでRDBが対応してきたのが、増加し複雑化していくデータにRDBのみでは対応しきれなくなってきている為にNoSQLのようなプロダクトが盛んに開発され利用されています。 アプリ開発者としてやるべきこと そういった時代を迎えるにあたって、アプリ開発者は何も備えなくていいんでしょうか？DBはインフラ/サーバーエンジニアのもの？ 僕は「D
MacBook Air 11インチ欲しい！ @sugyanさんのSQLでincrementした値を表示する方法を考える - すぎゃーんメモを生DBIでやってみたのとベンチマークとってみた。 トランザクションなし Rate dbic teng dbi1 dbi2 dbic 578/s -- -64% -92% -92% teng 1587/s 175% -- -78% -79% dbi1 7143/s 1136% 350% -- -7% dbi2 7692/s 1231% 385% 8% --トランザクションあり Rate dbic teng dbi1 dbi2 dbic 581/s -- -59% -88% -92% teng 1429/s 146% -- -71% -81% dbi1 5000/s 760% 250% -- -35% dbi2 7692/s 1223% 438% 54%
季節が変わって、早速風邪をひいています。 さて、もう秋を通り越して冬の様相を呈してきた昨今ではありますが、DBI では、普通はプレースホルダを使い my $stmt = 'SELECT * FROM user WHERE user_id = ?'; my @bind = ($user_id); $dbh->do($stmt, undef, @bind); とか書くと思います。 このときに、実際にバインドされた後の SQL をみたいなーって衝動に駆られると思いますが*1、どう頑張ってドキュメントを読んでもわかりませんね。 こういうときは仕方ないので、$stmt と @bind を両方ログに出してお茶を濁していました。 $self->log->_dump($stmt, @bind); # => SELECT * FROM user WHERE user_id = ?, [1234] でもこれっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く