브라우저 보안

1. XXS

flowchart LR C([Attacker Web Browser]) -->|sends XXS payload| D[Server] D <-->|victim views XXS payload| E([Victim Web Browser])

클라이언트가 서버를 신뢰하기 때문에 발생하는 보안이슈이다. 클라이언트는 서버로 부터 받는 데이터를 정상 데이터라고 생각하고 일방적으로 받아들인다. 그리고 서버에서 받은 리소스를 처리하여 돔 오브젝트에 반영한다. 스크립트 인젝션(Script Inject) 공격은 이러한 방식의 취약점을 이용한 것으로 서버에 부적절한 스크립트를 전송한다.

보안상 문제로 innerHTML 대신 textCotent를 사용하라는 이야기를 종종 들어보았을 것이다. 그 이유는 innerHTML이 XXS 공격에 취약하기 때문이다. 다음 코드를 innerHTML과 textContent로 출력하면 어떻게 될까.

<button></button>

전자는 버튼이 웹 상에 렌더링되며, 후자는 버튼이 아닌 텍스트로 출력된다. 버튼이 아닌 치명적인 코드가 들어간다면, 개인정보 유출 등 심가한 이슈가 발생했을 것이다.

2. CSRF

반대로 CSRF는 서버가 클라이언트를 신뢰하여 발생하는 보안이슈이다. 서버가 클라이언트의 신뢰도를 판단하는 기준은 인증정보를 가지고 있는지이다. 만약, 사용자가 인증정보를 가진 상태에서 해커가 가진 링크를 눌렀다고 생각해보자. 해커는 다른 사용자의 인증정보를 가로채서 서버에 요청을 보낼 수 있게 된다.

실제로 해당 유저가 원한 것이 아님에도 요청이 보내질 수 있다. 원치않는 회원정보 변경, 출금, 결제가 행해질 수 있다.

3. 교차 출처 리소스 공유 - CORS(Cross-Origin Resource Sharing)

CORS는 웹 어플리케이션을 이용하는 사용자들을 보호하기 위한 브라우저의 정책이다. 주로 XMLHttpRequest 또는 Fetch와 같은 API 호출에서 CORS를 사용하여 교차 출처 HTTP 요청의 위험을 완화한다. 그 외에 어떤 요청이 CORS를 사용하는지는 MDN - 어떤 요청이 CORS를 사용하나요를 참고하자.

3. 1. 교차 출처

다음은 https://domain-a.com의 프론트 엔드 자바스크립트 코드가 XMLHttpsRequest를 사용하여 리소스를 요청하는 경우이다.

위 그림은 네이버 Fetch API로 GET 메소드를 요청한 것이다. 해당 도메인https://www.naver.com에 접속하여 리소스를 요청하면 정상적으로 프로미스를 반환한 것을 확인할 수 있다. 반면, 다른 도메인(blank page)에서 요청한 경우 CORS 정책에 따라 리소스 요청을 거부했다는 메시지를 확인할 수 있다.

3. 2. 사전전달(Preflight)

CORS는 허용된 출처를 서버에 설명할 수 있는 HTTP 헤더를 추가하여 작동한다. 또한 서버에 요청하는 메소드 중 특정 메소드들은 브라우저가 먼저 OPTIONS 메서드로 요청을 사전전달(Preflight)한다. 그리고 서버에서 해당 메서드를 사용할 수 있다는 허가를 받고나서야 실제 요청을 보내게 된다.

위 그림을 보도록 하자. CORS정책에 따라 특정 메소드는 해당 요청을 보내기 전에 OPTIONS 메소드로 먼저 허가를 요청한다고 했다. 크롬 개발자 도구 네트워크 탭에서 이 과정을 확인할 수 있다. 첫 번째 그림은 OPTIONS1 요청이 받아들여지지 않은 상황이다. 두 번째 그림은 클라이언트의 OPTIONS 요청을 서버가 허가를 내렸다. 이후에 실제 요청을 보낸 것을 확인할 수 있다.

서버는 클라이언트에게 쿠키, HTTP인증 등 인증정보를 함께 보내야 한다고 알려줄 수도 있다.

리소스 접근 요청 시나리오는 MDN - 접근 제어 시나리오 예제의 예제를 보도록 하자.