アカウント名:
パスワード:
null で空文字列を意味するというのは、そのまんま加工せずにパラメータとして入れ込んでしまっているのではないか? こっちはインジェクション・アタックとか大丈夫なんかいな?
長すぎる方をよく見てみると、名前の途中にアポストロフィが入ってるし。ど初級のSQLインジェクションアタックで最初に試みるのがアポストロフィとか \ エスケープとかだから、たぶん対処はされているんだと信じるが…
物理学の'tHooft先生も、ご自身の名を冠された小惑星について、アポストロフィを削られているから、この小惑星上ではアポストロフィを禁止する、と怒っておられたなあ。
#ハイフン記号とかも名前として入力できないシステムもある。
インジェクションアタック自体は、入力文字をそのままSQLにぶっこむことが問題なので、SQLパラメータにすればシングルクオート付きの名前でも問題ない。Nullって名前でも。
で、入力がNullの時、文字列のNullを返すというインターフェイスで、「Null」ならデータ未入力だという判定ロジックの問題と思われるが、Nullって名前の人がいるというテストはしなかったと言われると、否定出来ない。マジで居るんだなあ。
補足してくださりありがとうございます。お分かりの通り、自分が心配したのはもっともっと初級のミスの方です。パラメタライズドSQLなど、サーバ側、もしくはライブラリ等が型に合わせて自動的にエスケープ処理をしてくれるなら大丈夫でしょう。入力としても文字列としてのNullというものなら、それは文字列として解釈してくれるだろうと思います。いくらなんでも。だよね。きっと。
>パラメタライズドSQLその言葉も#2988855の道をたどるよ。♯DellのIT部門吸収したとこでの実話
他にどういう名前がまずいの?未定義さんとかいたら問題起こる?
とある会社のWebサイトで、外部と連携してる(顧客から申し込みがあると外部サイトにも情報を送信する)システムを作ってた頃。自システムの文字コードがUTF-8、連携先のシステムがEUC-jpで動いてたんだ。
で、名字がJISの第3水準だか第4水準だかの文字(1文字)の人が申し込みしたとき、変換インターフェースが空文字に置き換えた挙げ句、連携先のサーバーアプリが所謂「ぬるぽ」で落ちて騒ぎになったことはある。
そういや Mailman-jp は UTF-8 に公式対応したのかな。
javascript処理系ならundefinedさんあたりは問題になりそう。
どちらのjavascriptでどう組むと問題になりそうなんですか?
書いてみた。間違いに至る例を意図的にかつ再現しやすいよう書くのって難しいね。// input要素nameに値をセットすることを意図したこんな感じの関数があったとしてfunction setHogeText(text) { document.getElementById("name").value = text;}
setHogeText();// こういう記述ミスを防ぎたい(呼び出しに引数が足りてないのでundefinedになる)
// じゃあ検出ロジックを追加しよう!function validateHogeText() { if (document.getElementById("name").value === undefined) {// あれれ、これじゃ検出されないや window.alert("Undefined!"); }
if (document.getElementById("name").value ==="undefined") {// 直したよ!これで検出できるね! window.alert("Undefined!!!"); }}
validateHogeText();// 確かに上記の呼び出しミスは検出できるのだが、nameに「undefined」と入れても検出されてしまう。
あんたひたすら個別具体例を聞きたがってるようけど何ゆえ?
> あんたひたすら個別具体例を聞きたがってるようけど何ゆえ?
自分以外はもう一人しか書き込みしていないと思わないほうがいいです。ありえないから聞いているんでしょう。
文字列のNullで判定なんて普通なことなの?問題になるってことは普通にやってる事なのか。
プログラマが意図してやらなくても、フレームワークや中間のレイヤーが、勝手に'null'をヌルデータに変換したり、ヌルデータと'null'を同一視したりする場合があるのです。
>フレームワークや中間のレイヤーが、勝手に'null'をヌルデータに変換したり、>ヌルデータと'null'を同一視したりする場合があるのです。どちらのフレームワークがそういうことするんですか?
http://stackoverflow.com/questions/4456438/ [stackoverflow.com]の例では、
WSDL (SOAP).Flex 3.5ActionScript 3ColdFusion 8
の組み合わせだったそうです。
「フレームワーク」というのはオープンソースに限らず、開発メーカ謹製の業務パッケージ専用フレームワークというものも存在するのだよ。で、それを外部から来た補給部隊が使うと悲劇が起こる。(内包された爆弾があらわになる、と言うほうが適切かな)
(#2988860) に聞いているんで。
なんというか、こうやって具体的に細かく聞こうとする人って、どこかを攻撃しようとする意思でもあるか、自分が使っている物について調べようとも勉強しようともしない人なのかなぁと思わなくも無いな。
ちょっと普通には聞いたことがない。しかし「政府の納税関連Webサイトなど、ほかのサイトでも同じような問題に悩まされる」というから、何かの共有ライブラリにそうした問題があったのではと推測。
それらの全プログラマがポカだったとはいくらなんでも思えない。しかしテストが足りなかったとは言えるでしょ?
> で、入力がNullの時、文字列のNullを返すというインターフェイスで、> 「Null」ならデータ未入力だという判定ロジックの問題と思われるが、何言語だとこういうこと起きるんですか?
判定ロジックの問題なら言語関係ないだろ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
SQLインジェクションアタックの対象になりかねない (スコア:5, 参考になる)
null で空文字列を意味するというのは、そのまんま加工せずにパラメータとして入れ込んでしまっているのではないか? こっちはインジェクション・アタックとか大丈夫なんかいな?
長すぎる方をよく見てみると、名前の途中にアポストロフィが入ってるし。ど初級のSQLインジェクションアタックで最初に試みるのがアポストロフィとか \ エスケープとかだから、たぶん対処はされているんだと信じるが…
物理学の'tHooft先生も、ご自身の名を冠された小惑星について、アポストロフィを削られているから、この小惑星上ではアポストロフィを禁止する、と怒っておられたなあ。
#ハイフン記号とかも名前として入力できないシステムもある。
Re:SQLインジェクションアタックの対象になりかねない (スコア:1)
インジェクションアタック自体は、入力文字をそのままSQLにぶっこむことが問題なので、
SQLパラメータにすればシングルクオート付きの名前でも問題ない。Nullって名前でも。
で、入力がNullの時、文字列のNullを返すというインターフェイスで、「Null」ならデータ未入力だという判定ロジックの問題と思われるが、
Nullって名前の人がいるというテストはしなかったと言われると、否定出来ない。
マジで居るんだなあ。
Re:SQLインジェクションアタックの対象になりかねない (スコア:1)
補足してくださりありがとうございます。
お分かりの通り、自分が心配したのはもっともっと初級のミスの方です。
パラメタライズドSQLなど、サーバ側、もしくはライブラリ等が型に合わせて自動的にエスケープ処理をしてくれるなら大丈夫でしょう。入力としても文字列としてのNullというものなら、それは文字列として解釈してくれるだろうと思います。いくらなんでも。だよね。きっと。
Re: (スコア:0)
>パラメタライズドSQL
その言葉も#2988855の道をたどるよ。
♯DellのIT部門吸収したとこでの実話
Re: (スコア:0)
他にどういう名前がまずいの?
未定義さんとかいたら問題起こる?
Re:SQLインジェクションアタックの対象になりかねない (スコア:2, 興味深い)
とある会社のWebサイトで、外部と連携してる(顧客から申し込みがあると外部サイトにも情報を送信する)システムを作ってた頃。
自システムの文字コードがUTF-8、連携先のシステムがEUC-jpで動いてたんだ。
で、名字がJISの第3水準だか第4水準だかの文字(1文字)の人が申し込みしたとき、変換インターフェースが空文字に置き換えた挙げ句、連携先のサーバーアプリが所謂「ぬるぽ」で落ちて騒ぎになったことはある。
Re: (スコア:0)
そういや Mailman-jp は UTF-8 に公式対応したのかな。
Re: (スコア:0)
javascript処理系ならundefinedさんあたりは問題になりそう。
Re: (スコア:0)
javascript処理系ならundefinedさんあたりは問題になりそう。
どちらのjavascriptでどう組むと問題になりそうなんですか?
Re:SQLインジェクションアタックの対象になりかねない (スコア:1)
書いてみた。間違いに至る例を意図的にかつ再現しやすいよう書くのって難しいね。
// input要素nameに値をセットすることを意図したこんな感じの関数があったとして
function setHogeText(text) {
document.getElementById("name").value = text;
}
setHogeText();// こういう記述ミスを防ぎたい(呼び出しに引数が足りてないのでundefinedになる)
// じゃあ検出ロジックを追加しよう!
function validateHogeText() {
if (document.getElementById("name").value === undefined) {// あれれ、これじゃ検出されないや
window.alert("Undefined!");
}
if (document.getElementById("name").value ==="undefined") {// 直したよ!これで検出できるね!
window.alert("Undefined!!!");
}
}
validateHogeText();// 確かに上記の呼び出しミスは検出できるのだが、nameに「undefined」と入れても検出されてしまう。
Re: (スコア:0)
あんたひたすら個別具体例を聞きたがってるようけど何ゆえ?
Re: (スコア:0)
> あんたひたすら個別具体例を聞きたがってるようけど何ゆえ?
自分以外はもう一人しか書き込みしていないと思わないほうがいいです。
ありえないから聞いているんでしょう。
Re: (スコア:0)
文字列のNullで判定なんて普通なことなの?
問題になるってことは普通にやってる事なのか。
Re:SQLインジェクションアタックの対象になりかねない (スコア:1)
プログラマが意図してやらなくても、フレームワークや中間のレイヤーが、勝手に'null'をヌルデータに変換したり、ヌルデータと'null'を同一視したりする場合があるのです。
Re: (スコア:0)
>フレームワークや中間のレイヤーが、勝手に'null'をヌルデータに変換したり、
>ヌルデータと'null'を同一視したりする場合があるのです。
どちらのフレームワークがそういうことするんですか?
Re:SQLインジェクションアタックの対象になりかねない (スコア:2)
http://stackoverflow.com/questions/4456438/ [stackoverflow.com]
の例では、
の組み合わせだったそうです。
Re: (スコア:0)
「フレームワーク」というのはオープンソースに限らず、
開発メーカ謹製の業務パッケージ専用フレームワークというものも存在するのだよ。
で、それを外部から来た補給部隊が使うと悲劇が起こる。
(内包された爆弾があらわになる、と言うほうが適切かな)
Re: (スコア:0)
(#2988860) に聞いているんで。
Re: (スコア:0)
なんというか、こうやって具体的に細かく聞こうとする人って、
どこかを攻撃しようとする意思でもあるか、
自分が使っている物について調べようとも勉強しようともしない人なのかなぁと思わなくも無いな。
Re: (スコア:0)
ちょっと普通には聞いたことがない。
しかし「政府の納税関連Webサイトなど、ほかのサイトでも同じような問題に悩まされる」というから、何かの共有ライブラリにそうした問題があったのではと推測。
それらの全プログラマがポカだったとはいくらなんでも思えない。
しかしテストが足りなかったとは言えるでしょ?
Re: (スコア:0)
> で、入力がNullの時、文字列のNullを返すというインターフェイスで、
> 「Null」ならデータ未入力だという判定ロジックの問題と思われるが、
何言語だとこういうこと起きるんですか?
Re: (スコア:0)
判定ロジックの問題なら言語関係ないだろ