SQLは滅ぶべきか｜ミックでかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。
Gormにおける「仕様通り」なSQLインジェクションの恐れのある実装についての注意喚起 - ANDPAD Tech Blog
ANDPADボードチームの原田(tomtwinkle)です。 Node.jsの mysqljs/mysql の仕様に起因するSQLインジェクションが話題に上がっていたので、それGolangのORMであるGormでも同じような「仕様」があるよ！ という注意喚起の意味も込めて筆を執りました。 ※ 2022/02/21追記 コードレビューを自動化して指摘してもらう記事を公開しました！ tech.andpad.co.jp Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション | 株式会社Flatt Security TL;DR GormのQuery Conditions関数に関する危険な仕様 対策 締め TL;DR GormのConditions関数(Find, First, Delete...)を使用する際、第2引数の値にStringを引き渡
自己流のSQLインジェクション対策は危険
HTMLエスケープの対象となる < > & " の4文字は、文字実体参照に変換された後、preg_replace関数でセミコロンを削除してしまうので、中途半端な妙な文字化けになりそうです。 一般的な原則としては、データベースにはHTMLの形ではなくプレーンテキストの形で保存しておき、HTMLとして表示する直前にHTMLエスケープする方法で統一することで、上記のような文字化けやエスケープ漏れをなくすことがよいでしょう。 脆弱性はないのか このsanitize関数に脆弱性はないでしょうか。上表のように、バックスラッシュ（円記号）を素通ししているので、MySQLや、設定によってはPostgreSQLの場合に、問題が生じそうです。以下、それを説明します。以下の説明では、MySQLを使う想定とします。 以下のように、ログイン処理を想定したSQL文組立があったとします。 $sql = sprintf(
「SQL アンチパターン」は色んな戦争の火種になりそう - yoshiori.github.io
監訳の一人である @t_wada に献本頂きました。 ありがとうございます！！！ でだ、いきなりだけどコレ、タイトルで損してると思うんだよね…… だって、SQL のアンチパターンてタイトルだったら、 join した結果の方で where で絞るよりも on 句で先に絞れ 的なのが書いてあると思うじゃん！！ 問い合わせ言語の事だと思うじゃん！！！ 違った…… ほとんど書いてあるのは DB 設計についてだった…… まぁ、副題は「Avoiding the Pitfalls of Database Programming」のだし、まぁいいか。 んで、読んでみた感想とか もうね、何年か DB 絡んだ開発したことのある人なら（・∀・）ﾆﾔﾆﾔ出来ると思う。 「”マルチカラムアトリビュート”とか 10 年前に通ったわー」 とか 「あーはいはい”インデックスショットガン”乙」 みたいな。 Explain
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLわかんねーーーーーーーー！！！！！！
