1. Principle of attack
Cookies spoofing mainly uses the unsafe practice of storing user login information in cookies on the current network. The attack method is relatively difficult compared to vulnerabilities such as SQL injection vulnerabilities, but it is still very stupid.
We know that a general cookies-based user system will store at least two variables in cookies: username and userlevel, where username is the username and userlevel is the user level. When our browser accesses the ASP page, it will emit something like
GET /.../file.asp HTTP 1.0
...
Cookies: username=user&userlevel=1
...
Then, as long as we know the administrator's username and userlevel values (assuming admin and 5 respectively), we can transfer it
GET /.../file.asp HTTP 1.0
...
Cookies: username=admin&userlevel=5
...
to obtain administrator permissions. Very simple, right? However, before the vulnerability was discovered, almost all user management systems relied on cookies.
2. Safely store user information
Since cookies are unsafe and we must store user login information, where should they be stored?
We noticed that in ASP, in addition to cookies, there is also a Session that can store information. Session is stored on the server and cannot be changed by the client at will, so it has extremely high security. In this way, everyone can change the code of all cookies to Session.
3. Store user information for a long time
Session is used to save user login information. Although it gets rid of the problem of cookies spoofing, Session cannot be stored for a long time (IIS default Session expires after the user stops responding for 20 minutes), so the Cookies + Session hybrid storage method described in this section is generated. .
There are two variants of this method. The first is to store the user name and password in cookies. When a user visits a page, read the Session first. If there is any content, the Session shall prevail. Otherwise, read the Cookies and provide it according to the Cookies. The username and password of the username and password are logged in opaquely to determine whether the content in the cookies is legal. If it is legal, it will be stored in the Session. The code to implement this method is as follows:
vbs:
<%
Dim username, password
username = Session(username)
if username = then
' There is no user login information in the Session
username = Request.Cookies(username)
password = Request.Cookies(password)
' Pay attention to the username and password obtained in the above two sentences to prevent SQL injection vulnerabilities (i.e. filter out single quotes'), omitted here
if username = or password = then
' The user is not logged in
...
else
' Here it is assumed 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 then
' The information in the cookies is illegal
...
else
' The information in the cookies is legal and automatically logged in
Session(username) = username
...
end if
end if
else
' User information already exists in the Session and is read directly
...
end if
%>
js:
<%
var username, password;
username = Session(username) + ;
if (username == || username == undefined) {
// There is no user information in the Session
username = Request.Cookies(username) + ;
password = Request.Cookies(password) + ;
// Pay attention to the username and password obtained in the above two sentences to prevent SQL injection vulnerabilities (i.e. filter out single quotes'), omitted here
if (username == || username == undefined || password == || password == undefined) {
// The user is not logged in
...
}
else {
// Here it is assumed 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) {
// The information in the cookies is illegal
...
}
else {
// The information in cookies is legal and automatically logged in
Session(username) = username + ;
...
}
}
}
else {
// User information already exists in the Session and is read directly
...
}
%>
However, this method is not very safe for users, because the browser will transmit cookies every time it visits the page, and the user's account will be stolen once the cookies containing the password are obtained by others. For this case, a second method appears, that is, add a field verification code to the user information database. When the user logs in, a long integer verification value is randomly generated and stored in the verification code field, and username and this verification code value are added. Instead of password depositing cookies. When verifying user information in cookies, only username and verifycode are verified. The advantage of this method is that even if the user's cookies are obtained by a hacker, he can only use this temporary verificationcode to log in, and cannot obtain the user's password. As long as this user logs in with the username and password again, the verificationcode value will change and the hacker will not be able to log in through the original verificationcode.
The implementation of this method only requires slight changes to the code of method one mentioned above. First, in your login program, you need to add a paragraph where the verification passes to store user information:
vbs:
<%
Response.Cookies(verifycode) = int(rnd * 2100000000)
%>
js:
<%
Response.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
Then, in the verification code provided above, change the verification of Cookies(password) to the verification of Cookies(verifycode).
4. Conclusion
Through our analysis and processing, the Cookies spoofing vulnerability has been completely resolved, and since then, our ASP programs have become more secure.
2007-08-05 20:37 Writing begins
2007-08-05 21:14 The first edition is completed