[웹보안] 네트워크와 웹보안

1주차 - 네트워크와 웹보안

웹 보안 목적 - 무결성(a가 b사이트에 영향 안미침), 기밀성(a사이트가 b사이트의 정보를 빼앗지 않아야한다.)

HTTP 프로토콜 - 클라이언트, 서버가 이를 통해 소통함

쿠키

서버가 브라우저에 보내는 작은 데이터 조각

브라우저는 이를 저장하고, 같은 서버에 다시 보낸다.

세션관리, 개인화, 추적에 사용된다.

서버가 브라우저에 이렇게 쿠키 설정

브라우저가 서버에는 이렇게 전달

브라우저는 임의로 쿠키 수정해서 보낼 수 있다.

→ 일반적으로 암호화 된 비밀값을 저장하거나, 고유 세션 식별자를 사용한다.

<보통 랜더링 과정>

HTML 불러옴 → 자바스크립트 수행 → 내부 참조 이미지 추가 요청 → 사용자 이벤트에 대응

Frames

웹페이지 안에 다른 출처 콘텐츠 삽입

frame : 페이지 가장자리 위치

iframe : 페이지 중간에 위치

쓰는 이유 : 다른 컨텐츠 삽입 가능, 보안적 격리 제공, 프레임 망가져도 부모페이지 동작

DOM

자바스크립트는 dom을 읽고 수정 가능

웹사이트 콘텐츠를 읽고 쓰기 위한 객체지향 인터페이스이다.

HTML을 구조화 된 DOM으로 만든다.

이런식으로!

Same Origin Policy(SOP)

웹은 같은 출처를 가지고 있는 웹페이지간에만 스크립트를 적용해야한다.

origin이 다른 컨텐츠는 다른 프레임에 분리해서 통신을 제한한다.

프로토콜, 도메인, 포트가 같아야 같은 origin이다.

각 프레임은 각각의 origin을 갖는다.

같은 origin을 가지는 프레임에만 http request, read/write DOM, access local storage에 접근할 수 있다.

patent frame이라도 origin 다르면 안된다.

isolated란? 각 origin은 클라이언트 측에 존재하는 데이터, 자원을 가지고 격리되어 보호된다.

cookeis, dom storage, dom tree, javascript namespace, permission to use local hardware

Script Execution

스크립트(자바스크립트)는 자신의 부모창 또는 프레임의 권한으로 실행된다.

장점 : 성능개선, 단점 : 구글 애널리틱스 스크립트도 당신의 페이지를 조작 가능하다

• 예를 들어, 어떤 웹사이트에 <script> 태그로 외부 JS 파일을 불러오면
• 즉, 같은 도메인처럼 행동할 수 있어서 위험할 수도 있음!

SOP를 프레임에 적용

Domain Relaxation

서브 도메인끼리는 서로 협력하게 만들고싶을 때

public suffix List

사용자가 끝부분에 추가할 수 있는 도메인 끝부분

→ github.io 겹친다고 relacation되면 안됨

→ 이걸 PSL에 등록해서 이거 겹친다고 같은 origin 취급 할 수 없게 함

PostMessage

클라이언트 간의 통신

보낸 쪽

targetWindow.postMesage(message, targetOrigin, [transfer]);

targetWindow : 보낼 window

targetOrigin : 보낼 origin(수신자의)

message: 전달할 데이터

받는 쪽

해당 도메인이 신뢰할만한 곳에서 온건지 확인하는 과정 거침

BroadcastChannel API

이는 같은 origin간의 여러 탭 간의 메세지를 주고받게 해주는 api

XMLHttpRequests

자바스크립트에서 url로부터 데이터를 요청할 수 있는 객체

다른 도메인에 요청할 수는 없다.

같은 오리진에서 온 것만 읽기 가능하다

요청할 때 헤더에 원하는 값 넣을 수 있다.

CORS

다른 도메인이 자신의 리소스에 접근하도록 허락하는 것

Access-Control-Allaow-Origin(ACAO) 헤드를 통해 가능하다위

위와 같이 *로 표시되면 전부 허용하겠다는 뜻이다.

이런식으로 다른 도메인만 허용했을 경우는 실패한다.

SOP : Cookies

쿠키는 서버가 클라이언트에 보낸 작은 조각

쿠키를 맞는 사이트에 보내는 것은 매우 중요하다

쿠키에 대한 sop는 기준이 좀 다르다

페이지는 자신 또는 부모 도메인에 쿠키를 보낼 수 있다.(public suffix 아니어야 가능)

site.com이 기준 사이트이다.

이 때 other.site.com은 subdomain이지만, 보안상으로 막혀있다.

site.com은 parent이라 가능하고, com은 parent이지만, public suffix라서 불가능하다

또한 othersite는 완전히 다른 origin이라 허용되지 않는다.

브라우저는 url scope안에 있는 쿠키를 항상 전송

쿠키 도메인은

site.com이면 login.site.com은 가능

그리고 /my이면 /my/home도 가능하다

site.com은 login.site.com보다 상위라 쿠키 못준다.

https로 가면 안전한 쿠키를 attacker가 http://로 유도해서 탈취할수도 있다.

→ 이를 방지하기 위해서

뒤에 secure을 붙여주면 된다.

이렇게 쿠키와 dom의 sop 기준이 다르다.

그런데 이 때 경로에 따라 쿠키를 줄 수 있냐 마냐가 결정되긴 하지만 경로를 나누는 건 편리성 때문이지 보안때문은 아니다.

<만약 은행앱이 구글애널리틱스 자바스크립트 코드를 가지고있다면?>

이렇게 쿠키에 접근할수도 있다.

HTTPOnly Cookies

돔에서 쿠키에 접근을 못하도록 한다.

이렇게 뒤에 HttpOnly를 붙이면 스크립트에서 쿠키에 접근을 못한다.

만약 attacker 코드에 위와 같은 코드가 있다면

http://bank.com에 접근할 때 쿠키가 자동으로 전송된다.

→ CSRF 위험!

 

출처 : 충남대 네트워크 웹보안 ppt