HTML&Cookie
HTML CSS JS Webbrowser
HTML은 웹 브라우저를 통해서 사용자에게 보이는 웹 문서를 작성하는 언어로 쉽게 말해, 웹 문서의 뼈대를 구축하는 개념이다.
반면, CSS는 기존 HTML파일에 다양한 모양을 추가하거나, 변경하는 등 디자인 표현에 집중하는 언어로 CSS는 디자인을 입히는 개념이다.
Java Script는 웹문서를 HTML을 이용해서, 정보를 보거나 웹 문서끼리 연결하는 것 이외에 동적 요소 제어를 위해 사용되는 언어로 웹 문서에서 제공하는 동적제어에 집중을 하는 언어이다. HTML로 뼈대를 만드고 CSS로 디자인을 입힌 웹 문서에 움직임을 넣는 개념의 언어이다.
위 사진은 웹 브라우저 구성요소이다.
1. 사용자 인터페이스(UI) : 인터페이스(interface)의 뜻은 “중앙 처리 장치와 그 주변 장치를 서로 잇는 부분” or “사람과 컴퓨터를 연결하는 장치”이다. 여기에서 인터페이스(interface)는 ‘다른 두 개의 어떤 것을 연결’한다는 느낌이 강하다. 상호 작용 하기 위해 연결하는 느낌이다.
주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분(화면에 보이는 모든 것들(클릭할 수 있는 것, 입력할 수 있는 것, 레이아웃 등등)이 사용자와 시스템 사이에서 의사소통하려는 매개체(UI)이다.
2. 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작 제어(역할)
3. 렌더링 엔진 : 요청한 콘텐츠를 표시함 (e.g. HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시함)
4. 통신 : HTTP 요청과 같은 네트워크 호출에 사용됨. 이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨
5. UI 백엔드 : 콤보 박스, 창과 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용함
6. 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행함
7. 자료 저장소 : 자료를 저장하는 계층임. 쿠키를 저장하듯이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있음. HTML5 명세에는 브라우저가 지원하는 '웹 데이터베이스'가 정의되어 있음
JS Obfuscation(자바스크립트 난독화)
자바스크립트는 Client에서 실행되도록 하는 언어입니다. 따라서 사용자(Client)가 웹사이트에 접근하게 되면 해당 스크립트를 그대로 볼 수 있게 됩니다. 이를 방지하고자 적용하는 기법이 바로 난독화입니다.
그렇다면 왜? 난독화를 하는가?
코드가 쉽게 분석되지 않도록 숨기거나 분석 시간을 늦추기위해 사용한다.
이를 공격자가 이용하면 악성코드의 실질적인 배포기간을 늘릴 수 있다.
- 클라이언트 측에 저장되는 작은 데이터 파일이다.
- 웹 서버가 브라우저에게 지시하여 사용자의 로컬 컴퓨터에 파일 또는 메모리에 저장하는 작은 기록정보 파일이다.
- 파일에 담긴 정보는 인터넷 사용자가 같은 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 있다.
쿠키(Cookie)의 구성요소
Path
- 쿠키를 반환할 경로를 결정 ex) path=/
- 도메인의 루트 경로로 이동할 경우 쿠키가 전송된다.
예를 들어 웹 어플리케이션의 경로가 구성된 경우 쿠키의 path 값을 /subDir1/ 으로 지정하면 localhost:8080/subDir1/xx.jsp 와 같이 subDir1 하위 경로로 요청시에만 쿠키가 전송됩니다.
Expires
- 쿠키가 언제 삭제되는지 결정한다. ex) expires=”wdy, DD-Mon-YYYY HH:MM:SS GMT”
- 쿠키에 만료일이 포함되어 있으면 영구적 쿠키로 간주한다.
- Max-Age를 통해 지정된 만료일이 되면 디스크에서 쿠키가 제거된다.
Domain
- domain 속성은 현재 쿠키가 어떤 서버로 전송되어져야 하는지를 지정할 수 있는 속성이다. 입니다.
- 쿠키는 하나의 도메인 범위 안의 여러 서버들간에 쿠키를 공유할 수 있도록 domain 속성을 제공하고 있습니다.
- 쿠키가 사용되는 도메인을 지정한다. ex) domain=nesoy.github.io
- 이 값이 현재 탐색중인 도메인과 일치하지 않을 경우, “타사 쿠키”로 간주되며 브라우저에서 거부된다.
- 이렇게 하여 한 도메인에서 다른 도메인에 대한 쿠키를 사용하지 못하게 설정한다.
HttpOnly
- document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막는 옵션이다.
- 브라우저에서 http only가 설정된 쿠키를 조회할 수 없다.
- 서버로 http request요청을 보낼때만 쿠키를 전송한다.
- 이를 통해 XSS(Cross Site Scripting)공격을 차단할 수 있다.
**XSS란?
웹 사이트의 어드민이 아닌 악의적인 목적을 가진 제 3자가 악성 스크립트를 삽입하여 의도하지 않은 명령을 실행시키거나 세션 등을 탈취할 수 있는 취약점입니다.
First-Party Cookie와 Third-Party Cookie
- 퍼스트 파티 쿠키는 사용자가 접속한 페이지와 같은 도메인으로 전송되는 쿠키를 말한다.
- 서드 파티 쿠키는 사용자가 접속한 페이지와 다른 도메인으로 전송하는 쿠키를 말한다.
쿠키와 CSRF문제
쿠키에 별도로 설정을 가하지 않는다면, 크롬을 제외한 브라우저들은 모든 http요청에 대해서 쿠키를 전송하게 된다. html 문서 요청, html문서에 포함된 이미지 요청, XHR혹은 Form을 이용한 http 요청등 모든 요청이 포함된다.
- CSRF(Cross Site Request Forgery)[사이트간 요청 위조]는 위의 문제를 노린 공격이다.
- 공격대상 사이트는 쿠키로 사용자 인증을 수행
- 피해자는 공격 대상 사이트에 이미 로그인 되어있어서 브라우저에 쿠키가 있는 상태
- 공격자는 피해자에게 그럴듯한 사이트 링크를 전송하고 누르게 함.
- 링크를 누르면 html문서가 열리는데, 이 문서는 공격 대상 사이트에 http요청을 보냄
- 이 요청에는 쿠키가 포함되어 있으므로 공격자가 유도한 동작을 실행할 수 있음
*XHR(XMR Http Request)은 AJAX 요청을 생성하는 Java script API이다.
*XML은 "Extensible Markup Language"의 약어로, 데이터를 구조화하고 전송하기 위한 마크업 언어입니다. HTML과 마찬가지로 태그와 속성으로 구성된 문서입니다. 그러나 HTML과 달리, XML은 데이터의 구조와 의미를 설명하기 위해 직접 정의한 태그를 사용할 수 있습니다.
Samesite Cookie
서드 파티 쿠키의 보안적 문제를 해결하기 위해 만들어진 기술이다. 크로스 사이트(Cross-site)로 전송하는 요청의 경우 쿠키의 전송에 제한을 두도록 합니다.
- Samesite Cookie의 정책으로 None, Lax, Strict 세 가지 종류를 선택할 수 있고, 각각 동작하는 방식이 다르다.
- None : None으로 설정된 쿠키의 경우 크로스 사이트 요청의 경우에도 항상 전송된다. 즉, 서드 파티 쿠키도 전송된다. 따라서, 보안적으로도 SameSite적용을 하지 않은 쿠키와 마찬가지로 문제가 있는 방식이다.
- Strict : Strict로 설정된 쿠키는 크로스 사이트 요청에는 항상 전송되지 않는다. 즉, 서드 파티 쿠키는 전송되지 않고, 퍼스트 쿠키만 전송된다.
- Lax : Lax로 설정된 경우, 대체로 서드 파티 쿠키는 전송되지 않지만, 몇 가지 예외적인 요청에는 전송됨
Chrome에서 SameSite=Lax로 쿠키 정책이 바뀐 이유
회원가입을 받거나, *OAuth를 사용해서 사용자에게 권한을 부여하는 웹사이트가 많다.
각 사용자는 서로 다른 권한을 가지고 있으며, 이 권한의 종류는 아주 다양하다.
*OAuth : 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
ex) Google로 로그인하면 *API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있다.
*API(Application Programming Interface) : 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘이다.
HTTP Session Hijacking
웹 브라우징시 세션 관리를 위해 사용되는 Session ID를 스니핑이나 무작위 추측 공격(brute-force-guessing)을 통해서 도용하는 기법
HTTP 특징
HTTP는 기본적으로 비연결유지 프로토콜이다. 따라서 웹 사이트 로그인 후 다른 페이지 방문시마다 매번 로그인해야 하는 불편함이 있는데 이는 Session ID를 사용해서 해소가능
Session ID
- 웹 서버가 다수의 웹 페이지 요청자를 구별하기 위하여 각각의 사용자의 세션에 대해서 부여한 임의의 긴 문자열을 말함
- 사용자가 홈페이지 방문시 혹은 로그인시에 생성
- 사용자의 계정, 암호, 그 밖의 IP주소, times tamp등의 여러 파라미터들을 조합하여 생성 가능
- 사용자의 일련의 웹 서핑 동작을 연결시켜줌으로써 웹 사이트 로그인 후 다른 페이지 방문시마다 매번 로그인 하지 않아도 되는 편리함을 제공
Session ID는 어디에 존재하는가?
- Session ID는 우리가 흔히 듣는 쿠키라는 곳에 저장되는 것이 일반적이다. 그러나 가끔은 웹 브라우저 주소창 URL이나 HTML페이지 폼 소스상의 hidden 필드에 포함돼 드러나기도 함
Cookie와 Session의 차이
- 세션은 쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리함
- 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하여 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지
다음에는 Http request/response에서 부터 설명하겠습니다.