<div id="readability-page-1" class="page"><div><h2 id="broken-authentication">Broken Authentication</h2>
Broken Authentication이란 인증이나 세션 관리가 제대로 이루어지지 않을 때 발생하는 취약점으로, 공격자가 다른 사용자의 계정에 무단 접근하거나 세션을 탈취할 수 있다.
<h3 id="세션이란">세션이란</h3>
세션의 사전적 정의는 동일 사용자에 대한 일련의 요청을 연결하는 임시 식별자다. 쉽게 말해 서버로부터 동일한 사용자라고 믿게 하는 인증서다. 
<h3 id="인증-우회-방법들">인증 우회 방법들</h3>
인증을 부수는 방법으로는 2가지가 있다.
<ul>
<li>사용자 책임</li>
</ul>
약한 비밀번호나 재사용된 비밀번호를 사용하는 경우 Brute Force나 Credential Stuffing로 꺨 수 있다.
<ul>
<li>개발자 책임</li>
</ul>
공격자가 미리 세션 ID를 정해 피해자가 사용하게 하는 Session Fixation이나 평문으로 전송하거나 예측 가능한 세션 ID을 사용한 경우, 그리고 XSS등으로 쿠키 탈취가 있다.
그럼 개발상의 부주의로 생기는 인증 우회를 알아보자
<h3 id="유저-아이디에-공백이-있는-경우">유저 아이디에 공백이 있는 경우</h3>
만약 'darren' 이란 아이디로 기존 유저가 있다고 가정하자. 
<img src="https://velog.velcdn.com/images/dongha1992/post/3ddc9e87-f031-4b9f-bd14-f7c1d480d09d/image.png">
예제는 TryHackMe에서 사용함. 유료 결제 이슈로 직접 해보진 못 함...
<img src="https://velog.velcdn.com/images/dongha1992/post/19a05618-a9e7-4a9b-9bda-1c5c37447a94/image.png">
로그인 시도 시 당연히 에러가 나온다. 그럼 새로운 아이디를 만드는데 ' darren' 공백을 포함하여 만들어보자.
<img src="https://velog.velcdn.com/images/dongha1992/post/e4ec356e-08a7-43ae-bc27-43f949b58a76/image.png">
그리고 로그인을 시도하면
<img src="https://velog.velcdn.com/images/dongha1992/post/b2b1f467-2e31-47c3-b4e0-8c543fd79362/image.png">
로그인에 성공한다.
이유는 이러하다. 회원가입 시 공백을 포함하면 서버에서는 다른 유저로 가입을 허용한다. 하지만 권한 체크 및 데이터 조회에서는 <code>trim(username)</code>을 해버려서 기존 darren의 권한이 붙어버린 것이다.
기존의 유저 아이디만 알면 공백이나 특수문자, 유니코드를 붙여서 회원가입을 한 뒤, 기존 
<h3 id="쿠키-값-조작하기">쿠키 값 조작하기</h3>
쿠키의 값을 가로채서 유추를 통해 다른 계정을 로그인 하는 취약점을 알아보자
먼저 <code>test1</code>이란 아이디로 회원가입을 하자
<img src="https://velog.velcdn.com/images/dongha1992/post/8e4a001d-4aa6-41de-9e1e-efb8bbc5d141/image.png">
실습 예제는 mutillidae에서 하였다.
<img src="https://velog.velcdn.com/images/dongha1992/post/d2314401-5c77-4b60-8bd6-76165cf62694/image.png">
회원 가입이 되었고
<img src="https://velog.velcdn.com/images/dongha1992/post/7d9826c2-5d02-4f50-a8a3-22b70cc4aff4/image.png">
로그인까지 했다. 이제 Burp Suite을 이용해서 요청을 가로채보자
<img src="https://velog.velcdn.com/images/dongha1992/post/30a53be1-f948-418e-a21c-d14a3222439c/image.png">
쿠키를 살펴보면(Base64 인코딩이 안되었다고 가정) <code>username, uid</code>를 볼 수 있다. 여기서 <code>username</code>을 <code>admin</code>으로 고치고 요청을 forward한다
<img src="https://velog.velcdn.com/images/dongha1992/post/dadcfe46-51f6-493e-a2ae-d83e42740e31/image.png">
아무 일도 발생하지 않는다. 그럼 <code>uid</code>를 변경해보면 어떨까. 보통 어드민의 경우 <code>uid</code>가 1인 경우가 많다(전회사도 어드민의 마스터 계정의 id는 1이였다)
<img src="https://velog.velcdn.com/images/dongha1992/post/51270b3c-61cd-4a9f-96a8-2fcdea81a2c5/image.png">
<code>uid</code>를 1로 바꿔서 forward해보면
<img src="https://velog.velcdn.com/images/dongha1992/post/b7b9d30b-b820-4191-bac1-2186222c5c43/image.png">
붐! 어드민 계정을 조회하게 된다. user_id가 1,2,3…처럼 추측 가능하면 계정 탈취가 브루트포스급으로 쉬워진다. 즉, 관리자가 보통 id가 1인 점을 이용한 것!
<h4 id="어떻게-방어할-것인가">어떻게 방어할 것인가</h4>
프론트가 할 수 있는 일은 사실 많이 없다. 공격자가 프록시를 사용하여 요청을 캐치하기 떄문에. 
그럼에도 할 수 있는 일은 user_id, isAdmin 같은 값을 쿠키나 로컬스토리지에 저장해서 권한 판단하는 설계를 피하는 것이 좋다. 
서버 쪽에서는 권한 판단에 클라이언트가 준 user_id나 role, username을 쓰지 않고, 서버에서 토큰을 받아 사용자 매핑하여 관리 해야 한다.</div></div>

