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（[ユーザー] from [user] from username = ' + username +'および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プログラムはより安全になりました。
2007-08-05 20:37執筆が始まります
2007-08-05 21:14初版が完了しました