Tabnabbing 피싱 공격에 대해 알아보기. (noopener, noreferrer)
리액트를 통해 개발을 하던 도중 a태그의 target="_blank"속성 값을 사용할 일이 있었는데
이런 경고를 발견했습니다.
a태그의 target="_blank" 속성 값을 사용할 때 rel="noreferrer"속성이 없다면 보안에 문제가 생길 수 있다고 말하고 있어서 이게 뭘까 하고 찾아봤는데 Tabnabbing이라는 피싱 공격을 막기 위해 만들어진 속성이라고 합니다.
그래서 이 Tabnabbing이 무엇이고 어떤 방식으로 동작하는지에 대해 알아보고
이 공격을 막기 위해 사용되는 a태그의 rel속성값인 noopener와 noreferrer에 대해서도 알아보겠습니다.
Tabnabbing
사진 출처: https://blog.jxck.io/
Tabnabbing은 피싱 공격중 하나로 공격 방식은 위의 사진과 같습니다.
a태그의 target="_blank"속성이 적용된 링크(새 탭으로 열리는 링크)를 사용자가 클릭하게 되면 피싱용으로 만들어진 페이지가 새 탭에서 띄워지고
링크를 클릭했던 기존 페이지는 로그인 화면과 같이 사용자의 정보 입력을 유도하는 피싱페이지로 바뀌게 됩니다.
그럼 이게 도대체 어떻게 가능한걸까요?
target="_blank" 속성값을 가진 링크를 클릭하게 되면 새 탭에서는 링크가 있던 기존 탭에 대한 참조가 가능합니다.
이 기존 탭에 대한 정보가 전역객체인 window내부의 opener에 들어있고
여기서 href속성 값을 변경하게 되면 기존 탭의 URL이 변경됩니다.
따라서 이런 링크를 클릭하게 되면 기존 탭의 페이지가 해커가 만들어 놓은 기존과 유사한 피싱용 사이트로 바뀌게 되고 사용자의 ID와 비밀번호 같은 정보 입력을 유도하게 됩니다.
예를들어 사용자가 자신의 메일에서 이런 링크를 클릭했다면 기존의 메일 페이지는 해당 사이트의 로그인 페이지와 똑같이 생긴 피싱용 사이트로 바뀌면서 사용자는 로그인이 풀린 것이라고 착각하여
자연스럽게 해커가 만들어놓은 피싱용 사이트에서 자신의 정보를 입력한 후 로그인버튼을 누르게 되고
해당 정보는 해커에게 전달되며 해커는 기존 메일페이지로 다시 이동시켜 사용자가 자신의 정보가 유출된 사실을 인지하지 못하게끔 합니다.
그래서 이런 공격을 방지하기 위해 target="_blank"속성을 사용하는 태그들에 넣어주어야하는
rel 속성값 noopener와 noreferrer가 만들어졌습니다.
noopener
rel="noopener"라는 속성값은 링크를 클릭해 새 탭에서 열리더라도 window.opener가 항상 null인 상태로 유지되도록 합니다.
즉, 더이상 새 탭에서 기존 탭에 대한 접근이 불가능하도록 합니다.
이는 피싱 공격 방지뿐만 아니라 기존탭과 새 탭의 쓰레드도 분리되어 성능상의 이점도 있습니다.
(opener객체를 참조하고 있을 경우 2개의 탭은 같은 쓰레드를 사용함.)
다행히 대부분의 모던 브라우저(크롬, 엣지, 파이어폭스 등)는 a태그에 target="_blank" 속성이 지정되어있을경우 noopener를 적용한 것과 똑같이 동작하지만
IE의 경우 자동으로 적용이 되지 않으며 noopener도 지원하지 않기 때문에 noreferrer라는 값을 명시해 주어야 합니다.
하지만 모던 브라우저에서도 href속성과 target="_blank"속성을 사용하는 다른 태그들 모두 방지되어있지만 유일하게 form태그로는 참조가 가능했습니다.
form태그를 이용해 크롬에서 기존탭에 접근하기.
noreferrer
새 탭으로 열리는 링크를 클릭하게 되면 기존 탭의 URL정보가 요청 헤더에 포함되어 새탭으로 요청을 보내게 됩니다.
따라서 새 탭의 서버에서는 사용자가 어떤 사이트의 링크를 통해 접근한건지 알 수 있습니다.
noopener는 window의 opener를 null로 설정하는 반면
이 값은 헤더로 전달되는것을 막기 때문에 noopener처럼 tabnabbing 공격을 막는것도 가능하면서
기존 탭의 대한 정보 전달을 막는 목적도 있습니다.
그래서 Google Analytics와 같이 방문자의 유입경로를 추적하는 프로그램에서는 정상적으로 이동경로를 추적하지 못하게 되므로 사용자가 링크를 통해 넘어온것이 아니라 사이트에 직접 접근한것으로 인식하게 됩니다.
그리고 referrer는 쉽게 조작이 가능하기 때문에 신뢰성이 떨어진다고 볼 수 있습니다.
referrer 임의 조작
그래서 보통 광고성 링크의 경우에는 헤더의 referrer를 기준으로 판별하지 않고 해당 링크에 고유한 id등을 query에 붙여 사용하므로 noreferrer의 영향을 받지 않는 경우가 많습니다.
