[WebGoat 5.4-16] Session Management Flaws

1. Hijack a Session

---

누군가에 의해 인증된 세션을 액세스 하도록 시도한다.

WEAKID를 예측하기위해 노력한다. WEAKID는 인증된 사용자와 WebGoat의 익명사용자를 구분한는데 사용된다.

 

2. Spoof an Authentication Cookie

---

사용자는 authentication check를 bypass 되도록 시도한다.

 

WebGoat에서 "Show Cookie"가 enable되도록 한다.

WebScarab에서 "Injection know cookies into request" 특징을 disable한다. 그러지 않으면 WebScarab은 항상 새로운 쿠키가 아니고 오래된 쿠키를 항상 injection 한다.

 

webgoat/webgot으로 로그인 한다.

 

"Refresh"를 누른다. refresh는 AuthCookie를 보여줄거다. 그러면 authenticated cookie를 사용하여 파라메터 없이 인증을 받아 본다.

 

Logout을 하고 aspect/aspect로 로그인한다.

그리고 "Refresh"를 눌러서 새로운 쿠키를 확인한다.

webgoat이랑 다른 AuthCookie값을 할당 받은 것을 확인할 수 있다.

 

 

이번에는 alice로 로그인하면 서 WebScarab에서 인터셉트한다.

그리고 AuthCookie값을 65432fdjmb   (AuthCookie 값의 규칙은 username-> reverse, 그다음 알파벳 하나씩 밀어서 사용 a->b  b->c

즉 alice -> ecila => fdjmb  그래서 65432fdjmb가 AuthCookie가 된다.

WebScarab에서 기존의 JSESSIONID에 유추한 AuthCookie값을 수정해서 넣고 [Accept changes]버튼을 클릭한다. 그러면 로그인이 성공적으로 처리되는 것을 볼 수 있다.

 

즉 로그인에 대한 확인을 세션값을 사용하지 않고 쿠키로 전달되는 AuthCookie값으로 결정하는 결함을 점검할 수 있다.

 

 

3. Session Fixation

---

[해답]

Stage1: 해커 Joe가 Jane의 session을 훔치기를 원한다. 그래서 은행으로부터 온 공식 메일인 것처럼 메일을 만들어서 Jane에게 전송한다.  템플릿메시지를 준비해 두었으니 SessionID(SID)값만

메일의 중간에 추가해서 전송한다.

<a href=/WebGoat/attack?Screen=56&menu=1800&SID=100>

 

Stage2: 메일을 수신한 Jane은 이메일에 포함된 링크를 클릭해서 해당 사이트로 이동한다. 그럼 URL창에 SID=100으로 붙어서 가는 것을 확인할 수 있다.

 

Stage3: 은행의 로그인이 창이 뜨면 Jane은 자신의 계정으로 로그인한다.

        Jane/tarzan 을 입력하고 로그인한다.

 

Stage4: 이제 Joe는 Jane의 세션을 훔친다. 

        URL창에 SID=100으로 변경하여 접속하면 Jane으로 접속되어 있다.

OWASP WebGoat: Session Management Flaws 솔루션 비디오 보기   

Description: It includes Session Fixation  [View | Download], 

Spoofing an Authentication Cookie  [View | Download] 

Hijacking a Session  [View | Download]. 

Spoofing an Authentication Cookie: Many applications will automatically log a user into their site if the right authentication cookie is specified. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.

Before we can hijack a session, we must do Session Analysis  [View | Download] to determine exploitable sign. 

Hijacking a Session: Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks. 
Size: N/A