프롤로그
Mitigation : Same Origin Policy 을 대충 해석해보니까 완화/진정 : 같은 원산 정책이라고 적혀있는 걸 보아하니 뭔가 Same Origin Policy 라는 정책으로 무언갈 완화 시키는 것 같다.
https://learn.dreamhack.io/186#
Same Origin Policy(SOP)
쿠키는 브라우저 내부에 보관되고, 이 쿠키를 HTTP 요청에 포함시켜 전달한다.그런데 이게 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하는 특징을 가지고 있다.
그래서 악의적인 페이지가 클라이언트의 권한을 얻기 위해 이 쿠키를 얻으면 보안 위협이 생겨버린다. 그냥 세션 id 악의적으로 A한테 받을 거 나한테 받는다 이런 의미인 것 같다.
이를 막기 위해 동일 출처 정책(SOP)를 이용한다.
SOP의 오리진(Origin) 구분 방법
원본 : https://same-origin.com/
(1) https:// 가 아닌 http:// 로 접근 -> Sheme이 다름
(2)same-origin이 아닌 cross.same-origin/으로 접근 -> Host가 다름
(3) https://....:1234 ->Port 가 다름
위 1, 2, 3과 같이 Scheme, Host, Port 가 다르면 Cross Origin 이고, 원본 뒤에 아무거나 붙는 건 상관이 없다.
Same Origin Poilicy 실습
(1) Same Origin
(2) Cross Origin
출력에 오류가 생긴다
그러나, 데이터 읽기/쓰기에는 문제가 되지 않는다
SOP 제한 완화
이미지, JS, CSS 등의 리소스를 불러오는 태그들은 SOP의 영향을 받지 않는다.
추가적으로 naver.com 에서 cafe.naver.com으로 넘어가는 식으로 가는 것도 동일 출처라고 판단되어야 하는데 HOST가 다르다 보니 SOP에 걸린다. 이걸 어떻게 해결해야하나...하면 교차 출처 리소스 공유(Cross Origin Resource Sharing, CORS)가 필요하다.
CORS 와 관련된 HTTP 헤더를 추가하여 전송하는 방법을 사용한다.
Cross Origin Resource Sharing(CORS)
교차 출처 리소스 공유는 HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법.
발신 측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정
POST방식으로 요청해도 OPTIONS 메소드를 가진 HTTP요청이 전달됨(CORS PreFilight)
수신측의 응답이 발신측의 요청과 상응하는지 확인하고, 그때야 비로소 POST요청을 보내 수신측의 웹 리소스를 요청하는 HTTP 요청을 보냄.
(1) Access-Crontrol-Allow-Origin : 헤더값에 해당하는 Origin에서 들어오는 요청만 처리
(2) Access-Control-Allow-Methods : 헤더 값에 해당하는 메소드의 요청만 처리
(3) Access-Control-Allow-Credential : 쿠키 사용 여부 판단
(4) Access-Control-Allow-Headers : 헤더값에 해당하는 헤더의 사용가능 여부
에필로그
CORS 까지는 잘 모르겠음. 확실히 웹 개발 한 번 해보니까 처음 익혔을 때보다 이해는 더 잘 되긴 함.
'보안 스터디 > 웹 해킹' 카테고리의 다른 글
[드림핵/워게임] CSRF-1 (웹해킹) (1) | 2024.01.07 |
---|---|
[드림핵/웹해킹] ClientSide: CSRF (1) | 2024.01.06 |
[드림핵/워게임] xss-2 (웹 해킹) (1) | 2024.01.05 |
[드림핵/워게임] session-basic (웹해킹) (1) | 2024.01.03 |
[드림핵/워게임] cookie (웹해킹) (1) | 2024.01.02 |