【質問】ASP.NETスレ Part7【雑談】 [sc](★0)
-
- 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
-
- 290
- 2015/09/09(水) 12:50:52.32
-
>>288
＞これって、ajaxの定義範囲から外れて定義されているとかない？
それはどうやって調べれば分かりますか？
<asp:TextBox ...
みたいに頭に<aspがついていますがこれでいいんでしょうか?
-
- 291
- 2015/09/09(水) 12:53:04.98
-
>>289
一度、新しくWEBページを作成して、
テストコードを入力したほうが早いと思うよ。
なんか、ajax関係の動作が噛んでおかしくなっていそう。（ScriptManagerはその役割を担っている）
おっしゃっている、テスト動作は、ふつう、問題なくできるよ。
page_loadや、button_clickサーバイベントハンドラで取得するんでしょ。
問題ないはず。
-
- 292
- 2015/09/09(水) 13:47:22.14
-
>>291
ありがとうございました！
新規にやり直したら、うまく行きました。
ASP.NETやっている人はみんな親切でいいなあ。
-
- 293
- 2015/09/09(水) 19:09:07.36
-
また質問なんですが、
WebForm1を実行すると以下のような順番でイベントが発生するようです。
C#のPage_Init()
C#のPage_Load()
$(document).ready()
$(window).load()
C#側では IsPostBack == true と言う判定を使えばPostBackかどうか分かりますが、
クライアントサイドでも同じような判定は可能でしょうか？
要するに最初にWebForm1を開いて$(document).ready()など実行される場合と、
それ以降に$(document).ready()が実行される場合を区別出来ますか？
-
- 294
- 2015/09/09(水) 21:06:10.84
-
>>293
というか、getと、postしかないから、
クライアントサイドからどうのこうのという場合は、常にpostなのでは？
-
- 295
- 2015/09/09(水) 22:07:53.25
-
さわりはじめだから右も左もわからんのだろう
-
- 297
- 2015/09/09(水) 22:41:31.76
-
>>294
常にpostだってのが、フォームをsubmitするメソッドの事を言ってるのなら
getでポストバックさせることもできるぞ
クライアントサイドからのアクションはポストバックにきまってるだろっていうならまあその通りか
ただ$(document).ready()とかは初回表示時もポストバック時も非同期ポストバック時も発生するから
-
- 298
- 2015/09/09(水) 22:52:30.01
-
>>297
>ただ$(document).ready()とかは初回表示時もポストバック時も非同期ポストバック時も発生するから
それをクライアントサイドで区別したいんですが、無理ですか？
-
- 299
- 2015/09/09(水) 23:07:28.40
-
>>298
よくわからんが、初回表示した時と、なんらかのアクション後（POST BACK後）をクライアントサイドでも区別したいということかな？
多分、サーバー側でその状態をJavaScriptとして書き出せばできるんじゃなかろうか。
-
- 300
- 2015/09/10(木) 00:46:07.45
-
PageRequestManager使えって言ってるだろ
-
- 301
- 2015/09/10(木) 00:57:16.83
-
>>296
知らない奴に限って要領を得ない事をグダグダ書くんだよな
-
- 302
- 2015/09/10(木) 02:47:26.43
-
そりゃ要点をちゃんと抑えて整理出来るなら自分で解決できてるだろうからな
-
- 303
- 2015/09/10(木) 10:43:52.19
-
>>284
ありがとうございます。
できました！
しかし、objフォルダと、binフォルダと、どう違うんでしょうか。
両方に、同じ名称で同じサイズのdllがあったんですが。
objフォルダに入っているdllを、参照設定しましたけど。
-
- 304
- 2015/09/10(木) 14:50:56.21
-
iisとasp.netでwebサイト作った場合、物凄く負荷が大きい時に誤動作してAさん向けのページがBさんに表示されるなんて事は無いですか？
-
- 305
- 2015/09/10(木) 16:43:44.33
-
>>303
dllを参照するんじゃなくて、そのdllを作るプロジェクトを参照するんだぞ
-
- 306
- 2015/09/10(木) 16:47:00.31
-
>>304
高負荷でそんな「誤動作」するとか見たことも聞いたことも無いわ
-
- 307
- 2015/09/10(木) 17:42:17.23
-
TextBoxに文字貼り付けるとValidationが反応して怒られる場合有りますよね。
これを無効化するとどう言う危険性が有るんですか?
貼られた文字列を実行する処理など入れて無ければ問題無いですよね？
-
- 308
- 2015/09/10(木) 20:19:54.23
-
>>304
そんなの有ったとしてもアプリケーション側のバグでしょ
-
- 309
- 2015/09/10(木) 21:16:32.20
-
>>305
プロジェクトフォルダ内にあるobjフォルダのアセンブリ（dll）自体を参照させたら、
参照側プロジェクトにdllファイルが自動的にコピーされたんだけど。
-
- 310
- 2015/09/10(木) 21:25:25.32
-
>>304
プログラマらしからぬ発言
-
- 311
- 2015/09/11(金) 00:07:58.84
-
>>307
その程度の認識だとXSSの考慮が漏れてそう・・。
まあ出力時にエスケープが徹底されていれば問題ないけど。
-
- 312
- 2015/09/11(金) 00:32:57.40
-
クライアントサイドのバリデーションは所詮はユーザビリティ向上くらいの意味だから
切りたければ切っても良いと思うけど、Webアプリまわりのセキュリティについて一度勉強した方が良いのでは。
-
- 313
- 2015/09/11(金) 08:30:34.05
-
>>312
モデルクラスで解決すべき問題だと認識されていますか
-
- 314
- 2015/09/11(金) 08:53:49.76
-
>>307
入力した文字列を、表示しようとしただけで攻撃が成功する可能性があるから
よくわからんならそのままにしとけ
-
- 315
- 2015/09/11(金) 08:54:43.48
-
>>309
参照にはローカルコピーするかどうかの設定があるわけだが
コピーされたからどうだと？
dll側もデバッグしたいんだろ？素直に言われた通りやっとけ
-
- 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
レスいただきありがとうございます。
アセンブリを参照するための方法として、二つあるってこと？
１、dllファイルのみを、参照する側のプロジェクトにコピー
２、プロジェクトフォルダごと、参照する側のプロジェクトから参照する設定を加える
考えられたこととして、
２、の場合だと、被参照プロジェクトでバージョンアップしたとき、
参照側のプロジェクトに影響する。
もちろん、良い意味と、悪い意味と、両方。
１、の場合だと、
被参照プロジェクト側がどう変更されようが、参照側のプロジェクトには一切の影響がない。
なぜ、>>315さんは、２の方法を推薦するのか、知りたいです。
-
- 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ファイル編集したら好きなように出来るだろ。どうでもいい変な事を悩むなよ
-
- 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側のセキュリティーホールで、意図しないところで攻撃が実現されてしまうことはあるんでしょうかね。
可能性としては当然ある
>フレームワーク上の欠陥で、セキュリティーホールが生じたことってあったのかなあ。
いくらでもある
何のためにマイクロソフトがいっぱいアップデートパッチ出してると思ってるんだ
少なくともお前や俺がミスってセキュリティホール作る方が
フレームワークの欠陥で穴が見つかるよりよっぽど可能性が高いから心配するな
-
- 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提供のライブラリを使うプログラマの範囲かなと思うんです。
しかし、なぜ、同名のクエリストリングが重なったら、おかしい文字列が取得されるのかは、
ライブラリ内の話になるので、追及できません。それとも、逆アセンブリするんでしょうか。
同じ問題が生じないように、対策を立てることくらいはできますけどね。
値を取得する前に、クエリストリングのキーがダブっていないか、検査するとか。
例外を投げてほしかったな。
このページを共有する
