728x90

클라이언트 사이드 취약점 : 웹 페이지의 이용자를 대상으로 공격할 수 있는 취약점

Cross Site Scripting (XSS)

공격자가 웹 리소스에 악성 스크립트를 삽입해 이용자의 웹 브라우저에서 해당 스크립트를 실행 할 수 있는 것
-> 이를 통해 세션 정보 탈취하여 임의의 기능 수행

  • Stored XSS : XSS에 사용되는 악성 스크립트가 서버에 저장되고 서버의 응답에 담겨오는 XSS, 서버의 데이터베이스 또는 파일 등의 형태로 저장된 악성 스크립트를 조회할 때 발생
  • Reflected XSS : XSS에 사용되는 악성 스크립트가 URL에 삽입되고 서버의 응답에 담겨오는 XSS, 서버가 악성 스크립트가 담긴 요청을 출력할 때 발생, 이용자의 요청에 의해 발생, Click Jacking 또는 Open Redirect 등 다른 취약점과 연계하여 사용
  • DOM-based XSS : XSS에 사용되는 악성 스크립트가 URL Fragment에 삽입되는 XSS
  • Universal XSS : 클라이언트의 브라우저 혹은 브라우저의 플러그인에서 발생하는 취약점으로 SOP 정책을 우회하는 XSS

'Study > Web Hacking' 카테고리의 다른 글

[웹] Dreamhack Cookie&Session  (0) 2024.04.03
728x90

쿠키

  • HTTP 프로토콜 특징
    • Connectionless : 하나의 요청에 하나의 응답을 한 후 연결을 종료
    • Stateless : 통신이 끝난 후 상태 정보를 저장하지 않음
  • HTTP에서 상태를 유지하기 위해 쿠키(Cookie) 탄생
  • 쿠키 = Key+Value (일종의 단위)
  • 서버가 클라이언트에게 쿠키 발급 -> 클라이언트는 서버에 요청을 보낼 때마다 쿠키 같이 전송 -> 서버는 이를 통해 클라이언트 구분

쿠키의 용도

  • 클라이언트의 정보 기록과 상태 정보를 표현
  • 정보 기록 : "다시 보지 않기", "7일 간 표시하지 않기" 등의 팝업 옵션을 기억
  • 상태 정보 : 클라이언트를 식별할 수 있는 값을 쿠키에 저장

쿠키가 없는 통신 vs 쿠키가 있는 통신

  • 쿠키가 없는 통신 : 서버는 요청을 보낸 클라이언트가 누군지 알 수 없기 때문에 현재 어떤 클라이언트와 통신하는지 알 수 없음
  • 쿠키가 있는 통신 : 클라이언트는 서버에 요청을 보낼 때마다 쿠키를 포함하고, 서버는 해당 쿠키를 통해 클라이언트를 식별

쿠키 변조

쿠키 -> 클라이언트 브라우저에 저장
따라서 악의적인 클라이언트는 쿠키 정보를 변조해 서버에 요청을 보낼 수 있음

이에 대해 서버가 검증을 하지 않는다면 사칭으로 정보를 탈취할 수 있음

세션

: 쿠키에 인증 상태를 저장하지만 클라이언트가 인증 정보를 변조할 수 없게 하기 위해 사용

 

인증 정보를 서버에 저장하고 해당 데이터에 접근할 수 있는 키(Session ID ,유추할 수 없는 랜덤 문자열)를 만들어 클라이언트에 전달하는 방식

브라우저는 해당 키를 쿠키에 저장하고 이후에 HTTP 요청을 보낼 때 사용, 서버는 요청에 포함된 키에 해당하는 데이터를 가져와 인증 상태 확인

 

쿠키 : 데이터 자체를 이용자가 저장
세션 : 서버가 저장

쿠키 적용법

클라이언트가 서버에 요청을 보낼 때 저장된 쿠키를 요청 헤더에 넣어 전송하기 때문에 이용자가 요청을 보낼 때 쿠키 헤더를 변조할 수 있다. 쿠키를 설정할 때에는 만료 시간을 지정할 수 있고, 만료 시간 이후에는 클라이언트에서 쿠키가 삭제된다.

 

서버 : HTTP 응답 중 헤더에 쿠키 설정 헤더(Set-Cookie)를 추가하면 클라이언트의 브라우저가 쿠키 설정

HTTP/1.1 200 OK
Server: Apache/2.4.29 (Ubuntu)
Set-Cookie: name=test;
Set-Cookie: age=30; Expires=Fri, 30 Sep 2022 14:54:50 GMT;
...

 

클라이언트 : 자바스크립트를 사용해 쿠키 설정

document.cookie = "name=test;"
document.cookie = "age=30; Expires=Fri, 30 Sep 2022 14:54:50 GMT;"

consle 창에 document.cookie 입력 (쿠키 옵션(HttpOnly)에 따라 자바스크립트에서 쿠키 확인이 불가능 할 수 있음)
application 탭에 목록 중 Cookies를 펼치면 Origin 목록 확인 가능, 이 Origin을 누르면 쿠키 정보 확인 및 수정 가능

 

* 세션 하이재킹 (Session Hijacking)
: 공격자가 이용자의 쿠키를 훔칠 수 있으면 세션에 해당하는 이용자의 인증 상태를 훔칠 수 있음

Same Origin Policy(SOP)

웹 서비스에 접속할 때, 브라우저가 쿠키를 HTTP 요청에 포함시켜 전달하는 특징은 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 적용되기에 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고, 응답 정보를 획득하는 코드를 실행 가능하다.

따라서, 클라이언트 입장에서 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 하는 것이 동일 출처 정책(Same Origin Policy, SOP)이다.

Origin 구분 방법

Origin = Protocol(Scheme) + Port + Host
위의 구성요소가 모두 일치해야 동일한 오리진

 

Origin : https://same-origin.com/

Same Origin : https://same-origin.com/frame.html -> Path만 다름

Cross Origin : http://same-origin.com/frame.html -> Scheme 다름

Cross Origin : https://cross.same-origin.com/frame.html -> Host 다름

Cross Origin : https://same-origin.com:1234/ -> Port 다름 

 

window.open : 새로운 창 띄우는 함수
object.location.href : 객체가 가리키는 URL 주소 읽어오는 코드

Cross Origin Resource Sharing (CORS)

브라우저가 SOP에 구애 받지 않고 외부 출처 접근을 허용하는 경우 : 이미지나 자바스크립트, CSS 등의 리소스를 불러오는 <img>, <style>, <script> 등의 태그
이외에도 SOP를 완화해 다른 출처의 데이터를 처리해하는 경우 존재 : 이용자가 수신한 메일의 개수를 메인 페이지에 출력하려면 메인 페이지에서 메일 서비스에 관련된 리소스 요청해야됨

 

교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS) : HTTP 헤더에 기반하여 Cross Origin 간에 리소스 공유 방법
발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 자져갈 수 있도록 설정

 

CORS preflight : 수신측에 웹 리소스를 요청해도 되는지 질의하는 과정

JSON with Padding (JSONP)

이미지나 JS, CSS 등의 리소스는 SOP에 구애 받지 않고 외부 출처에 대해 접근을 허용한다는 특징을 이용해 <script>태그로 Cross Origin의 데이터 불러온다. Callback 함수 사용해야한다. 요즘에는 잘 사용하지 않는다.

'Study > Web Hacking' 카테고리의 다른 글

[웹] Dreamhack XSS  (0) 2024.04.03

+ Recent posts