삶도 재입학이 되나요?

Broken Authentication
Broken Authentication이란 인증이나 세션 관리가 제대로 이루어지지 않을 때 발생하는 취약점으로, 공격자가 다른 사용자의 계정에 무단 접근하거나 세션을 탈취할 수 있다.
세션이란
세션의 사전적 정의는 동일 사용자에 대한 일련의 요청을 연결하는 임시 식별자다. 쉽게 말해 서버로부터 동일한 사용자라고 믿게 하는 인증서다. 
인증 우회 방법들
인증을 부수는 방법으로는 2가지가 있다.
사용자 책임
약한 비밀번호나 재사용된 비밀번호를 사용하는 경우 Brute Force나 Credential Stuffing로 꺨 수 있다.
개발자 책임
공격자가 미리 세션 ID를 정해 피해자가 사용하게 하는 Session Fixation이나 평문으로 전송하거나 예측 가능한 세션 ID을 사용한 경우, 그리고 XSS등으로 쿠키 탈취가 있다.
그럼 개발상의 부주의로 생기는 인증 우회를 알아보자
유저 아이디에 공백이 있는 경우
만약 'darren' 이란 아이디로 기존 유저가 있다고 가정하자. 
예제는 TryHackMe에서 사용함. 유료 결제 이슈로 직접 해보진 못 함...
로그인 시도 시 당연히 에러가 나온다. 그럼 새로운 아이디를 만드는데 ' darren' 공백을 포함하여 만들어보자.
그리고 로그인을 시도하면
로그인에 성공한다.
이유는 이러하다. 회원가입 시 공백을 포함하면 서버에서는 다른 유저로 가입을 허용한다. 하지만 권한 체크 및 데이터 조회에서는 trim(username)을 해버려서 기존 darren의 권한이 붙어버린 것이다.
기존의 유저 아이디만 알면 공백이나 특수문자, 유니코드를 붙여서 회원가입을 한 뒤, 기존 
쿠키 값 조작하기
쿠키의 값을 가로채서 유추를 통해 다른 계정을 로그인 하는 취약점을 알아보자
먼저 test1이란 아이디로 회원가입을 하자
실습 예제는 mutillidae에서 하였다.
회원 가입이 되었고
로그인까지 했다. 이제 Burp Suite을 이용해서 요청을 가로채보자
쿠키를 살펴보면(Base64 인코딩이 안되었다고 가정) username, uid를 볼 수 있다. 여기서 username을 admin으로 고치고 요청을 forward한다
아무 일도 발생하지 않는다. 그럼 uid를 변경해보면 어떨까. 보통 어드민의 경우 uid가 1인 경우가 많다(전회사도 어드민의 마스터 계정의 id는 1이였다)
uid를 1로 바꿔서 forward해보면
붐! 어드민 계정을 조회하게 된다. user_id가 1,2,3…처럼 추측 가능하면 계정 탈취가 브루트포스급으로 쉬워진다. 즉, 관리자가 보통 id가 1인 점을 이용한 것!
어떻게 방어할 것인가
프론트가 할 수 있는 일은 사실 많이 없다. 공격자가 프록시를 사용하여 요청을 캐치하기 떄문에. 
그럼에도 할 수 있는 일은 user_id, isAdmin 같은 값을 쿠키나 로컬스토리지에 저장해서 권한 판단하는 설계를 피하는 것이 좋다. 
서버 쪽에서는 권한 판단에 클라이언트가 준 user_id나 role, username을 쓰지 않고, 서버에서 토큰을 받아 사용자 매핑하여 관리 해야 한다.

Broken Authentication(인증 우회)

댓글