TIL #12 Browser Security

Joshua Song / 송성현·2019년 12월 3일

이머시브_16

목록 보기

13/29

Browser Security

브라우저 위협의 가장 큰 이유는 자바스크립트를 구동한다는 점이다.
- Ajax call 을 해서 api 호출
- DOM 제어
- 인증 정보를 브라우저에 저장
- 인증 정보를 불러 올 수도 있다.
한 웹페이지가 렌더 되려면 각기 다른 서버에 여러 번 요청을 보내고, 서로 다른 서버에서 제공하는 리소스를 사용해 이미지, 사진 등 여러가지 부분들을 구현한다. 이 요청들이 안전한 건지에 대한 점검을 하지 않으면 브라우저 보안에 문제가 생기고, 또 해킹의 위협이 있다.
Possible Threats
- XSS
  - 클라이언트가 서버를 신뢰 하기 때문에 발생하는 이슈
  - 보통 서버에 메시지 요청 => 메세지 응답 => 응답 받은 메세지 돔 반영식의 순서로 진행되는데 XSS는 서버에서 코드를 변형해 악의적인 메시지를 응답.
- CSRF
  - 서버가 클라이언트를 신뢰해서 발생하는 이슈
  - 서버는 인증정보를 가지고 오면 믿는다.
    - 사용자가 만약 인증 정보를 가진체로 해커의 링크를 누르면 해커가 가로채서 서버에 요청을 해, 원하는 결과를 본다.
How do we stop this?! => 브라우저 보안 정책 : CORS 와 Same-origin Policy

Same-origin Policy (SOP)

프로토콜, 호스트, 포트 번호가 일치하는 웹페이지들 간의 interaction 만 허락하는 보안 정책.

http://www.rlcjf0014.com/coding.html 이란 url에서 http://www.rlcjf0014.com/design.html 이란 페이지로 이동할 때, 이 이동은 프로토콜(http)도 같고, 각 url의 포트번호(80번은 HTTP의 기본 포트 번호입니다)도 같고, 호스트(www.rlcjf0014.com)도 같기 때문에 문제가 없다.

하지만 http://www.rlcjf000000014.com/coding.html 이란 페이지로는 호스트가 다르기 때문에 이동할 수가 없다. 이것이 Same-origin policy로 보안을 정한거였다.

SOP는 단순하고 철저하지만, 웹 페이지 기술이 발달하며 외부 서버에 대한 리소스 요청이 늘었고 SOP의 유연하지 못하고 엄격함은 오히려 리소스 사용을 불편하게 만들었다. 그래서 대안으로 나온 것이 CORS이다.

uses additional HTTP headers to tell browsers to give a web application running at one origin then access to selected resources from a different origin. origin 서버 바깥에 대한 리소스 요청을 관리하는 방법이다. SOP와는 달리 호스트가 달라도 이동이 가능하다.
- 누가 서버의 리소스에 접근할 수 있는지 결정하고, 어떤 방식으로 접근할 수 있는지도 명시하는 역할을 수행한다.
자원을 공유한다. 코스다. 서로 다른 오리진 간의 리소스를 공유한다. a 라는 도메인에서 오는 HTML이 b 라는 도메인의 이미지를 사용할 때 CORS를 사용.
보안적인 이유로, 브라우저는 cross-origin HTTP request를 스크립트 안에서 실행. 같은 오리진 정책을 따른다. 브라우저가 자발적으로 브라우저의 웹 애플리케이션 사용을 보호한다. 웹 서버를 통해서 사용자의 브라우저 웹 애플리케이션 사용을 보호해준다.
크로스 오리진 리퀘스트면 호출이 될 수도, 안 될수도 있다.
HTTP 헤더에 전송하는 요청 혹은 응답에 대한 정보가 담겨있다. 헤더를 통해 크로스 오리진 요청들을 관리할 수 있다.

Access-Control-Allow-Origin

여러 헤더들 중, 이 헤더는 서버의 리소스를 어떤 외부 도메인과 공유할 것인지 공유할 수 있다. 서버의 이 헤더 값이 *면 어떠한 도메인이라도 접근할 수 있고 특정한 도메인이면, 해당 도메인의 접근만 허용된다.
다른 method들은 :
- Access-Control-Expose Headers: 서버가 특정 헤더가 브라우저에 노출되게 해준다.
- Access-Control-Max-Age: 프리플라이트 요청이 얼마나 cache(저장)돼 있을지 보여준다.
- Access-Control-Allow-Credentials: 인증 플래그가 사실일 때, 요청에 대한 응답이 노출되도 되는지 안되는지 보여준다.
- Access-Control-Allow-Methods: 리소스에 접근할 때 허락된 method를 특정지어 준다.
- Access-Control-Allow-Headers: 프리플라이트 요청에 대한 응답으로 사용되는데 HTTP 헤더가 실제 요청을 만들때 사용될 수 있는지 보여준다.

CORS를 사용하는 리퀘스트:**

Fetch 나 XMLHttpRequest 호출이 사용한다.

Simple Request

Doesn't trigger CORS preflight
Has to be one of
- GET
- HEAD
- POST
기본적으로 세팅되는 헤더로만!
Content-type
- `application/x-www-form-urlencoded``
- multipart/form-data
- text/plain

Preflight Request

프리블라이트 요청은 OPTIONS method를 사용해 HTTP 요청을 보내 실제 요청이 안전한지 안한지 확인을 한다.
만약 안전하지 않을 경우, 아니면 브라우저가 redirection을 지원하지 않는 경우, 에러 메시지를 보여준다.

XSS

Cross-Site Scripting

클라이언트에 악성 스크립트를 주입하는 공격.
공격하는 쪽이 있고 방어하는 쪽이 있으면, 공격은 웹 브라우저를 통해 웹 애플리케이션에 XSS payload를 보낸다. 그러면 웹 애플리케이션에서는 해커가 보낸 특정 payload를 웹서버에 저장한다. 그러면 일반 유저가 브라우저를 통해 웹 애플리케이션에서 XSS payload를 받아 실행한다.
보안이 약한 웹 애플리케이션에 대한 웹 기반 공격
공격의 희생자는 사용자.
payload는 javascript를 활용하여 전달 됨.

Attack가 브라우저랑 서버로 POST하는데 malicious한 걸 넣어논다. 그러면 웹사이트는 그 malicious한 스크립트를 넣는다. 그러면 유저는 웹에서 그 스크립트를 받아 해커가 원하는 걸 실행하고 준다.
최신 브라우저는 자동적으로 막아준다...!
- 아니면, 출력할 때 데이터에 대한 필터 장치를 마련해 둔다...스크립트가 input을 통해 입력될 때 단순 문자열로 변환하려면? (JSON.stringify 같은 걸 사용해주면 되지 않을까?)