facebook twitter hatena line google mixi email
★お気に入り追加


  • 1
  •  
  • 2012/07/26(木) 14:55:28.26
ASP.NETとは、マイクロソフトが提供するWeb アプリケーションと XML Web サービスを構築するための
Microsoft .NET Frameworkの一連のテクノロジの一つです。
技術の移り変わりの早い分野ですので、みんなで質問、相談しつつ、より理解を深めていきましょう。

●ASP.NET関連サイト
マイクロソフトASP.NETデベロッパーセンター
http://msdn.microsoft.com/ja-jp/asp.net/default.aspx
ASP.NETオフィシャル(英語)
http://www.asp.net/
VisualStudioホームページ
http://www.microsoft.com/japan/msdn/vstudio/
SQLServerホーム
http://www.microsoft.com/japan/sqlserver/2005/default.mspx
IISオフィシャル(英語)
http://www.iis.net/
ASP.NETにAJAX技術を取り入れるASP>NET AJAX(英語)
http://www.asp.net/ajax/
ASP.NETにMVCアーキテクチャを取り入れるASP.NET MVC(英語)
http://www.asp.net/mvc/
ASP.NETでのお役立ちの定番サイト
http://www.atmarkit.co.jp/channel/aspnet/aspnet.html

ここまで見た
  • 316
  •  
  • 2015/09/11(金) 08:56:35.24
>>312
いや、たぶん、クライアントサイドでバリデーションするとか言う話ではなく
標準でポスト時にかってにポストデータ検証される機能の事だと思うぞ

まあWebアプリのセキュリティについて勉強しろってのは激しく同意するが

ここまで見た
  • 317
  •  
  • 2015/09/11(金) 09:05:52.66
>>314
>入力した文字列を、表示しようとしただけで攻撃が成功する可能性
そんな文字列あるんか?

ここまで見た
  • 318
  •  
  • 2015/09/11(金) 10:47:18.05
HTMLENCODEでほぼ解決!
あとは、致命的なバグだろうな。

if (inputvalue == "reset")
{
Reboot;
}

こういうバックドアを書いていたら、入力される文字列で攻撃が完成する。

ここまで見た
  • 319
  •  
  • 2015/09/11(金) 10:54:48.55
>>305>>315
レスいただきありがとうございます。

アセンブリを参照するための方法として、二つあるってこと?

1、dllファイルのみを、参照する側のプロジェクトにコピー
2、プロジェクトフォルダごと、参照する側のプロジェクトから参照する設定を加える


考えられたこととして、
2、の場合だと、被参照プロジェクトでバージョンアップしたとき、
参照側のプロジェクトに影響する。
もちろん、良い意味と、悪い意味と、両方。

1、の場合だと、
被参照プロジェクト側がどう変更されようが、参照側のプロジェクトには一切の影響がない。


なぜ、>>315さんは、2の方法を推薦するのか、知りたいです。

ここまで見た
  • 320
  •  
  • 2015/09/11(金) 10:57:12.83
>>318
それは入力した文字列を実行するんじゃ無いだろ。単におバカプログラマーだ

ここまで見た
  • 321
  •  
  • 2015/09/11(金) 10:58:01.51
>>317
何も考えずにそのまま全部表示しようとしたら
スクリプトインジェクション系の攻撃は全部成功だろ

ここまで見た
  • 322
  •  
  • 2015/09/11(金) 10:59:45.11
>>319
.csprojファイル編集したら好きなように出来るだろ。どうでもいい変な事を悩むなよ

ここまで見た
  • 323
  •  
  • 2015/09/11(金) 11:00:20.66
>>316
すみません、わかりました。

>>315>dll側もデバッグしたいんだろ?

そういうことです。

ここまで見た
  • 324
  •  
  • 2015/09/11(金) 11:01:42.41
>>321
表示って、textboxに入力されたら内容をそのままtextboxに表示するだけだぞ。
それで攻撃が完了するのか?

ここまで見た
  • 325
  •  
  • 2015/09/11(金) 11:02:42.82
>>322
GUI操作にとらわれずに、自分で、アセンブリ参照を書き換えなさいってことでしょうか。

ここまで見た
  • 326
  •  
  • 2015/09/11(金) 11:06:14.13
>>325
書き換えたければそう言う方法もあるっていうだけで、勧めている訳ではないが、設定の多くはcsprojファイルに書かれて居るので、手っ取り早い方法はcsprojの編集だとおもう。

ここまで見た
  • 327
  •  
  • 2015/09/11(金) 11:08:44.80
>>320
入力された文字が実行されたり、(インジェクションとか、xss)
入力された文字が「意図された」コードの実行を起こしたり、(>>318)
あくまでコードが正しく実行されて、攻撃が完成する場合は納得できます。

しかし、.net側のセキュリティーホールで、意図しないところで攻撃が実現されてしまうことはあるんでしょうかね。

いままで、フレームワーク上の欠陥で、セキュリティーホールが生じたことってあったのかなあ。
そうでなければ、あとはプログラマの技量だけで、どうにでもなりますよね。
WEBを全世界に公開するのもためらいませんが、,net事態の欠陥で、危ぶまれるのなら、躊躇するなあ。

ここまで見た
  • 328
  •  
  • 2015/09/11(金) 11:09:15.51
>>319
そこに書いてあるけど、dll側もデバッグしたいんだろ?

その参照されるdllってのは、元プロジェクトから切り出した部分じゃないのか?
つまり自分で変更するし、変更が反映されないと困るんじゃないのか?
そのdll(のソース)に手を入れない前提なら好きにすればいい

ここまで見た
  • 329
  •  
  • 2015/09/11(金) 11:18:24.45
>>324
Textbox.Textはたしか勝手にエンコードするから大丈夫
でも全ての表示できる内容がエンコードされるわけじゃない
たしかLabel.Textは生HTMLで出力する
適切にエンコードした出力すれば大丈夫なんだが、それが難しい
せめて危険かどうかの判断ができるようになるまで、保険的にバリデート外すなって言ってる

まあ、あれ、SQL系のインジェクションにはほとんど無力なんだがな

ここまで見た
  • 330
  •  
  • 2015/09/11(金) 11:21:14.53
>>329
>SQL系のインジェクション

この対策は、parameterオブジェクトのaddメソッドで、parameterを追加する方法で、
回避可能だと聞いたことがあります。もちろん、ストアドプロシジャでしか使えないけど。

ここまで見た
  • 331
  •  
  • 2015/09/11(金) 11:23:10.39
>>329
Labelも含めて、ブラウザに出力するコントロールのすべてにおいて、
デフォで、htmlEcodeをかけておいてほしかったな。

必要なら、意識して自分で外せるようにしておいてもらったほうが良かった。

ここまで見た
  • 332
  •  
  • 2015/09/11(金) 11:23:57.25
>>327
>net側のセキュリティーホールで、意図しないところで攻撃が実現されてしまうことはあるんでしょうかね。
可能性としては当然ある
>フレームワーク上の欠陥で、セキュリティーホールが生じたことってあったのかなあ。
いくらでもある
何のためにマイクロソフトがいっぱいアップデートパッチ出してると思ってるんだ

少なくともお前や俺がミスってセキュリティホール作る方が
フレームワークの欠陥で穴が見つかるよりよっぽど可能性が高いから心配するな

ここまで見た
  • 333
  •  
  • 2015/09/11(金) 11:24:00.12
>>328
その通りです。すみません、先に>>323にレスしていました。

ここまで見た
  • 334
  •  
  • 2015/09/11(金) 11:24:35.61
>>328
丁寧に、ありがとうございます。

ここまで見た
  • 335
  •  
  • 2015/09/11(金) 11:28:27.71
>>332
やはりあったんだ。
せっかくしっかり作りこんでいても、土台でセキュリティーホールがあったら、
どうしようもないな。

今、一つ気になっているのは、クエリストリングの処理。
間違えて、URLとクエリストリングの文字列に、さらにクエリストリングを連結させてしまったら、
ランタイムエラーが出ずに、「,」が復元先のテキストボックスに表示されてしまったよ。
(同名のクエリストリングが重なった状態になったのだと思う。)

クエリストリングも公開WEBアプリには使わないほうがいいと思った。

ここまで見た
  • 336
  •  
  • 2015/09/11(金) 11:29:37.54
>>330
ストアドじゃなくてもパラメタは使える
まあ、SQLインジェクションに対してはパラメタ使えってのは鉄則

なんだが、ついつい動的にSQL書いちまうんだよなぁ

ここまで見た
  • 337
  •  
  • 2015/09/11(金) 11:31:37.89
>>326
ありがとうございます。
csprojの編集ということもできるなんて、初めて知ったので、勉強になりました。

ここまで見た
  • 338
  •  
  • 2015/09/11(金) 11:34:24.22
>>336
そうなんですか。Sql server系だったら、@パラメーターを、sql文字列に埋め込んでおいて、
同じ要領で、パラメーターオブジェクトをコマンドオブジェクトに組み込んで、投げることができるんですね。

しかし、sql動的作成だと、パラメーター以外に、インジェクションされる危険が多々ありますよね。
日本語しか入力させないようにしたら少しはましになるのかな。

ここまで見た
  • 339
  •  
  • 2015/09/11(金) 11:34:39.50
>>335
それはお前の間違いであって、フレームワークの穴じゃないだろ

そこでクエリストリングの仕様と、起こった事の詳細を解明しようと思わないなら
プログラミングやめた方がいいよ、マジで

ここまで見た
  • 340
  •  
  • 2015/09/11(金) 11:40:35.17
