Considering that ASP development can use two languages: vbs and js, program codes in both languages are provided here (bilingual version? YY medium...) One last wordy sentence, the machine I used to type this article does not have an ASP environment, so The code provided was not tested, and I apologize for that. If you find any problems in the code, please feel free to comment~I have a thick skin~
1. Attack principle
Cookie spoofing mainly exploits the unsafe practice of storing user login information in cookies by some user management systems on the current network. Its attack method is relatively difficult compared to vulnerabilities such as SQL injection vulnerabilities, but it is still very stupid.
We know that a general user system based on Cookies will store at least two variables in Cookies: username and userlevel, where username is the username and userlevel is the user's level. When our browser accesses an ASP page, it will send out something like
GET /.../file.asp HTTP 1.0
...
Cookies: username=user&userlevel=1
...
packet, then as long as we know the administrator's username and userlevel values (assumed to be admin and 5 respectively), we can transmit
GET /.../file.asp HTTP 1.0
...
Cookies: username=admin&userlevel=5
...
to obtain administrator rights. Very simple isn't it? However, before this vulnerability was discovered, almost all user management systems relied on cookies.
2. Store user information securely
Since Cookies are not secure, and we must store user login information, where should it be stored?
We noticed that in ASP, in addition to Cookies, there is also Session that can store information. Session is stored on the server and cannot be changed casually by the client, so it has extremely high security. In this way, you can replace all Cookies codes with Session.
3. Store user information for a long time
Using Session to save user login information, although it gets rid of the problem of Cookies deception, Session cannot be stored for a long time (IIS default Session expires 20 minutes after the user stops responding), so the Cookies + Session hybrid storage method described in this section is produced. .
There are two variants of this method. The first one is to store the user name and password in Cookies. When the user visits a page, the Session is read first. If there is content, the Session shall prevail. Otherwise, the Cookies shall be read and the information provided in Cookies shall be used. Log in opaquely with your user name and password 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:
Copy the code code as follows:
<%
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)
' Note that the username and password obtained in the above two sentences need to be prevented from SQL injection vulnerabilities (that is, single quotes are filtered out'), which are omitted here.
if username = or password = then
'The user is 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 then
'The information in the cookies is illegal
...
else
'The information in the cookies is legal, log in automatically
Session(username) = username
...
end if
end if
else
'User information already exists in Session, read it directly
...
end if
%>
js:
Copy the code code as follows:
<%
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) + ;
// Note that the username and password obtained in the above two sentences need to prevent SQL injection vulnerabilities (that is, filter out the single quotes '), which are omitted here.
if (username == || username == undefined || password == || password == undefined) {
//The user is 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) {
//The information in Cookies is illegal
...
}
else {
//The information in Cookies is legal, log in automatically
Session(username) = username + ;
...
}
}
}
else {
// User information already exists in Session, read it directly
...
}
%>
However, this method is not very safe for users because the browser will transmit Cookies every time they visit the page, and once the Cookies containing passwords are obtained by others, the user's account will be stolen. For this situation, there is a second method, which is to add a field verifycode in the user information database. When the user logs in, a long integer verification value is randomly generated and stored in the verifycode field, and the username and this verifycode value are added. Store cookies instead of password. 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 the temporarily generated verifycode to log in, but cannot obtain the user's password. As long as this user logs in using the username and password again, the verifycode value will change, and hackers will not be able to log in through the original verifycode.
The implementation of this method only requires slight changes to the code of method 1 above. First, in your login program, you need to add a paragraph where the user information is stored after verification:
vbs:
Copy the code code as follows:
<%
Response.Cookies(verifycode) = int(rnd * 2100000000)
%>
js:
Copy the code code as follows:
<%
Response.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
Then, change the verification of Cookies(password) to the verification of Cookies(verifycode) in the verification code provided above.
4. Conclusion
Through our analysis and processing, the Cookies spoofing vulnerability has been completely resolved. Since then, our ASP program has become more secure.