11/12[TIL]Browser Security

어제 정리했던 웹 아키텍처를 이어서 Browser Security를 다루어보고자 한다.

 

우리가 사용하는 브라우저는 javascript를 구동하기 때문에 공격을 받을 수 있다고 한다.

 

이러한 공격의 종류에는 XSS와 CSRF가 존재한다.

 

XSS(Cross Site Scripting)

클라이언트가 서버를 신뢰하기 때문에 발생하는 이슈이며 지금은 기본적인 xss 공격은 브라우저에서 막혀있다.

XSS는 보안이 약한 웹 애플리케이션에 대한 웹 기반 공격이며 공격의 희생자는 애플리케이션이 아닌 사용자이다. 보통 js를 통해서 전달되며 이는 해커가 서버에 코드를 심어 놓으면 사용자가 이를 아무 생각 없이 받아서 사용자의 브라우저 상에서 실행되어버리는 상황을 말한다.

 

CSRF(Cross-Site Request Forgery)

앞서 언급한 XSS와는 반대로 서버가 클라이언트를 신뢰해서 발생하는 이슈이며 보통 서버는 인증정보를 가지고 오면 믿는다. 그런데 사용자는 인증정보를 가진 채로 예를 들어 해커의 링크를 누르게 된다면 해커는 인증정보를 가로채서 서버에 요청을 보내 버리고 그럼 서버는 해커가 아닌 클라이언트라고 생각하게 된다.

 

앞서 공격의 두 종류를 보았는데 이러한 공격들을 막아내는 방법도 많이 존재했고 앞서 언급했듯이 지금은 기본적인 xss 공격은 브라우저에서 막혀있다.

 

브라우저의 공격 측인 면 말고도 유저들을 보호하기 위한 것도 있다. 내가 좀 이해하는 데에 시간이 좀 걸렸던 CORS이다.

 

CORS(Cross-Origin Resource Sharing)

 

CORS는 추가적인 http header를 사용하여 한 서버에서 실행 중인 웹이 다른 서버의 자원에 접근할 수 있는 권한을 부여받게 하는 방법이다.  간단히 말하면 브라우저가 자발적으로 브라우저의 애플리케이션을 사용하는 유저들을 보호하기 위한 정책이라고 이해하면 될 듯하다.

옛날에는 클라이언트 서버가 같이 있기도 했지만 지금은 많은 클라이언트들과 서버가 존재하기에 현대의 시스템이 cors를 만들었다고 보면 될 것 같다.

cors 설정은 서버에서 해주며 모든 요청을 다 받던지 한 곳만 허용할 수 있다. 프로토콜 / 도메인 / 포트 중 하나라도 안맞으면 크로스 오리진이다.

교차 출처 리소스 공유가 동작하는 방식을 보여주는 세 가지 시나리오가 존재하는데 SimpleRequest / PreflightedRequest / Request with Credentials이다.

 

 

SimpleRequest는 조건들이 좀 많은데 이 조건들을 모두 충족할 때이다.

너무 많아서 출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/CORS 링크를 걸어둔다.

 

PreflightedRequest

 

preflight request 내가 원하는 header

이전에 options 가 감(다음번 요청을 허용할지 안 할지) 그 후에 post가 간다.

모든 cross origin 요청이 preflight request를 발생시키는 것은 아니다.

실제 요청이 안전한지 서버가 미리 파악할 수 있도록 하는 수단이다.

실질적인 요청 전, OPTIONS 메서드를 통해 발생한다. 허용하지 않는다면 오류가 뜬다.

 

js 코드가 실행이 되면 브라우저가 자발적으로 심플리 퀘스트가 아니다면 preflight request를 한다는 것 (서버에) 그리고 실제 내가 원했던 request가 가게 되고 그 응답을 받게 된다.

 

Request with Credentials

내가 서버에 요청을 할 때 쿠키 있는 정보를 같이 보낼 것인가?

ex) 로그인하지도 않았는데 장바구니 사용기능