>>339
ポストバックされたページから、urlをつかんだら、すでにクエリストリングが含まれているんですよね。
そこからクエリストリングを切断したうえで、新たなクエリストリングを連結させる必要があったんですよ。
ここまでが、MS提供のライブラリを使うプログラマの範囲かなと思うんです。

しかし、なぜ、同名のクエリストリングが重なったら、おかしい文字列が取得されるのかは、
ライブラリ内の話になるので、追及できません。それとも、逆アセンブリするんでしょうか。

同じ問題が生じないように、対策を立てることくらいはできますけどね。
値を取得する前に、クエリストリングのキーがダブっていないか、検査するとか。
例外を投げてほしかったな。

ここまで見た
  • 341
  •  
  • 2015/09/11(金) 12:01:24.14
>>340
>なぜ、同名のクエリストリングが重なったら、おかしい文字列が取得されるのか
コード見ないとわからんが、まあ多分、お前の取得の仕方が悪いだけ

お前が勝手に同名のクエリ文字列は存在しないと思いこんでるだけで
それ前提で作れば、当然おかしな動作するわな

HttpRequest.QueryStringの戻りはNameValueCollection
NameValueCollection.Itemの戻りは、指定したキーに関連付けられた値のコンマ区切りのリストを格納する String

おかしな文字列でもなんでもなく正しく動いてるようにみえるな

ここまで見た
  • 342
  •  
  • 2015/09/11(金) 22:05:09.15
>>341
キーの話だけじゃないんだ。
?もダブっている。

http://honyarara.com?key1=asdf&key2=werf?key1=fafag&key2=greasge

こんな感じで、?からダブっているイメージ。

こんなurlでpageへポストバックして、querystringのコレクションを読み出すけど、
例外が発生しないわけなんだよ。

もちろん、querystringを作成する処理にバグを発生させてしまっていたので、
修正したのだけれど。

ここまで見た
  • 343
  •  
  • 2015/09/11(金) 22:08:03.17
>>342
honyararaって、実在サイトだった!
私とは関係ないので、あしからず。

ここまで見た
  • 344
  •  
  • 2015/09/11(金) 23:35:17.27
>>342
例外を発生させるべき理由なんてないけど?

おかしいのはお前の理解
まさに、お前の思った通りに動かなくてもお前がプログラムした通り動いてる

ここまで見た
  • 345
  •  
  • 2015/09/12(土) 03:29:53.07
初歩的な質問なのですが、
VSのソリューションMyHomePageというのを作って
Default.aspx
sub1/Default1.aspx
sub2/Default2.aspx
のようなディレクトリ構成で、それを発行して
www.example.com/MyHomePage/   (1)
に配置しました。その時
www.example.com
にアクセスした場合に、
www.example.com/MyHomePage/Default.aspx   (2)
を開くにはどういう方式を使うのが一般的ですか?
現状では、
www.example.com/index.html   (3)
を作成してその中で(2)にredirectしています。でもこれだと、
www.example.com/sub1/
にアクセスすると当然エラーしてしまいます。

ここまで見た
  • 346
  •  
  • 2015/09/12(土) 06:31:37.00
>>344
感情的にならずに、何がどうおかしいのか、論破すべきだよ

ここまで見た
  • 347
  •  
  • 2015/09/12(土) 10:33:50.88
>>345
IISの設定をみなおしあ

>>342
なんで「?」が二重にあるの

ここまで見た
  • 348
  •  
  • 2015/09/12(土) 10:47:50.95
>>346
横からだけど・・・

HttpRequest.QueryString
https://msdn.microsoft.com/ja-jp/library/system.web.httprequest.querystring(v=vs.110).aspx
NameValueCollection
https://msdn.microsoft.com/ja-jp/library/system.collections.specialized.namevaluecollection(v=vs.110).aspx

そんな例外は仕様に書かれていないし、「例外が発生しない」ものはしない。
無い物ねだりをしているのは >>346 であって、その例外が発生すべき理由を論理的に説明できていない。
(>>335の内容がASP.NETの挙動として何がおかしいのか分からない。アプリケーション的に問題のあるPOST内容をエスケープできてないだけ)

ASP.NETの仕様に提案があればMSは受け付けているし、そっちでどうぞ。
それも嫌だったら、「俺の考えた最強のセキュリティー機能搭載フレームワーク」を独自開発してくれって話だ。
馬鹿なPHPerがよく陥りやすい思考回路だけどね。

ここまで見た
  • 349
  •  
  • 2015/09/12(土) 16:11:02.27
>>345
でもこれだとって、それ別の話なんだが
とりあえずsub1にもindex.html作っとけば

ここまで見た
  • 350
  •  
  • 2015/09/12(土) 16:13:21.74
>>346
>>341,343

