📒 What is SOP?
SOP : Critical Security Mechanism이다.
좀 더 자세히 알아보자면, 한 Origin으로 부터 로드된 리소스가 다른 Origin의 리소스와 상호작용 할 수 있는 방법을 제한하는 보안 메커니즘이다.
Origin은 Scheme, Host, Port까지 비교를 하는데
document.location.origin로 확인할 수 있다.
실제로 글을 작성하고 있는 지금 Origin은 'https://velog.io' 가 된다.
이런 경우에서 Velog 내에 다른 Origin의 Resource가 존재한다면 제한을 준다는 것이 바로 Same Origin Policy이다.
위에 작성했듯이 Scheme, Host, Port가 같다면 Same Origin으로 판단한다.
📖 When does apply?
그래서 어떤 경우에 SOP가 적용되는 것일까.
우선 예시를 들어보자.
http://test.com 내에서 http://api.test.com 의 Json을 읽어오고자 한다면 서로의 Host가 다르기에 데이터를 읽어올 수가 없다.
즉 XHR을 사용하여 open을 한 경우,
window.open을 사용한 경우
iframe 태그를 사용한 경우
접근이 제한된다.
웹에는 Local Storage, Session Storage 같은 데이터베이스가 있는데, 이는 Origin마다 생성이 된다. 따라서 이 때에도 접근을 하고자 한다면 Same Oirgin을 만족해야 한다.
📒 If there is no SOP?
📖 1. iframe
해커의 홈페이지에 아래와 같은 태그가 적혀있다고 생각을 해보자.
<iframe id="mail" src="https://mail.test.com/inbox"></iframe>만약 유저가 구글 자동로그인이 되어있는 상태라면, 그 쿠키값을 붙여서 해당 iframe을 열게 될 것이다. mail.test.com에서도 유저임을 판단하고 그 메일 내용들은 저 iframe에 들어가지게 된다.
그 때 스크립트에서 getElementById("mail")을 사용한다면 해당 내용을 공격자의 서버로 보낼 수 있게 된다.
그러면 해커는 유저의 메일을 볼 수 있게 되어버린다.
결론은, 유저가 링크 한 번 눌렀다고 메일들을 탈취하게 되어버리는 것이다.
만약 SOP가 있다면 어떻게 될까?
iframe까지는 정상적으로 내용이 들어가진다.
하지만 해커의 페이지와 mail.test.com의 Origin이 다르기에 해커의 document에서 iframe 내부의 document를 참조하지 못하게 된다.
따라서 공격자의 서버로 아무런 데이터를 보낼 수 없게 되는 것이다. 이는 iframe 태그를 격리시킨다고 생각하라 수도 있게 된다. Cross-Origin의 경우 상호간의 document에 접근을 못한다는 것을 확인할 수 있게 되는 것이다.
하지만 데이터 교환이 필요할 때도 있을 것이다.
그 때 아래를 사용 가능하다.
window.postMessage📖 2. XMLHttpRequest
두 번째는 XHR(XMLHttpRequest)를 보자.
xhr.open('GET', 'http://mail.test.com/inbox', true);
xhr.send(null);이 코드를 통해 mail.test.com에 로그인 되어 있다면 쿠키가 자동으로 붙여서 전해진다. 따라서 inbox내의 값을 확인할 수 있다.
xhr.onreadystatechange = payloadencodeURIComponent(xhr.responseText);xhr 값을 받아들였을 때 payload함수를 실행하고, payload 함수 내에 아래 코드와 같이 들어있다고 생각을 해보자.
만약 SOP가 적용되어있지 않다면 아무런 문제 없이 실행될 것이다.
하지만 SOP가 적용되어 있기에 네트워크 API를 통해 다른 서버에 접근을 하게 된다면 요청은 보낼 수 있지만, 그 데이터를 읽을 수가 없다. 아마 XHR의 경우에는 데이터를 읽을 때 Same-Origin 여부를 확인한다고 추측할 수 있다.
논외로 중요한 것은 네트워크 API를 통해 Write는 가능하다는 것이다. 따라서 xhr.open을 할 때 POST 메소드를 통해 넘긴다면 CSRF 공격은 충분히 발생할 수 있다. 이를 방지하기 위한 방법이 SameSite cookies를 비교하는 거구나 ~! 미쳤다.
내가 정리한 SameSite Cookie(클릭)
자세히 작성한 내용이다...
만약 내용을 읽게 하고 싶다면 Access-Control-Allow-Origin 헤더를 설정하면 된다. 그 헤더에 http://hacker.com 을 넣어놓으면 되는 것이다. 그렇다면 Cross-Origin 이어도 허용 Origin에 있기에 읽어들일 수 있는 것이다.
📒 Cross-Origin embedding Vulnerability
사실 이걸 취약점이라고 작성해도 될 지는 모르겠다.
우선 Cross-Origin을 embedding 방식으로는 자원 접근이 가능하다.
<script>
CSS
<img> <video> <audio>
<object> <embed>
@font-face
<iframe>이런 요소들이 embedding 방식이다.
만약 페이스북이 로그인을 한 유저라면 300짜리 픽셀을, 로그인하지 않은 유저라면 100픽셀짜리 사진을 반환한다고 생각해보자.
그렇다면 해당 정보를 가지고 로그인이 되어있는 지, 안되어있는 지를 판단할 수 있을 것이다.
📒 How to Cross-Origin Network access
만약 Cross-Oirigin간의 통신이 필요하다면 어떻게 해결을 해야할까.
앞서 말했듯이 resp packet의 header에 Access-Control-Allow-Origin을 추가해 허용할 Origin들을 넣어주어야 한다.
이는 꼭 응답 헤더에서 넣어주어야 한다. 즉 해커가 임의로 설정하지 못한다고 봐야겠다.
JSONP는 표준이 아니므로 사용하지 말자. 모든 정책을 다 열어버리게 된다.
