development guideline/ASP.NET

• development guideline/ASP.NET/Security

Webサイト構築前に決めておくべき事 †

• Webサイトの目的 (5W1Hで)
  • Webサイトのコンセプト
  • ターゲットユーザーの属性
  • ユーザーニーズ
  • コンテンツの展開方法
• サイト構造／ディレクトリ構成
• アクセシビリティ／ユーザービリティ／SEO指針
• ビジュアルデザイン基本方針

Webページ共通 †

文字コード †

• Htmlとしてレンダリングされるファイル(*.aspx,*.ascxなど)の文字コードと、Content-Typeで指定する文字コードは一致させる。
• WebForm(*.aspx), ユーザーコントロール(*.ascx)ファイルの文字コードは、UTF-8とする。
• ただし、モバイル用Webページの文字コードについては、旧機種への対応のため、Shift_JISとする。

ページキャッシュ †

• キャッシュの設定はパフォーマンスとリアルタイム性のトレードオフになるため、十分に検討して設定すること。

セッションタイムアウト †

• あらゆる画面でセッションタイムアウトは発生する。安全に処理が中断されるように設計すること。

ブラウザアクションへの対応 †

• 「戻る」「進む」をはじめ、ページの「更新」「ソースの表示」等のブラウザアクションについて、機能的に問題がないか十分に考慮すること。

ポップアップ画面 †

• ポップアップ画面開発の際には、複数起動されることや、タブブラウザを利用される可能性を考慮すること。

例外処理 †

• 例外処理は、Global.asaxや基底ページ等で共通化すること。
  • ただし、個別の例外処理は、個々のページで実装すること。
• なにはなくても、以下の２つはcatchし、IISデフォルトのサーバーエラーページが出力されないようにする。
  • SesssionTimeOut
  • 予期せぬシステムエラー
• HTTP Status 400番台の処理はIISに任せ、妥当なエラーページを作成する。

アプリケーションパス †

• Webアプリケーション名は、URLの一部となる。後で変更できるように、ソースコード中にWebアプリメーション名を記述しないように注意すること。
  • サーバーコントロールのプロパティでは、「~（チルダ）」を指定することで、Webアプリケーションのベースフォルダが指定できる。
  • JavaScriptや、生HTMLのhref属性やonclick属性に記述する際には、「~（チルダ）」は使用できない（URLとして誤記になる）ので、<%= Request.ApplicationPath %>スクリプトレットを使用する。ただし、スクリプトレットはaspxファイル内でのみ有効で、JavaScript外部ファイル(*.js)内では無効であることに注意すること。

ポストバック後のスクロールの位置の復元 †

• 標準の状態では、ポストバック発生後にページを表示すると、スクロール位置は復元されない。
• web.configのpagesにmaintainScrollPositionOnPostBack="true"を付加する事で全ページに対して、スクロールの復元を可能とする。

シリアル化できないオブジェクトを、Sessionに格納しない †

• セッション管理をinProc以外で実現した場合にも、正常に動作させるため。
• また、データサイズの大きなオブジェクトを、不要にセッションに格納しないこと。性能の劣化を招くだけでなく、メモリやストレージを圧迫したりする。
• ちなみに、ViewStateにシリアル化できないオブジェクトを保存することはできない。

できるだけ、Session_OnEndイベントを利用しない †

• セッション管理をinProc以外で実現した場合に、Session_OnEndイベントハンドラは正常に動作しないため。

head要素内ルール †

• 文字化け回避のため、必ず最初にmeta要素のcharset属性で文字コードセットを指定する
• その直後に、title要素を記述する
• 続いて他のmeta要素、link要素、script要素の順で記述する

定型判定ロジック †

• Page_Load()では、IsPostBack判定を実装すること。
• 各ユーザーアクションイベント(click等)ハンドラでは、IsValid判定を実装すること。

CSS †

タイプセレクタとclassセレクタを組み合わせて指定する（例：p.example） †

• ⇔classセレクタだけで指定しない（例：.examples）
• どの要素にも適用させたい汎用スタイルとして指定する場合を除く

Webコントロール †

コントロールの基底化 †

• .NET Framework標準のWebコントロールは直接利用せず、継承したクラスを共通利用すること。（例：TextBoxコントロールをExTextBoxコントロールとして継承・拡張し利用する。）
  • 同種のコントロール全てに、同じ実装を追加したい場合には、その基底クラスに実装するとよい。
• 同種のコントロールの一部に、同じ実装を追加したい場合には、その基底クラスを更に派生させたクラスに実装するとよい。（機能のクラス階層化）
• 特に、Pageクラスは基底クラスを必ず作成してから、開発を始めること。

ITextControl系コントロールのText属性初期値の記述場所 †

• Label, Literal等、ITextControl系コントロールのText値は、属性部分ではなく、開始タグと終了タグの間に記述する方が見やすい。

バリデーション †

コントロールの基底化 †

• .NET Framework標準のValidatorコントロールは直接利用せず、継承したクラスを共通利用すること。
  • 全てのコントロールに同じ実装を追加したい場合に、その基底クラスに実装する。

セキュリティ対策 †

ボタン2度押し †

• TransactionToken機能を実装し、DBアクセスを伴うボタンの2度押しを防止すること。
  ※ StrutsのTransaction Tokenと同機能と考えてよい。
  • 登録処理が実行されるボタンには必須。
• JavaScriptだけに頼らない。

クロスサイトスクリプティング（XSS） †

• ユーザー入力値や、DBから取得した値をWebページにHTMLレンダリングされる際には、無害化処理（サニタイジング）を行う必要がある。
• 基本的には、拡張Webコントロール内で無害化処理を共通化し、個別に無害化するのは、JavaScript等のリテラル処理のみとする。
• 個別に実装する場合は、HttpServerUtility.HtmlEncode ()メソッドを利用する。
  • aspxファイルのPageディレクティブのvalidateRequest属性をtrueに設定することで、「<」文字などの入力をエラーとすることも可能だが、XSS対策として完全でない上に、入力不能な文字を生んでしまう。validateRequest属性には頼らない。
    http://msdn2.microsoft.com/ja-JP/library/system.web.httprequestvalidationexception.aspx

URLクエリ文字列の無害化 †

• URLのクエリ文字列に使用されるクエリ値は、HttpUtility.UrlEncode()メソッド、あるいは、Uri.EscapeEncode()メソッドを使用し、無害化を行う事。
• また、クエリ名称は無害化の必要のない文字列とすること。