ここまで見た
  • 351
  •  
  • 2015/09/12(土) 16:32:22.58
>>348
仕様的におかしなことをしたからって、全てが例外を吐くとは限らんけどな
だから、おかしいと思ったらまず仕様を確認してそれに則ってるか確認するべき

で、おそらく>>335はクエリストリングの仕様を正しく理解してない。さんざん言われてるのに
>>346は多分別人だろ

ここまで見た
  • 352
  •  
  • 2015/09/12(土) 16:37:22.78
>>349
そう言う方法ではサブフォルダが増える度にredirect設定が必要じゃん。そうでは無くてasp.netの仮想デレクトリとかそう言う機能で出来るかな?

ここまで見た
  • 353
  •  
  • 2015/09/12(土) 18:41:12.31
>>352
仮想ディレクトリはASP.NETじゃなくてIISの機能
フォルダのデフォルトページと、ページが見つからなかった場合の処理は別の話なんだが

とりあえずIISかASP.NETかで404エラー捕まえて何とかすりゃ良いんじゃね

ここまで見た
  • 354
  •  
  • 2015/09/12(土) 19:42:49.81
>>351
定義されてない例外は起きないと言ってるのに、どうしたの?
黙っててくれるかな?

ここまで見た
  • 355
  •  
  • 2015/09/12(土) 19:51:25.46
>>353
>404エラー捕まえて何とかすりゃ良いんじゃね
そんな方法ってあり?
もっと正統的な方法があると思うのだがググッテも見つからん。

ここまで見た
  • 356
  •  
  • 2015/09/12(土) 19:56:30.79
>>354
定義されていないから、例外として捕捉されるんじゃないの??

ここまで見た
  • 357
  •  
  • 2015/09/12(土) 20:01:11.83
>>356
そんな難しい話は置いといて344お願いしますだ。

ここまで見た
  • 358
  •  
  • 2015/09/12(土) 20:15:43.51
>>357
このあたり、ヒントになるんでは?
http://forums.iis.net/t/1209305.aspx?How+to+redirect+all+pages+from+a+subdirectory+to+the+root+directory+

あとで、できたか報告おねがいします!

ここまで見た
  • 359
  •  
  • 2015/09/12(土) 20:37:25.74
>>356
え?こういう例外が起きますよ、ってMSDNに書いてあるよね。
それ以外に例外は起きようがない。
マニュアルも読めないなら黙っとけ(笑)

ここまで見た
  • 360
  •  
  • 2015/09/12(土) 20:37:28.71
>>358
情報ありがとう!
でも、この情報では、
 http://nonghoc.com/nonghoc/Default.aspx - > http://nonghoc.com/Default.aspx
のようにサブフォルダーへのアクセスをRootにリダイレクトする設定のようです。
私のやりたいのはその逆でRootへのアクセスをサブフォルダーへリダイレクトなので、
 http://nonghoc.com/Default.aspx  - >  http://nonghoc.com/nonghoc/Default.aspx
になるから、逆のような気がする。難しい。

ここまで見た
  • 361
  •  
  • 2015/09/12(土) 20:46:12.20
>>360
ありがとう。
じゃあ、ここも?

https://host4asp.net/top-iis-rewrite-rules/

ここまで見た
  • 362
  •  
  • 2015/09/12(土) 20:47:09.00
>>359
自分で、例外投げることにするわ

ここまで見た
  • 363
  •  
  • 2015/09/12(土) 20:53:35.98
>>361
君は検索の達人か!
飯食った後でじっくり読んでみるよ。有難う。

ここまで見た
  • 364
  •  
  • 2015/09/12(土) 22:50:07.66
>>362
それでええんやで
フレームワークから得ている恩恵を顧みずに勉強不足を棚に上げて、文句ばかり言わないように。

ここまで見た
  • 365
  •  
  • 2015/09/12(土) 23:15:30.52
>>364
あなたの論理とは違うところで、そういう判断に至ったわけなので、
「それでいいんやで」なんて、気持ちの悪くなるようなこと言わないでください
わたしは、あなたの例外だ。しかも、捕捉もできない型なんでw

ここまで見た
  • 366
  •  
  • 2015/09/12(土) 23:29:08.38
>>365
アプリケーション的にそうせざるを得ないだけでしょ?

.NETにセキュリティ的に不安があるんじゃなかったの?どういう思考回路でこのまま.NETでいくことにしたの?君のアプリのセキュリティは万全になったかな?
おじさん心配だよ〜

ここまで見た
  • 367
  •  
  • 2015/09/13(日) 02:24:04.28
>>354
定義されてない例外が起きるなんて誰か言ってるか?
>>351は全ての仕様違反に対して例外が定義されてるわけではないって話だが

まあ、例外定義どころか仕様違反ですらないのに例外が発生しないとかいう人もいたが

砂時計アラームタイマー
フリックゾンビ
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email