アカウント名:
パスワード:
SQLインジェクションは本質的に「データベースのアクセス権限昇格の脆弱性」であることなのに, 単にサニタイズ問題に矮小化されがちであるのは非常に気になりますねえ...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
だって日本人だもの・・・ (スコア:3, すばらしい洞察)
>と尋ねたところ6割程度の人しか手を挙げなかったのが
知っていても決して手を上げないのが日本人の習性ですから:-
Re:だって日本人だもの・・・ (スコア:3, すばらしい洞察)
とゆう質問の意味を、
・辞書的な意味で、知っている
・骨身に染み付くぐらいに、知っている
・目を瞑ったまま対処できるぐらいに、知っている
等々、どうゆうレベルに取るかによって、
態度が変わる気がします。
// 「お前はSQLを知っているか?」と問われて、
// 躊躇無くyesとこたえられない気がするけどID
Re:だって日本人だもの・・・ (スコア:1, フレームのもと)
単にサニタイズ問題に矮小化されがちであるのは非常に気になりますねえ...
# これに気がついている技術者が少ないことが,特に.
みんつ
Re:だって日本人だもの・・・ (スコア:1)
ストレートに解釈するところの「権限」だとすると、これを「権限昇格」というのはあまり一般的でないような。
Re:だって日本人だもの・・・ (スコア:1)
ご指摘の通り,いわゆるセキュリティの脆弱性で良く表現される「権限昇格」とはニュアンスが違うかもしれませんね.
みんつ
Re:だって日本人だもの・・・ (スコア:1)
これは、理論的には不可能ではないですが、現実には色々と難しいかと。
ポイントはこのあたりです。
例えば、Webアプリから参照しないはずのシステム表などへのSELECT制限やUPDATE制限をかける、ということであれば、
リスク低減の観点からは実施すべきです。これすらやっていなくて被害を拡大している例も確かにあると思います。
(Webアプリからdba権限でDBアクセスさせるような…)
ただし、SQLインジェクションによる脅威は、WebアプリからSELECT/UPDATEしない表に限定されるものではありません。
(ショッピングサイトで他の利用者の注文内容を盗み見る、など)
適切な権限設定によってリスク低減が図れるのは間違いありませんが、本質的な解決はやはり「インジェクションさせない」
ことになるかと思います。
# このへんは先日の日記に書こうか迷ったけど、SQLインジェクションの本質的な解決にはならないので推敲で削除。
Re:だって日本人だもの・・・ (スコア:1)
ただ,レコード単位までアクセス制御がかかれば,ほぼ「SQLインジェクション怖くねー」となりますし,それを実現する ための仕組み (Oracle の FGAC など) も利用できないことはないです.
...つうか「ユーザ毎にアクセス制御しない」「生成される SQL 文を制限させることでアクセスを実現する」のが当然なのであれば,接続時のユーザ/パスワードなんて不要になっちゃいますよね...
逆説的な説明になってしまいましたが
「きちんとアクセス制御を行う」のがデータベースの使い方としては常道であり,性能等の問題が出た場合に「安全性とのトレードオフを熟慮した上で慎重な実装」にて行う,というのが原則だと思うのです.
前段の論議ヌキに最後の「慎重な実装」という対策部分だけが語られがちであることが気になっています.
みんつ
Re:だって日本人だもの・・・ (スコア:0)
Re:だって日本人だもの・・・ (スコア:1)
サイトの安全性を考えるならば,小手先の入口対策より根本対処にて対応すべきでしょう.
他の方の投稿にもありますように,理想的にはそうであってもなかなか難しい,と言うのには納得しますが,だからと言って「結果でしかない」と短絡するのには違和感があります.
みんつ