SQLインジェクションを使ったアタックが増加中 58
ストーリー by hylom
気をつけろ、奴らが狙っている 部門より
気をつけろ、奴らが狙っている 部門より
独立行政法人 情報処理推進機構のセキュリティセンター(IPA/ISEC)は、コンピュータウイルス・不正アクセスの届出状況[5月分]を発表した。iLogScannerでの解析によると、4月、5月にアタックが増えているとのこと。また、被害報告も上がっており、悪意のあるサイトへの誘導のためにサイトデータを改ざんするケースもあった。このような誘導型の改ざんが増えている傾向もあるようだ。
一段落したと思っていたSQLインジェクションだが、先日も HackerSafe証明済みサイトでカード番号漏洩発生、原因はSQLインジェクションという話もあり、まだまだ危ないところは多いのだろうか。
IPAの発表によると、SQLインジェクションと思われる攻撃は2月は3件、3月は4件だったのに対し、4月には29件、5月には55件にまで急増しているとのこと。
多いどころか (スコア:5, 興味深い)
私の周りを見ていると、減るどころかむしろ増加傾向です。
近くで受託開発したコードを見ると、おもいっきり脆弱性を積み込んで納品しています。
指摘しても、売り上げに繋がらないことをするつもりかと、馬鹿にした顔で逆に聞かれてしまいます。
実際、脆弱性を積み残していても発注元(大手CP含む)の担当者は気にも留めません。
むしろセキュリティ対策を削ってでも安くしろと言って来ますね(言外にですが)。
まぁ世間ってそんなものかもしれません…。
# さすがにACで
Re:多いどころか (スコア:2, すばらしい洞察)
いいえ (スコア:0)
今の日本でセキュリティに金をかけるのは金をドブに捨てるようなものです
Re:いいえ (スコア:1)
お金をドブに捨てて高台に逃げますか？
お金を抱えたまま十年に一度発生する洪水に流されますか？
みたいな感じでしょうか。
もっと大騒ぎになるくらい被害が増えると考え方も変わってくるのでしょうけどね。
足りてないのはセキュリティに対する意識ではなく当事者意識だと思われます。
# セキュリティレベルってのは外から見るとわかりづらいからねぇ。普通の人には。
わかっていませんね (スコア:0)
Re:わかっていませんね (スコア:1)
何がわかっていないのかすらよくわからないこの阿呆に、
わかってるＡＣさんの御説の根拠などご提示いただければありがたいのですけどね。
# 天才は忘れた頃にやってくるそうですし。
## 『天災』だ。っつーかそもそも元の話はクラックなんだから天災じゃなくて人災だ。
Re: (スコア:0)
>今の日本でセキュリティに金をかけるのは金をドブに捨てるようなものです
それなんてカカクメソッド？
Re:多いどころか (スコア:1, 興味深い)
2004年：最初の報告
2005年：２度目＆３度目の報告（担当部署に話は伝わってるのに対応しない）
2006年：私は退職→数ヵ月後にIPAに報告→「サイト管理者に連絡しました」とIPA→その後の進展なし
2007年：進展なし
2008年：IPAに確認メール送るが返答無し＆サイトも進展なし
そもそも『脆弱性』以前に『マトモに動かす為の機能』だっての……。
Re: (スコア:0)
Re: (スコア:0)
削り忘れです。忘れてください。
Re: (スコア:0)
Re: (スコア:0)
ほんとぜんぜん減らないですよね。
十年前くらいのゲーラボで
「JPNICの検索フォームはクエリーをDBにナマでわたしてやがるぜギコハハ」
みたいな記事を読んだ記憶があります。
Re: (スコア:0)
さすがに/.Jerの会話だと、そういうpostするパラメータを手で書き換える・・・みたいなレベルは
皆無でいきなり「PreparedStatement」とか「ORマッパ」みたいなところから会話がはじまるので
すね。
SQLは人が手で入力して使うツール (スコア:1)
コードにSQLの断片を埋め込んで、パラメータを文字列連結して、ランタイムでコードがSQLを生成するのは、全面的にやめるべきだと思います。
メンテナンス性の為や手抜きのために複雑な構文解析機を通して検索ロジックを実行時に機械語へビルドしている事になるわけですが、安全なサービスの構築のためにはロジックは静的に用意されているべきだと思います。
上に ORM をのっけて蓋をするのでもいいんですが、SQLという文字列でロジックをDBSに渡すというのは、無駄が多すぎる気がしてなりません。
良い解決策をもっているわけではないのですが…
Re:SQLは人が手で入力して使うツール (スコア:4, 興味深い)
例えばOracleDBMSなんかだと, 一回構文解析したSQLはキャッシュ上に保存しておいて, 同じ字面のSQLが再発行された場合にはキャッシュ上の解析済みのコードを実行するようになっています. この効果は抜群で, 1回目には100m秒単位でかかっていた解析処理が2回目以降は10m秒未満から1m秒単位で実行可能になり, それに応じてCPU負荷も減ります.
そのため, OracleDBMSを利用したエンタープライズシステムではSQLの動的生成は論外に近く, 基本的にPreparedStatementを使ってパラメータのみを変更するのが定石になっています. 副次的に, PreparedStatementを使うと, かなりの割合のSQLインジェクションを防ぐことができるという利点もあります.
そういった開発パターンに慣れている立場から見ると, それほど容易にSQLインジェクションを可能にする環境というのがどういうものなのか, 逆に興味があります.
Re:SQLは人が手で入力して使うツール (スコア:1, 興味深い)
PostgreSQLだろうがMySQLだろうがSQLServerだろうがACCESSだろうが一緒です。
# でも、その例だとPreparedStatementにつっこむSQLは動的生成してんじゃないの？
# 組み立ててなくともアドホックなクエリなんだから扱いは一緒だと思うぞ。
# 静的というならストアドなりDBMS側に持たさないと。
ところでさ、昔ながらのクラサバ構成でも入力された値をそのままSQL文に繋げて実行するなんてことはしなかったよね。
「SQLインジェクション」なる言葉ってWebアプリが流行ってから出てきただと思うのだが違う？
それ以前からありますか？
どうもDBMSが何なのか解ってない連中が使い出したあたりが根っこなのかなぁと。
# 因みにOracle9iのJDBCだとバインド変数でVARCHAR2(4000)にShiftJISの2byte文字を2000文字入力できなかったりします。
# 悲しいことにバインド変数も万能ではないです。ちゃんとドキュメントに書いてあるんですけどね。
# 10gか11gのドライバで変わってるかもしれないけど。
Re:SQLは人が手で入力して使うツール (スコア:1, 参考になる)
JDBC Thinの10.1.0.4から制限が撤廃されました。
Re:SQLは人が手で入力して使うツール (スコア:1)
それはおそらくDBの設計, さらに遡れば業務分析やシステム構成設計がまずいと思います. 平たく言えば, 使い方が悪いってやつですね. だって, バインド変数で渡さなければならないものって通常はキーパラメータですから, 普通に考えればそんなに長大なキー項目はハッシュやB+木といった一般的な検索方法では効率が悪いし, インデックスキャッシュの使用効率も悪くなって性能がた落ちっていうのが見えますから.
ただ, 上流からそういう設計でやれと言われたらやらなくちゃいけない立場も分かるし, そういうダメ設計になった理由もあらかた想像がついちゃうんですけどね.
Re: (スコア:0)
繰り返す場合、単純に構文解析のオーバーヘッドが削れて速くなると思ってるんですが。
Re: (スコア:0)
S2JDBC [seasar.org]のやりかたはどの辺だと見なされるのか興味あります。
「流れるようなインターフェース」のせいで、
生成し得るSQLのバリエーションが凄く多いうえに、
同じ検索
Re: (スコア:0)
> それほど容易にSQLインジェクションを可能にする環境というのがどういうものなのか,
> 逆に興味があります.
PreparedStatementだと安全だと思い込んでる段階で既にヤバそうだな
ま、いいけどさ
PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1)
元のコメント主とは違いますが、PreparedStatementやまっとうなO/Rマッパーを使えば起こることは無いと認識していたのですが違うんでしょうか？
不勉強で申し訳ないですが「こういうときにヤバいぞー」というのとその場合の対策が知りたいです。
Re:PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1)
JDBC4.0のSpecificationを見ると、
と定めるのみで、私の見落とし出なければ、サニタイズについては何の規定もしていません。
紳士協定的に、もしくはデファクトスタンダード的に、もう少し言うと、親切心的に、サニタイズが実装されているのだというつもりで居た方がいいってことを、元ACさんは言いたいのでなかろうかと。
具体的な行動指針にしてみると、新しいデータベースエンジンを使う時はサニタイズに関してまずはテストをすべきじゃないか…っていう問いかけですね。
Re:PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1, 参考になる)
PEAR::DBなんかは、プリペア機能のないDBの場合はそういう動きをするようです。
Re:PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1)
型付けと字句解析が緩く、マルチバイト対応の甘い言語、製品のインターフェイスには
実装上の制限などからそういうのもあるらしいですね。
>PEAR::DBなんか
納得。
>プリペア機能のないDBの場合
でも、それは無いものに対してという前提があるのに、利便上あると誤解させる機能を持たせて
誤解を招くベンダーのが悪いか、接続先DBの仕様を知らないユーザが悪いかという問題であって、
正しく実装されていないPreparedStatementの問題でアプローチを否定する理由ではないかと。
攻撃されたとしても、自社開発ではない言語標準ライブラリの脆弱性を突かれたという品質の限界
を盾に瑕疵の軽減理由になるだけでも、それを使わない理由は無いんじゃないかと思います。
もちろん、使わない理由が標準ライブラリの脆弱性を回避するために、という明らかな理由が
示された上でなら話は違うけど、そういう特殊条件でもなければ自分でシコシコ組み立てるより
ライブラリがシコシコ組み立てる擬似PreparedStatementであれ、使わない理由は小さいと思う。
Re:PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1)
PreparedStatement を使っていても危険な場合で、自分が知っている範囲だと。
LIKE 演算子の場合は SQL インジェクションとは言わないのかもしれませんが、サーバーの負荷を上昇させたりはできなくはないと思うのですよ。
個人的にはですね。SQL インジェクション云々以前に、' を入力したらエラーになるのを仕様とか言い張るのがどうかしているんじゃないかと思うのですよ。' は入力しないで! ってマニュアルに一言書くだけじゃんと言われてしまったり。
Re:PreparedStatementを使ってもSQLインジェクションの危険はあるの？ (スコア:1)
てか、ストアドのパターンは想定してなかった。たしかに、ストアドでSQL文生成してるパターンもありうるよなぁ。
Re: (スコア:0)
SaaSってるならわかりますが、それならそもそもoracle云々ってなりませんよね。
Re:SQLは人が手で入力して使うツール (スコア:1)
直結していなくても, フロントエンドを一枚かましてバックでOracleなんてのは普通ですよ. いわゆる3階層(バックエンドDB, アプリケーションサーバ, Webブラウザ)構成システムってやつです. よく/.Jのコメントで「社内システムがIE6までしか対応していない」とかの話が出たらこの類と考えて良いでしょう. また保険会社なんかの小規模の代理店・取引先が多いB2Bシステムでは, 閉じたネットワークではなく通常のインターネットで接続していることも多いと思われます.
Re:SQLは人が手で入力して使うツール (スコア:2, おもしろおかしい)
---- 末は社長か懲戒免職 なかむらまさよし
Re:SQLは人が手で入力して使うツール (スコア:1, 興味深い)
プログラム内部で”変数”と”命令”を明確に意識していない
人が多すぎます。
SQLしかり、コマンドインジェクションしかり。
ORACLEのようにprepare効果でないmysqlとかでも
キチンとバインド変数つかって、SQL文と、それに与える値を
意識してわけて使用し、利用していればDBへの橋渡しをする
部分で吸収してくれることがおおいのに。
（もちろんそれで完全にふせげるなんておもってないけど
あんまり知識ない人でもそれだけで防げること多いと思います）
perlでコマンド実行でも\Q\Eでくくって記号を\して、
命令と”引数”を明確にわけるだけでも危険をへらせるのに、
どうにもかんにも。
すこし変えればすむことなんですけど、そういうコードを
かくひとにかぎって、何の根拠にもなっていない言い分で
ぜんぜんなおそうとしてくれないのでツライですねぇ・・・
Re:SQLは人が手で入力して使うツール (スコア:1, 興味深い)
変数と命令…とまで極端なことは言わないにせよ、
言語内の色々な部分を
「めんどくさいから文字列でばばっと書いちゃえ(る)」
ってのがスクリプト言語の「メリット」だと思います。
で、そういう意味ではSQLももろにスクリプト言語の一種。
＃そういえば羽生氏はSQLについて「非技術者でも書けるのがいい」とかいってたよな。
Re: (スコア:0)
Re:SQLは人が手で入力して使うツール (スコア:1)
1. とりあえずJava言語を覚えさす
2. とりあえずSQLを覚えさす
3. JDBCでJava→SQL→DBというルートが可能であることを示す
...ここでやめちゃうと、平気でSQLインジェクション非対応のアプリ書いちゃいますよね。大概この後に
4. PreparedStatementやCallableStatement(ストアードプロシジャ)もあるよー
というのは話があるんだけど、実効上そんなに差がないよってことだと、ひとまず最初に覚えたやり方をずっと引きずっちゃったりするわけで。
つーわけで個人的には
5. セキュリティとの兼ね合い上、Statementはヤバい(場合がある)
ってのを話すようにしてたんですが、どれほど効果があったかな...
これから教える人は、
- 生JDBCはdark side forceである
- 標準化されたORマッピングを採択すべき
ってのをきちんと説明してあげてほしいですね。
Re: (スコア:0)
Re:SQLは人が手で入力して使うツール (スコア:1)
意味もわからず、今まで同様SQLを毎回組み立ててる大馬鹿者が。。。。
理解できている人にDB IO部分をまかせて隠ぺいさせるか、O/Rマッパーでも使うのが一番かも
Re:SQLは人が手で入力して使うツール (スコア:3, 参考になる)
余談ですが，暗黙の型変換についても気にしてない（気づいてない？）と思われるコードをよく見かけます。
# ちょっと前に，OpenOLAP を PostgreSQL 8.3系で動作させようとしましたが，修正箇所多くて諦めました・・・。
> 理解できている人にDB IO部分をまかせて隠ぺいさせるか
Oracleであれば，
- まず仕様書からDBインターフェース部分を抜き出し，RefCursorを返すFunctionやUpdateを行うProcedureをPackageでまとめて先に実装する。
- P層，F層プログラマにはそのPackageを提供し，SQL文は一切書かせない。
というのが性能面からも理想的ですが，いわゆる「理解できている人」が少なすぎで，実現した試しがありません。Re: (スコア:0)
DBのアクセスに限らず、「低レベル技術者でも安全に使える共通部品を先行開発」というアイディアを完遂できたプロジェクトって少ない気が。ないことはないんだけど。
でもって個人の独自実装による品質のばらつきが発生し後々の苦労が絶えない。
マネージャーが重要性を解ってないのだろうか…
Re: (スコア:0)
でも、「一時的に完遂」しても気がつくと変なフレームワークになって、
人が移動したら誰も解らなくなって、でもプロジェクトは進んでいって、
個々の拡張でドキュメンテーションは追いつかないとなっていくと。
結局、人の階層や時間軸で見ていくと、「個人の独自実装による品質のばらつきが発生しない」っていうのは、
プロジェクトと名づけられ複数の人間が多岐に渡って関係する場合、「銀の弾丸」に他ならないでしょうね。
>マネージャーが重要性を解って
こうですか？ (スコア:1, 興味深い)
「データベースの空間閉鎖も、情報封鎖も甘い。だから私に気づかれる。侵入を許す」
「あなたは私のバックアップデータベースのはず」
「SELECT パスワード FROM データベース WHERE うんたらかんたら。
当該対象のDBA権限を解除する」
「わたしの負け。よかったね、クラック出来て。でも気を付けてね。
統合データベースは、この通り、一枚岩じゃない。」
Re:こうですか？ (スコア:1)
# あの作品世界では神に相当するアレに次ぐ力をもってるからなぁ。
# 人間の作ったセキュリティなんてちり紙ほどの役にもたたんだろう。
Re: (スコア:0)
まともにプログラム作ってたら、カメラでチートしてるのを確認でもしないかぎり
「相手には自機の姿が丸見え」なんてわからない
# プログラム的には知ってて、ユーザに見せないって実装するよね、普通。
# テーブルゲームなんかの COM ルーチンも「知ってるけど知らないふり」したりとか
## のぞき見して貧弱な思考ルーチンを補佐するっていう COM ルーチンのもあるけど。
4月に急増か・・・ (スコア:1)
Re:4月に急増か・・・ (スコア:1)
や、知らんけど。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re: (スコア:0)
新人社員い攻撃させるって・・・中国かな。
Re: (スコア:0)
>iLogScannerでの解析によると、4月、5月にアタックが増えている
これの公開が4/18ですから、それで潜在的な攻撃が浮かび上がったという事では？
背景にオンラインゲームのBOT対策強化の影響 (スコア:1)
中国のRMT業者（Gold Famer）がゲーム内でBOTを運用してゲーム通貨を稼いで、それを現実通貨で販売することが難しくなってきています。
そこで、ゲーム内で使えるアイテムの現金販売を狙って、3Dセキュアのクレジットカードの番号、有効期限、IDとパスワード抜き取り、その情報で第三者に成りすまして、アカウント取得・課金を行い、3Dセキュアのクレジットカードで購入したアイテムをゲーム内で販売、その売上げのゲーム内通貨をプレイヤー、RMT仲介業者などに売って、現金を獲得するという手段に出たようです。
SQLインジェクション脆弱性さえあれば情報を引くのは簡単？ (スコア:1)
そこから有用な情報を引くにはスキーマ情報とか知らないと難しいなぁ。。。と
なんとなく思っていたのですが、
任意の SQL文実行できるようになれば次はスキーマ情報を取りに行き、
その上でデータをとるようにすればいいやん。自動化も簡単やん。
・・・と思いいたって今更ながらガクブルしてます。
マクロの基本は検索置換(by y.mikome)
部門名 (スコア:0)
「気をつけろ、奴」と来れば、「気をつけろ、奴はスナッチャーだ！」でしょう常考。
Re:部門名 (スコア:1)
頭の中で懐かしいSCCサウンドが流れました。
# スナッチャーって、言ってみれば手がかかった
# 過激なソーシャルハッキングですよね。