【質問】ASP.NETスレ Part7【雑談】 (806ﾚｽ)
上下前次1-新
319(1): 2015/09/11(金)10:57 ID:??? AAS
>>317
それは入力した文字列を実行するんじゃ無いだろ。単におバカプログラマーだ
320(1): 2015/09/11(金)10:58 ID:??? AAS
>>316
何も考えずにそのまま全部表示しようとしたら
スクリプトインジェクション系の攻撃は全部成功だろ
321(1): 2015/09/11(金)10:59 ID:??? AAS
>>318
.csprojファイル編集したら好きなように出来るだろ。どうでもいい変な事を悩むなよ
322(1): 2015/09/11(金)11:00 ID:??? AAS
>>315
すみません、わかりました。
>>314>dll側もデバッグしたいんだろ？
そういうことです。
323(1): 2015/09/11(金)11:01 ID:??? AAS
>>320
表示って、textboxに入力されたら内容をそのままtextboxに表示するだけだぞ。
それで攻撃が完了するのか？
324(1): 2015/09/11(金)11:02 ID:??? AAS
>>321
GUI操作にとらわれずに、自分で、アセンブリ参照を書き換えなさいってことでしょうか。
325(1): 2015/09/11(金)11:06 ID:??? AAS
>>324
書き換えたければそう言う方法もあるっていうだけで、勧めている訳ではないが、設定の多くはcsprojファイルに書かれて居るので、手っ取り早い方法はcsprojの編集だとおもう。
326(1): 2015/09/11(金)11:08 ID:??? AAS
>>319
入力された文字が実行されたり、(インジェクションとか、xss)
入力された文字が「意図された」コードの実行を起こしたり、(>>317)
あくまでコードが正しく実行されて、攻撃が完成する場合は納得できます。
しかし、.net側のセキュリティーホールで、意図しないところで攻撃が実現されてしまうことはあるんでしょうかね。
いままで、フレームワーク上の欠陥で、セキュリティーホールが生じたことってあったのかなあ。
そうでなければ、あとはプログラマの技量だけで、どうにでもなりますよね。
WEBを全世界に公開するのもためらいませんが、,net事態の欠陥で、危ぶまれるのなら、躊躇するなあ。
327(2): 2015/09/11(金)11:09 ID:??? AAS
>>318
そこに書いてあるけど、dll側もデバッグしたいんだろ？
その参照されるdllってのは、元プロジェクトから切り出した部分じゃないのか？
つまり自分で変更するし、変更が反映されないと困るんじゃないのか？
そのdll（のソース）に手を入れない前提なら好きにすればいい
328(2): 2015/09/11(金)11:18 ID:??? AAS
>>323
Textbox.Textはたしか勝手にエンコードするから大丈夫
でも全ての表示できる内容がエンコードされるわけじゃない
たしかLabel.Textは生HTMLで出力する
適切にエンコードした出力すれば大丈夫なんだが、それが難しい
せめて危険かどうかの判断ができるようになるまで、保険的にバリデート外すなって言ってる
まあ、あれ、SQL系のインジェクションにはほとんど無力なんだがな
329(1): 2015/09/11(金)11:21 ID:??? AAS
>>328
>SQL系のインジェクション
この対策は、parameterオブジェクトのaddメソッドで、parameterを追加する方法で、
回避可能だと聞いたことがあります。もちろん、ストアドプロシジャでしか使えないけど。
330: 2015/09/11(金)11:23 ID:??? AAS
>>328
Labelも含めて、ブラウザに出力するコントロールのすべてにおいて、
デフォで、htmlEcodeをかけておいてほしかったな。
必要なら、意識して自分で外せるようにしておいてもらったほうが良かった。
331(1): 2015/09/11(金)11:23 ID:??? AAS
>>326
>net側のセキュリティーホールで、意図しないところで攻撃が実現されてしまうことはあるんでしょうかね。
可能性としては当然ある
>フレームワーク上の欠陥で、セキュリティーホールが生じたことってあったのかなあ。
いくらでもある
何のためにマイクロソフトがいっぱいアップデートパッチ出してると思ってるんだ
少なくともお前や俺がミスってセキュリティホール作る方が
フレームワークの欠陥で穴が見つかるよりよっぽど可能性が高いから心配するな
332: 2015/09/11(金)11:24 ID:??? AAS
>>327
その通りです。すみません、先に>>322にレスしていました。
333: 2015/09/11(金)11:24 ID:??? AAS
>>327
丁寧に、ありがとうございます。
334(3): 2015/09/11(金)11:28 ID:??? AAS
>>331
やはりあったんだ。
せっかくしっかり作りこんでいても、土台でセキュリティーホールがあったら、
どうしようもないな。
今、一つ気になっているのは、クエリストリングの処理。
間違えて、URLとクエリストリングの文字列に、さらにクエリストリングを連結させてしまったら、
ランタイムエラーが出ずに、「,」が復元先のテキストボックスに表示されてしまったよ。
（同名のクエリストリングが重なった状態になったのだと思う。）
クエリストリングも公開WEBアプリには使わないほうがいいと思った。
335(1): 2015/09/11(金)11:29 ID:??? AAS
>>329
ストアドじゃなくてもパラメタは使える
まあ、SQLインジェクションに対してはパラメタ使えってのは鉄則
なんだが、ついつい動的にSQL書いちまうんだよなぁ
336: 2015/09/11(金)11:31 ID:??? AAS
>>325
ありがとうございます。
csprojの編集ということもできるなんて、初めて知ったので、勉強になりました。
337: 2015/09/11(金)11:34 ID:??? AAS
>>335
そうなんですか。Sql server系だったら、@パラメーターを、sql文字列に埋め込んでおいて、
同じ要領で、パラメーターオブジェクトをコマンドオブジェクトに組み込んで、投げることができるんですね。
しかし、sql動的作成だと、パラメーター以外に、インジェクションされる危険が多々ありますよね。
日本語しか入力させないようにしたら少しはましになるのかな。
338(1): 2015/09/11(金)11:34 ID:??? AAS
>>334
それはお前の間違いであって、フレームワークの穴じゃないだろ
そこでクエリストリングの仕様と、起こった事の詳細を解明しようと思わないなら
プログラミングやめた方がいいよ、マジで
上下前次1-新書関写板覧索設栞歴
あと 468 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s