Cookies 사기 구멍 방지 방법(vbs+js 구현)

마지막 으로 한 마디 로 본인 이 이 글 을 입력 하 는 기계 에 ASP 환경 이 없어 제 공 된 코드 를 테스트 하지 못 한 점 에 대해 깊이 사 과 드 립 니 다.만약 에 여러분 이 코드 에 있 는 모든 문 제 를 발견 하면 벽돌 을 치 는 것 을 환영 합 니 다~본인 의 가죽 이 두 껍 습 니 다~1.공격 원리 Cookies 사 기 는 주로 현재 인터넷 에 있 는 일부 사용자 관리 시스템 을 이용 하여 사용자 의 로그 인 정 보 를 Cookies 에 저장 하 는 안전 하지 않 은 방법 으로 공격 합 니 다.그 공격 방법 은 SQL 에 구멍 을 넣 는 등 구멍 에 비해 상대 적 으로'어렵 습 니 다'.그래도 바보 야.일반적인 쿠키 기반 사용자 시스템 은 최소한 쿠키 에 두 개의 변 수 를 저장 합 니 다.username 과 userlevel,그 중에서 username 은 사용자 이름 이 고 userlevel 은 사용자 등급 입 니 다.브 라 우 저가 ASP 페이지 를 방문 할 때 GET/.../file.asp HTTP 1.0...Cookies:username=user&userlevel=1..과 같은 패 킷 이 전 달 됩 니 다.관리자 의 username 과 userlevel 값(각각 admin 과 5 라 고 가정)만 알 면 됩 니 다.GET/.../file.asp HTTP 1.0...Cookies:username=admin&userlevel=5..를 전송 하여 관리자 권한 을 얻 을 수 있 습 니 다.쉬 워 요.그 렇 죠?그러나 이 구멍 이 발견 되 기 전 까지 거의 모든 사용자 관리 시스템 이 쿠키 에 의존 했다.2.사용자 정 보 를 안전하게 저장 합 니 다.쿠키 가 안전 하지 않 은 이상 저 희 는 사용자 로그 인 정 보 를 저장 해 야 합 니 다.그러면 어디 에 저장 해 야 합 니까?ASP 에 서 는 쿠키 외 에 도 세 션 이 정 보 를 저장 할 수 있다 는 점 에 주목 했다.Session 은 서버 에 저 장 된 것 으로 클 라 이언 트 가 마음대로 변경 할 수 있 는 것 이 아니 기 때문에 매우 높 은 안전성 을 가진다.이렇게 하면 모든 쿠키 의 코드 를 세 션 으로 바 꿀 수 있 습 니 다.3.사용자 정 보 를 장시간 저장 할 때 Session 을 사용 하여 사용자 로그 인 정 보 를 저장 합 니 다.쿠키 사기 문제 에서 벗 어 났 지만 Session 은 장기 적 으로 저장 하지 못 합 니 다(IIS 기본 Session 은 사용자 가 응답 을 멈 춘 지 20 분 후에 효력 을 잃 습 니 다).그래서 이 절 에서 말 한 Cookies+Session 혼합 저장 법 이 생 겼 습 니 다.이 방법 은 두 가지 변종 이 있 는데,첫 번 째 는 쿠키 에 사용자 이름과 비밀 번 호 를 저장 하고,사용자 가 한 페이지 를 방문 할 때 세 션 을 먼저 읽 고,내용 이 있 으 면 세 션 을 기준 으로 하 며,그렇지 않 으 면 쿠키 를 읽 고 쿠키 에 제 공 된 사용자 이름과 비밀번호 에 따라'불투명'하 게 한 번 로그 인하 여 쿠키 의 내용 이 합 법 적 인지 판단 하 는 것 이다.합 법 적 으로 세 션 에 넣 으 면이 방법 을 실현 하 는 코드 는 다음 과 같다.vbs:

 
<% 
Dim username, password 
username = Session("username") 
if username = "" then 
' Session           
username = Request.Cookies("username") 
password = Request.Cookies("password") 
'            username   password     SQL        （       “'”），     
if username = "" or password = "" then 
'        
... 
else 
'           conn   rs    
rs.Open "SELECT TOP 1 * FROM [user] WHERE username='" & username & "' AND password='" & password & "'", conn, 1, 3 
if rs.eof then 
' Cookies        
... 
else 
' Cookies       ，     
Session("username") = username 
... 
end if 
end if 
else 
'           Session  ，     
... 
end if 
%> 

js:

 
<% 
var username, password; 
username = Session("username") + ""; 
if (username == "" || username == "undefined") { 
// Session         
username = Request.Cookies("username") + ""; 
password = Request.Cookies("password") + ""; 
//            username   password     SQL        （       “'”），     
if (username == "" || username == "undefined" || password == "" || password == "undefined") { 
//        
... 
} 
else { 
//           conn   rs    
rs.Open("SELECT TOP 1 * FROM [user] WHERE username='" + username + "' AND password='" + password + "'", conn, 1, 3); 
if (rs.eof) { 
// Cookies        
... 
} 
else { 
// Cookies       ，     
Session("username") = username + ""; 
... 
} 
} 
} 
else { 
//           Session  ，     
... 
} 
%> 

그러나 이러한 방법 은 사용자 에 게 안전 하지 않다.브 라 우 저 는 페이지 를 방문 할 때마다 쿠키 를 전송 하고 비밀 번 호 를 포함 한 쿠키 를 다른 사람 이 가 져 오 면 사용자 계 정 이 도 둑 맞 기 때문이다.이러한 상황 에 대해 두 번 째 방법 이 나 타 났 다.즉,사용자 정보 데이터베이스 에'verifycode'필드 를 추가 하고 사용자 가 로그 인 할 때 랜 덤 으로 긴 정형 검사 값 을 verifycode 필드 에 저장 하 며 username 과 이 verifycode 값 을 password 가 아 닌 Cookies 에 저장 하 는 것 이다.쿠키 의 사용자 정 보 를 검증 할 때 도 username 과 verifycode 만 검증한다.이런 방법의 장점 은 사용자 의 쿠키 가 해 킹 당 하 더 라 도 이'임시'로 생 성 된 verifycode 로 만 로그 인 할 수 있 을 뿐 사용자 의 비밀 번 호 를 얻 을 수 없다 는 점 이다.이 사용자 가 다시 사용자 이름과 비밀 번 호 를 사용 하여 로그 인하 면 이 verifycode 값 이 바 뀌 고 해커 는 원래 의 verifycode 를 통 해 로그 인 할 수 없습니다.이런 방법의 실현 은 상술 한 방법 1 의 코드 에 약간의 변경 만 필요 하 다.우선,로그 인 프로그램 에서 사용자 정 보 를 저장 하 는 곳 에 vbs:

 
<% 
Response.Cookies("verifycode") = int(rnd * 2100000000) 
%> 

js:

 
<% 
Response.Cookies("verifycode") = Math.floor(Math.random() * 2100000000); 
%> 

를 추가 한 다음 에 위 에서 제공 한 인증 코드 에서 Cookies("password")에 대한 인증 을 Cookies("verifycode")에 대한 검증 으로 바 꾸 면 됩 니 다.4.결론 은 우리 의 분석 과 처 리 를 통 해 Cookies 사기 구멍 이 완전히 해결 되 었 고 이로부터 우리 의 ASP 프로그램 은 더욱 안전 해 졌 다.