XSS(Cross-Site Scripting)는 해커가 특정 사이트를 이용하고 있는 사용자의 정보를 가져갈 때 사용하는 공격 방법이다. 앞 글자를 따면 CSS이지만 CSS는 이미 존재하는 용어이기 때문에 XSS로 부른다고 한다. XSS에 대해 설명하기 보다는 XSS에 대해 공부를 하면서 느꼈던 것을 적어보려고 한다.
지금까지 우테코에서 미션을 하면서 로그인 관련 미션이 나올 때마다 항상 거론되었던 것이 토큰을 웹 스토리지 중 어디에 저장할 것인가였다. 대부분이 고려했던 것이 로컬 스토리지, 세션 스토리지, 쿠키였다. 미션은 기간이 짧기 때문에 이것에만 며칠을 소비할 수 없어서 번갈아 가면서 사용했던 것 같다. 보안 상 이슈가 있다는 것만 알아두고..
세션 스토리지는 탭을 닫으면 함께 사라지기 때문에 나의 고려 사항은 아니었다. 그래서 로컬 스토리지와 쿠키를 많이 비교했었다. 이때, 나오던 것이 XSS와 CSRF였다. 로컬 스토리지와 쿠키 모두 XSS에 취약했다. 하지만 쿠키는 상황이 조금 더 좋았는데, HttpOnly를 사용하면 XSS를 방어할 수 있기 때문이다.
XSS는 사용자의 정보(토큰)를 가져가는 것이라고 했다. 로컬 스토리지에 토큰이 저장되어 있다면 해커가 이것을 가져갈 수 있다고 알고 있었다. 그러다가 갑자기 궁금해졌다. 어떻게 토큰을 가져갈 수 있을까? 방법은 innerHTML에 있었다.
만약 게시글을 작성하는 곳에서 innerHTML로 게시글을 화면에 표시하고 있다고 생각해보자. 그 안에 script 태그가 존재한다면 자바스크립트가 실행되면서 해당 script 태그를 해석할 것이고, script 태그 안의 구문이 실행될 것이다. 그렇게 되면 해당 게시글을 읽는 사용자는 영문도 모른 채 자신의 토큰을 해커의 서버로 전송하고 있을 것이다. 물론 HTML5부터 script 태그는 어느 정도 방어를 해주기 때문에 script 태그 공격은 통하지 않을 수도 있다. 하지만 img 태그나 iframe 태그, svg와 같은 공격을 할 수 있는 여러 방법이 존재한다.
다른 방법으로 사용자가 XSS란?을 검색했을 때, XSS란? 에 대한 검색 결과입니다.라는 텍스트를 innerHTML으로 표시하고 있고, /?search=XSS란? 이라는 query를 받고 있다고 생각해보자. 그러면 이제 주소창을 사용해서 XSS 공격을 할 수도 있다. 이렇게 innerHTML은 굉장히 위험하다.
이렇게 이해를 했고, 그렇다면 innerHTML을 사용하지 않는 리액트에서도 XSS 공격이 가능할까가 궁금해졌다. 왜냐하면 내가 로컬 스토리지를 사용하지 않고 쿠키를 더 선호했던 가장 큰 이유는 쿠키는 XSS 공격을 완벽하게 방어할 수 있었기 때문이다. 하지만 리액트에서 XSS 공격이 방어되어 있다면 로컬 스토리지를 사용하지 않을 이유가 없었다.
몇 차례 실험을 거쳐봤고, DangerouslySetInnerHTML을 사용하지 않는다면 리액트에서는 XSS 공격을 할 수 없다는 결론을 내렸다. 아, 물론 a 태그의 href나 button의 formaction과 같은 속성들을 사용자의 input으로 받고 있다면 얘기가 달라지지만... 아직까지 이렇게 개발을 해야 했던 경우는 없어서 잘 모르겠다.
결국, 리액트에서 XSS는 어느 정도 안정성이 보장된 것 같다는 느낌을 받았다. 그래서 쿠키의 경우에는 로컬 스토리지에 저장하는 것도 괜찮은 방법이라고 생각한다. 왜냐하면 쿠키의 보안성 때문에 2023년에는 크롬에서 쿠키를 삭제해버린다는 얘기도 들려오기 때문이다.
이 글을 작성하면서 이제 로컬 스토리지나 쿠키 같은 스토리지 말고 indexedDB를 활용하는 것이 좋다는 구글 개발 팀의 글을 보게 되었다. 이 부분도 충분한 조사를 하고 글을 작성해봐야겠다.
