推奨：ASPで実際のIPアドレスを見つける方法誰もが知っているように、IPアドレスを取得する方法は次の参照コンテンツです：<％= request.servervariables（remote_addr）％>
1。攻撃の原則
Cookieは、主に、現在のネットワークにCookieにユーザーログイン情報を保存する安全でない練習を使用します。
一般的なCookiesベースのユーザーシステムは、Cookieに少なくとも2つの変数を保存することがわかっています。ユーザー名とユーザーレベル、ユーザー名はユーザー名であり、ユーザーレベルはユーザーレベルです。ブラウザがASPページにアクセスすると、
| 以下は引用されたコンテンツです。 get /.../file.asp HTTP 1.0 ... Cookie：username = user＆userLevel = 1 ... 次に、管理者のユーザー名とuserLevelの値（それぞれ管理者と5を仮定）を知っている限り、それを転送できます get /.../file.asp HTTP 1.0 ... Cookie：username = admin＆userlevel = 5 ... |
管理者の権限を取得します。とてもシンプルですよね？ただし、脆弱性が発見される前に、ほとんどすべてのユーザー管理システムはCookieに依存していました。
2.ユーザー情報を安全に保存します
Cookieは不安定であり、ユーザーログイン情報を保存する必要があるため、どこに保存する必要がありますか？
ASPでは、Cookieに加えて、情報を保存できるセッションもあることに気付きました。セッションはサーバーに保存され、クライアントによって自由に変更することはできないため、非常に高いセキュリティがあります。このようにして、誰もがすべてのCookieのコードをセッションに変更できます。
3.ユーザー情報を長期間保存します
セッションは、ユーザーログイン情報を保存するために使用されますが、Cookieのスプーフィングの問題を取り除きますが、セッションは長時間保存できません（IISデフォルトセッションは20分間応答を停止した後）。このセクションで説明されています。
この方法の2つのバリエーションがありますCookieによると、ユーザー名とパスワードは、Cookieのコンテンツが合法かどうかを判断します。この方法を実装するコードは次のとおりです。
| 以下は引用されたコンテンツです。 VBS： <％ DIMユーザー名、パスワード username = session（username） username = thenの場合 「セッションにはユーザーログイン情報はありません username = request.cookies（username） パスワード= request.cookies（パスワード） '上記の2つの文で取得したユーザー名とパスワードに注意して、SQL注入の脆弱性を防ぐ（つまり、単一の引用を除外）、ここで省略 username =またはpassword = thenの場合 'ユーザーはログインしていません ... それ以外 'ここでは、connとrsオブジェクトが作成されていると想定されています rs.open選択トップ1 * from [user] from where username = '＆username＆'およびpassword = '＆password＆'、conn、1、3 rs.eofの場合 「Cookieの情報は違法です ... それ以外 'Cookieの情報は合法であり、自動的にログインしています セッション（username）= username ... ifを終了します ifを終了します それ以外 'ユーザー情報はすでにセッションに存在し、直接読まれます ... ifを終了します ％> JS： <％ varユーザー名、パスワード。 username = session（username）; if（username == || username == undefined）{ //セッションにはユーザー情報がありません username = request.cookies（username）; パスワード= request.cookies（パスワード）; //上記の2つの文で取得したユーザー名とパスワードに注意を払って、SQLインジェクションの脆弱性を防ぐ（つまり、単一の引用符を除外）、ここで省略 if（username == || username == undefined || password == || password == undefined）{ //ユーザーはログインしていません ... } それ以外 { //ここでは、connおよびrsオブジェクトが作成されていると想定されています rs.Open（[user] from [user] from [user] from username = 'username' and password = 'password'、conn、1、3）を選択します。 if（rs.eof）{ // Cookieの情報は違法です ... } それ以外 { // Cookieの情報は合法であり、自動的にログインしています session（username）= username; ... } } } それ以外 { //ユーザー情報はすでにセッションに存在し、直接読まれます ... } ％> |
ただし、ブラウザはページにアクセスするたびにCookieを送信するため、この方法はユーザーにとってそれほど安全ではありません。パスワードを含むCookieが他の人が取得すると、ユーザーのアカウントが盗まれます。この場合、2番目のメソッドが表示されます。つまり、ユーザー情報データベースにフィールド検証コードを追加します。 Cookieをデポジットする代わりに、コード値が追加されます。 Cookieでユーザー情報を検証する場合、ユーザー名とVerifyCodeのみが検証されます。この方法の利点は、ユーザーのCookieがハッカーによって取得されたとしても、この一時的な確認コードのみを使用してログインでき、ユーザーのパスワードを取得できないことです。このユーザーがユーザー名とパスワードで再度ログインする限り、確認コード値は変更され、ハッカーは元の検証コードを介してログインできません。
この方法の実装には、上記の方法1のコードのわずかな変更のみが必要です。まず、ログインプログラムでは、検証が通過してユーザー情報を保存する段落を追加する必要があります。
| 以下は引用されたコンテンツです。 VBS： <％ Response.Cookies（verifyCode）= int（rnd * 2100000000） ％> JS： <％ Response.Cookies（verifyCode）= math.floor（math.random（） * 2100000000）; ％> |
次に、上記の検証コードで、Cookie（パスワード）の検証をCookie（VerifyCode）の検証に変更します。
4。結論
分析と処理を通じて、Cookieのスプーフィングの脆弱性は完全に解決され、それ以来、ASPプログラムはより安全になりました。
共有：ASP Webページの開発プロセスのいくつかのヒントASPは、Microsoftによって発売されたテクノロジーで、そのフルネームはアクティブなサーバーページです。これは、Webサーバー側の実行環境です。 ASP自体にはVBScriptとJavaScriptエンジンが含まれており、スクリプトをHTMLに直接埋め込むことができます。