Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
ときどき SELECt * FROM item as T1みたいな連番別名テーブルを見るんだが。 どこかで推奨でもされているんだろうか。 プログラムの変数名に無意味な連番は有り得ないっていうのは共通認識としてあると思うけど、SQLはそうじゃないんだろうか。 検索して上から順に見ていった。 オブジェクト(主にテーブル)のエイリアスは大抵つける、その際、テーブル名を略したエイリアスをつけない(TOKUISAKI_MST TOK, USER_MST USR みたいな)。理由は、略文字はテーブル名が増えたり、似たような名前のテーブルが並ぶと、ぱっと見で判断しにくいから。その点数字だとすぐ見分けが付く。(from 句を参照しないとだめだが) 頭文字の f というのは特に意味なし。 http://d.zeromemory.info/2007/01/19/coding-rule-sql.html あと、
今まで2回にわたって、SQL識別子のエスケープの問題を取り上げました。 間違いだらけのSQL識別子エスケープ SQL識別子エスケープのバグの事例 3回目となる本稿では、SQL識別子の取り扱いに関する問題を整理して､一般的な原則を導きたいと思います。 SQL文が動的に変化する場合のSQLインジェクション対策 「間違いだらけの…」で示したように、識別子エスケープが必要な局面でそれが洩れていると脆弱性の要因になることがありますが、それは外部から指定したデータにより、SQL文の構造が変化してしまい、アプリケーションの要件にないSQL呼び出しがなされてしまうからでした。 しかし、「間違いだらけ…」の後半で示したように、識別子のエスケープだけではセキュリティ問題を防ぐことはできず、情報漏洩を招いてしまいました。外部から任意のSQL識別子を指定できることが問題という結論でした。 上記のように、アプリケー
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず（こっちはちょっとやってしまった）頑張っておりました。 長かった。 本当に長かった。 原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。 さて、本書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いています
概要 割ともう書評も出揃ってる感がありますが、ようやく読み終わったので書こうと思います。 この本は SQL や DB 設計でやってしまいがちな、ダメダメなパターンを体系化して、名前をつけたものです。また、なぜそうなってしまうのか、どうやって回避するのか、使っても良い場合があるとしたらどういう場合か、も書いてあります。 PoEAA なんかもそうなのですが、わりと「知ってたわー、N年前から知ってたわー」という感想なのですが、それは僕自信がここ数年、それなりに真面目に DB 設計やったり SQL 書いたりしてたから言えるわけで、Nが 0 ならそれに越したことはないと思います。 DB とか SQL とか自信ない人は是非読むべきです。DB 設計とか長くやってる人も、読んだほうがいいでしょうね。デザパタなんかと同様に、今後はパターン名知らないと、話が通じなくなっちゃう可能性がありますから。 経験の少な
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
サロゲートキー（代理キー）は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID（IDリクワイアド）」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう（とくに保守担当者が）。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう（図１）。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性（時間あたり生産数）の管理簿である。 ＜図１＞ [工程]工程id,工程名,扱い単位 ＋ ￣￣￣ ｜ 001 切削 個 ｜ 002 加工 ｍ ｜ └―∈[作業区]工程id,行番,作業区名,標準生産性 ＋ ￣￣￣￣￣￣ ｜ 001 01 切削１号 1000/hr ｜ 001 02 切削２号 2
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る本書の著者はサロゲートキーに対して消極的なのだから、「サロゲートキーの使い方がおかしい」とか言うのはお門違いなのかもしれないが... 健忘症的サロゲートキー 「SQLアンチパターン」第3章の記述を総合すると、著者はサロゲートキーについて以下のように考えていると思う。 自然キーの一意性・不変性が当てにならない場合に「自然キーの変更の影響を受けないようにする」という目的でサロゲートキーを導入する。 自然キーの重複を防ぐために、自然キーにUNIQUEインデックスを振ることを推奨する。 自然キーの代わりにサロゲートキーを外部キーにする。自然キーは他のテーブルに転
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
Atsushi Kobayashi bayashi Fuji, Goro Gelu Lupas issm k-takahashi karupanerura Kaz-su Kazuho Oku ktat lestrrat makamaka Masahiro Chiba Masayuki Matsuki Neil Bowers plsplsme pokutuna sakamossan soh335 Tokuhiro Matsuno Toshio Ito yamaguchi.toru NAME SQL::Maker - Yet another SQL builder SYNOPSIS use SQL::Maker; my $builder = SQL::Maker->new( driver => 'SQLite', # or your favorite driver ); # SELECT ($
監訳の一人である @t_wada に献本頂きました。 ありがとうございます！！！ でだ、いきなりだけどコレ、タイトルで損してると思うんだよね…… だって、SQL のアンチパターンてタイトルだったら、 join した結果の方で where で絞るよりも on 句で先に絞れ 的なのが書いてあると思うじゃん！！ 問い合わせ言語の事だと思うじゃん！！！ 違った…… ほとんど書いてあるのは DB 設計についてだった…… まぁ、副題は「Avoiding the Pitfalls of Database Programming」のだし、まぁいいか。 んで、読んでみた感想とか もうね、何年か DB 絡んだ開発したことのある人なら（・∀・）ﾆﾔﾆﾔ出来ると思う。 「”マルチカラムアトリビュート”とか 10 年前に通ったわー」 とか 「あーはいはい”インデックスショットガン”乙」 みたいな。 Explain
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論
December 07, 201208:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か タイムラインで「SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？」ってのを見かけて居ても立ってもいられなくなったので、既出を承知で反論しておきたい。 スライドだけから話の内容を推測すると、 -- 販売成績上位10個を抽出 select * from sales where deleted = false order by amount desc limit 10 といったSQLを Sales.active().top(10).all() のように、細かく分解した部品を組み合わせて表現できた方が便利だし構造的でしょ？という話のようだ。 これは確かに一見美しいのだが、これこそが「敷居を下げすぎて、dbの性質を分かってない人まで気軽にSQLをいじるようになった結
本日お越しいただいた方、有難うございました。裏番組が超強力(メインホールに宮川さん、お隣が弾さんのうえ、LTソンで gfx さんがやってるとか、まじありえないだろwってかマジでオレ涙目ですわー)でしたが、思いのほか、沢山集まっていただいて嬉しかったです。 発表資料は下記に置いておきます。アニメーションちゃんと動いてないけど、ご了承ください。ちゃんとしたやつ(LibreOffice で書いてます)が欲しい方は 私のところまでご連絡ください。(twitter なら @tsucchi ね。) あと、スライド中にも紹介した、nihen さんのトークが(はからずも)このトークの続きみたいな感じになっていて、いい感じなので一緒に見ておくと 良いかもしれません。これ => very simple ORMapper Teng。 Q.A. Q1. トランザクションのところについて。例外処理とかあまり真面目に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
