The prevention of Cookies Spoofing Vulnerability (VBS+JS implementation)

First, the principle of attack

Cookies cheat mainly utilizes the current network some user management system to use the user login information to store in the Cookies the unsafe practice to attack, its attack method relative to the SQL injection loophole and so on the vulnerability to be "difficult" some, but still very "fool".
We know that the average cookie-based user system stores at least two variables in cookies: username and userlevel, where username is the user name, and Userlevel is the user's level. When our browser accesses an ASP page, it spreads a similar

The following are the referenced contents: Get/.../file.asp HTTP 1.0 ... Cookies:username=user&userlevel=1 ... Packets, then we'll just have to know the Administrator's username and userlevel values (assuming admin and 5, respectively) to transmit Get/.../file.asp HTTP 1.0 ... Cookies:username=admin&userlevel=5 ...

To obtain administrator privileges. It's simple, isn't it? However, until this vulnerability is discovered, almost all user management systems rely on Cookies.

Second, securely store user information

Since Cookies are unsafe and we have to store user login information, where should we store them?
We note that in the ASP, in addition to Cookies, there is a session can store information. The session is stored on the server, not the client casually can change, so have a very high security. In this way, everyone will be able to change the code for all Cookies for session.

Three, long time to store user information

Use session to save user login information, although free from the problem of cookie spoofing, but not long-term storage sessions (IIS default to stop response 20 minutes after the user stopped responding), resulting in this section of the Cookies + Mixed storage method.
This method has two variants, the first is to store the user name and password in the cookies, when the user visits a page, read the session first, if there is content to the session, otherwise read cookies, according to the cookies provided in the username and password for "opaque" Login once to determine whether the contents of the Cookies are legitimate, and if they are valid, they are then deposited in the session. The code to implement this method is as follows:

The following are the referenced contents: VBs: <% Dim username, password Username = Session ("username") If username = "" Then ' No user login information in session Username = Request.Cookies ("username") Password = request.cookies ("password") ' Note that the above two sentences get username and password to prevent SQL injection vulnerabilities (that is, filter out single quotes ""), omit If username = "" or Password = "" Then ' User not logged in ... Else ' Here suppose you have created the Conn and Rs objects Rs. Open "SELECT top 1 * from [user] WHERE username= '" & Username & "' and password= '" & Password & "", Conn, 1, 3 If Rs.eof Then ' Information in Cookies is illegal ... Else ' Cookies in the information legal, automatic login Session ("username") = Username ... End If End If Else ' User information already exists in session, read directly ... End If %> Js: <% var username, password; Username = Session ("username") + ""; if (username = = "" | | Username = = "undefined") { No user information in session Username = Request.Cookies ("username") + ""; Password = request.cookies ("password") + ""; Note that the above two sentences get the username and password to prevent SQL injection vulnerabilities (that is, filter out single quotes ""), where omitted if (username = = "" | | Username = = "undefined" | | Password = "" | | Password = = "undefined") { User not logged in ... } else { This assumes that the Conn and Rs objects have been created Rs. Open ("SELECT top 1 * from [user] WHERE username= '" + username + "' and password= '" + Password + "", Conn, 1, 3); if (rs.eof) { Information in Cookies is illegal ... } else { Information in Cookies is legal and automatically logged in Session ("username") = username + ""; ... } } } else { User information already exists in session, read directly ... } %>

But this method is not very safe for the user, because the browser every time the page will be sent to the cookie pass, and the password contains cookies once someone else gets the user account will be stolen. In this case, there is a second method, that is, in the user information database to add a field "Verifycode", when the user login, randomly generated a long integer checksum into the Verifycode field, and will username and this verifycode value instead of Password into Cookies. While verifying the user information in Cookies, only username and Verifycode are validated. The advantage of this approach is that even if the user's Cookies are captured by hackers, he can only use the "temporary" generated Verifycode login, and can not get the user's password. As soon as this user logs in with the username and password again, the Verifycode value changes, and the hacker cannot login through the original verifycode.
The implementation of this method requires only a slight change in the code of the method one above. First, in your login program, you need to add a section where you want to verify the information that is stored by the user:

The following are the referenced contents: VBs: <% Response.Cookies ("verifycode") = Int (RND * 2100000000) %> Js: <% Response.Cookies ("verifycode") = Math.floor (Math.random () * 2100000000); %>

The validation of Cookies ("password") is then validated against cookies ("Verifycode") in the validation code provided above.

Iv. Conclusion

Through our analysis and processing, cookie Spoofing vulnerability has been completely resolved, since then, our ASP program has become more secure.