웹해킹_2주차
https://dreamhack.io/lecture/roadmaps/1
Web Hacking
웹 해킹을 공부하기 위한 로드맵입니다.
dreamhack.io
2주차 (9/12~9/18) : Stage 3
STAGE 3 : Cookie & Session
1. Cookie & Session
[Background : Cookie & Session]
1. 들어가면
현대의 웹 서비스는 대부분 로그인을 통해 마이페이지, 유료 서비스 등 개인만의 서비스를 이용할 수 있게 된다.
웹 서버는 수많은 클라이언트와 HTTP 프로토콜을 사용해 통신한다. 손님 계정으로 로그인 했다면 손님이 이용할 수 있는 서비스를 제공하고, 관리자 계정으로 로그인 했다면 데이터베이스, 회원 관리 등의 관리자 페이지를 제공한다.
그렇다면 웹 서버는 수많은 클라이언트를 어떻게 구별하고 서로 다른 결과를 반환해줄까?
헤더(Header)를 통해서 웹 서버에게 요청을 보내고, 웹 서버는 헤더를 읽고 클라이언트에게 결과 값을 반환한다. 이때, 헤더에는 클라이언트의 정보와 요청의 내용을 구체화하는 등의 데이터가 포함되는데, 클라이언트의 인증 정보 또한 포함된다. 이번 코스에서는 클라이언트의 인증 정보를 포함하고 있는Cookie와 Session에 대해 배울 것이다.
2. 쿠키
1) 쿠키
-쿠키
클라이언트의 IP 주소와 User-Agent는 매번 변경될 수 있는 고유하지 않은 정보일 뿐만 아니라, HTTP 프로토콜의 Connectionless와 Stateless 특징 때문에 웹 서버는 클라이언트를 기억할 수 없다.
Connectionless, Stateless 특성을 갖는 HTTP에서 상태를 유지하기 위해 쿠키(Cookie)가 탄생했다. 쿠키는 Key와 Value로 이뤄진 일종의 단위로, 서버가 클라이언트에게 쿠키를 발급하면, 클라이언트는 서버에 요청을 보낼 때마다 쿠키를 같이 전송한다. 서버는 클라이언트의 요청에 포함된 쿠키를 확인해 클라이언트를 구분할 수 있다.
-용도
: 일반적으로 쿠키는 클라이언트의 정보 기록과 상태 정보를 표현하는 용도로 사용된다.
-정보 기록
: 웹 서비스 사용 시 종종 팝업 창에 "다시 보지 않기", "7일 간 표시하지 않기" 버튼이 있는 것을 확인할 수 있다. 웹 서버는 각 클라이언트의 팝업 옵션을 기억하기 위해 쿠키에 해당 정보를 기록하고, 쿠키를 통해 팝업 창 표시 여부를 판단한다.
쿠키는 과거에 클라이언트의 정보를 저장하기 위해 종종 사용됐다.
쿠키는 서버와 통신할 때마다 전송되기 때문에 쿠키가 필요 없는 요청을 보낼 때 리소스가 낭비될 수 있다. 최근에는 이러한 단점을 보완하기 위해 Modern Storage APIs를 통해 데이터를 저장하는 방식을 권장하고 있다.
-상태 정보
: 웹 서버에서는 수많은 클라이언트의 로그인 상태와 이용자를 구별해야 하는데, 이때 클라이언트를 식별할 수 있는 값을 쿠키에 저장하여 사용한다.
2) 쿠키 유무에 따른 통신
-쿠키가 없는 통신
: 서버는 요청을 보낸 클라이언트가 누군지 알 수 없기 때문에 현재 어떤 클라이언트와 통신하는지 알 수 없다.
-쿠키가 있는 통신
: 클라이언트 서버에 요청을 보낼 때마다 쿠키를 포함하고, 서버는 해당 쿠키를 통해 클라이언트를 식별한다.
3) 쿠키 변조
: 쿠키는 클라이언트의 브라우저에 저장되고 요청에 포함되는 정보이다. 악의적인 클라이언트는 쿠키 정보를 변조해 서버에 요청을 보낼 수 있다. 만약 서버가 별다른 검증 없이 쿠키를 통해 이용자의 인증 정보를 식별한다면 공격자가 타 이용자를 사칭해 정보를 탈취할 수 있다.
3. 세션
1) 세션
쿠키에 인증 상태를 저장하지만 클라이언트가 인증 정보를 변조할 수 없게 하기 위해 세션(Session)을 사용해야 한다. 세션은 인증 정보를 서버에 저장하고 해당 데이터에 접근할 수 있는 키(유추할 수 없는 랜덤한 문자열)를 만들어 클라이언트에 전달하는 방식으로 작동한다. 해당 키를 일반적으로 Session ID라고 한다. 브라우저는 해당 키를 쿠키에 저장하고 이후에 HTTP 요청을 보낼 때 사용한다. 서버는 요청에 포함된 키에 해당하는 데이터를 가져와 인증 상태를 확인한다.
2) 세션 실습
-세션
쿠키는 데이터 자체를 이용자가 저장하며, 세션은 서버가 저장한다.
3) 쿠키 적용법
쿠키는 클라이언트에 저장되기 때문에 클라이언트는 저장된 쿠키를 조회, 수정, 추가할 수 있다. 클라이언트가 서버에 요청을 보낼 때 저장된 쿠키를 요청 헤더에 넣어 전송하기 때문에 이용자가 요청을 보낼 때 쿠키 헤더를 변조할 수 있다. 쿠키를 설정할 때에는 만료 시간을 지정할 수 있고, 만료 시간 이후에는 클라이언트에서 쿠키가 삭제된다. 쿠키의 만료는 클라이언트(브라우저)에서 관리된다.
4) 세션 활용
쿠키에는 세션 정보가 저장되어 있고 서버는 이를 통해 이용자를 식별하고 인증을 처리한다. 공격자가 이용자의 쿠키를 훔칠 수 있으면 세션에 해당하는 이용자의 인증 상태를 훔칠 수 있는데, 이를 세션 하이재킹 (Session Hijacking)이라고 한다.
4. 마치며
[퀴즈 : Cookie & Session]
[혼자실습] Seesion-basic
[session-basic]
DH{8f3d86d1134c26fedf7c4c3ecd563aae3da98d5c}
[함께실습] Cookie
[Excersice : Cookie]
1. 들어가며
잘못된 쿠키의 설계로 발생할 수 있는 문제점을 다루는 드림핵 워게임 문제 풀어보기
2, 웹 서비스 분석
1) 엔드포인트 분석
인덱스 페이지에서 요청에 포함된 쿠키를 통해 이용자를 식별한다. 만약 쿠키에 존재하는 username이 "admin"일 경우 flag를 출력한다.
2) 엔드포인트 분석
-GET : username과 password를 입력할 수 있는 로그인 페이지를 제공한다.
-POST : 이용자가 입력된 username과 password 입력 값을 users 변숫값과 비교한다. 코드를 살펴보면, 손님 계정의 비번이 "guest", 관리자 계정의 비번이 파일에서 읽어온 flag임을 알 수 있다.
3. 취약점 분석
이용자의 계정을 나타내는 username 변수가 요청에 포함된 쿠키에 의해 결정되어 문제가 발생한다.
쿠키는 클라이언트의 요청에 포함된 정보로, 이용자가 임의로 조작할 수 있다. 서버는 별다른 검증 없이 이용자 요청에 포함된 쿠키를 신뢰하고, 이용자 인증 정보를 식별하기 때문에 공격자는 쿠키에 타 계정 정보를 삽입해 계정을 탈취할 수 있다.
4. 익스플로잇
문제를 해결하기 위해서는 쿠키에 존재하는 username을 "admin"문자열로 변경하여 서버에 요청해 flag를 찾아야 한다.
웹 브라우저의 개발자 도구를 사용하면 쿠키의 정보를 확인하거나 수정할 수 있다.
5. 마치며
서버가 검증 없이 쿠키를 신뢰하고 인증 정보를 식별할 때 문제가 발생할 수 있다. 이러한 문제들은 세션을 사용하면 해결할 수 있다.
세션은 인증 정보를 서버에 저장하고, 랜덤한 키를 클라이언트에 발급한다. 클라이언트는 해당 키를 포함해 서버에게 요청하고, 서버는 저장한 세션 키와 대응하는 클라이언트인지 확인하므로 안전한 서비스를 구현할 수 있다.
[cookie]
Same Origin Policy
[Mitigation : Same Origin Policy]
1. 들어가며
이용자가 악의적인 페이지를 접속했을 때, 페이지가 자바스크립트를 사용해 이용자의 SNS 웹 서비스로 요청을 보낸다면, 브라우저는 요청을 보낼 때 헤더에 해당 웹 서비스 쿠키를 포함시킬 것이다.
따라서 자바스크립트로 요청을 보낸 페이지는 로그인 된 이용자의 SNS 응답을 받을 수 있고, 마음대로 페이지 접속자의 SNS에 글을 올리거나, 삭제하고, SNS 메신저를 읽을 수 있다.
이와 같은 문제를 방지하기 위해 동일 출처 정책, Same Origin Policy (SOP) 보안 메커니즘에 대해 배울 것이다.
2. Same Origin Policy (SOP)
1) SOP
브라우저는 인증 정보로 사용될 수 있는 쿠키를 브라우저 내부에 보관한다. 그리고 이용자가 웹 서비스에 접속할 때, 브라우저는 해당 웹 서비스에서 사용하는 인증 정보인 쿠키를 HTTP 요청에 포함시켜 전달한다.
브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송한다.
이 특징 때문에 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고, HTTP 응답 정보를 획득 하는 코드를 실행할 수 있는데, 이는 정보 유출과 같은 보안 위협이 생길 수 있다.
따라서, 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 하기 위해서 브라우저의 보안 메커니즘인 동일 출처 정책 (Same Origin Policy, SOP)을 사용한다.
2) Origin 구분 방법
오리진은 프로토콜(Protocol Scheme), 포트(Port), 호스트(Host)로 구성된다. 구성 요소가 모두 일치해야 동일한 오리진이라고 한다.
3) SOP 실습
SOP는 Cross Origin이 아닌 Same Origin일 때만 정보를 읽을 수 있다.
3. Cross Origin Resource Sharing (CORS)
1) SOP 제한 안화
웹 서비스에서 SOP를 완화하여 다른 출처의 데이터를 처리 해야 하는 경우가 있다. 각 서비스의 Host가 다르기 때문에 브라우저는 각 사이트의 오리진이 다르다고 인식한다.
이러한 환경에서, 이용자가 수신한 메일의 개수를 메인 페이지에 출력하려면, 개발자는 메인 페이지에서 메일 서비스에 관련된 리소스를 요청해야 한다. 이 때, 두 사이트는 오리진이 다르므로 SOP를 적용받지 않고 리소스를 공유할 방법이 필요하다.
위와 같은 상황에서 자원을 공유하기 위해 사용할 수 있는 공유 방법을 교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)라고 한다. 교차 출처의 자원을 공유하는 방법은 CORS와 관련된 HTTP 헤더를 추가하여 전송하는 방법, JSON with Padding (JSONP) 방법을 사용할 수도 있다.
2) CORS
교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)는 HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법이다. 발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정한다.
CORS preflight는 수신측에 웹 리소스를 요청해도 되는지 질의하는 과정을 의미한다.
브라우저는 수신측의 응답이 발신측의 요청과 상응하는지 확인하고, 그때야 비로소 POST 요청을 보내 수신측의 웹 리소스를 요청하는 HTTP 요청을 보낸다.
3) JSONP
JSONP 방식은 <script> 태그로 Cross Origin의 데이터를 불러오는데, <script> 태그 내에서는 데이터를 자바스크립트의 코드로 인식하기 때문에 Callback 함수를 활용해야 한다. Cross Origin에 요청할 때 callback 파라미터에 어떤 함수로 받아오는 데이터를 핸들링할지 넘겨주면, 대상 서버는 전달된 Callback으로 데이터를 감싸 응답한다.
Cross Origin에서는 응답할 데이터를 myCallback 함수의 인자로 전달될 수 있도록 myCallback으로 감싸 Javascript 코드를 반환해준다.
다만 JSONP는 CORS가 생기기 전에 사용하던 방법으로 현재는 거의 사용하지 않는 추세로, 새롭게 코드를 작성할 때에는 CORS를 사용해야 한다.
4. 마치며
[퀴즈 : Same Origin Policy]
