R's Hacking Daily Log

Cookie Policy Cookie policy란 Browser 측에서 실행되는 규칙으로 1. Cookie를 서버로부터 받을 때 2. Cookie를 request에 포함해 서버로 보낼 때 아무 Cookie나 저장하고 아무 데나 Cookie를 보낼 수는 없기 때문에 이와 관련하여 Cookie를 저장하고 보내는 과정(store & send)에서 만족돼야 하는 조건 을 정의한다. Cookie Policy가 무엇인지 알아보기 전에 Cookie가 어떻게 생겼는지에 대해 먼저 살펴보자. 기본적으로 Cookie는 "name-value pair" 형태이다. name Theme value Dark Domain toon.sec.org path /cryptography secure True httpOlny false ex..

Same Origin Policy Same Origin Policy란 web security와 관련하여 만들어진 개념적인 정책이라 할 수 있다. web을 이용하는 동안 다양한 리스크가 발생할 수 있지만 SOP는 그중에서도 서로 다른 웹 페이지 간의 상호작용에 대한 규칙을 정의한다. 사용자가 실수로라도 악의적인 page에 접근했다고 한들, 다른 page를 브라우징 하는 데에는 그 어떤 피해(영향)가 있어서는 안 된다는 것을 목적으로 다시 말해, 하나의 web page가 다른 web page에 의해 변경, 조작 등 영향을 주지 못하게 지켜야 할 규칙을 SOP라고 한다. 그렇다면 Origin이라는 것은 어떻게 정의할 수 있을까? origin을 구분하기 위해서는 url의 protocol, domain, port..

사용자가 어쩌다가 공격자가 보낸 위와 같은 사이트(or 메일)를 열었다고 하자. "click" 버튼을 누르게 되면 사용자에게는 "Done"이라는 팝업창만 뜨지만 사실 저 click이라는 버튼에는 공격자가 숨겨둔 js파일이 있다. js 코드에는 사용자의 비밀번호를 hacker로 변경한다는 내용이 적혀있다. 즉 공격자가 지정한 임의 비밀번호로 사용자의 비밀번호가 변경된다는 것이다. 이 요청을 사용자의 브라우저에서 보내기 때문에 서버는 이 요청을 받고 별생각 없이 처리해 주게 된다. username = admin & password = hacker로 로그인을 해보면 성공적으로 로그인 된 것을 볼 수 있다. 이 말은 즉슨 위에서 사용자가 누른 click 버튼에 숨어 있는 js가 실행되어 공격자가 지정한 비밀번호..

CSRF Defenses (server side) CSRF 공격은 공격자가 사이트를 거쳐 "서버에 있는 데이터를 조작하거나 정보를 빼오는 등의 형태"라는 걸 알아보았다. 그렇다면 CSRF 공격을 막기 위해선 어떤 방법이 있을지 살펴보자. (* server side = CSRF Defense는 서버에 의해 실행된다.) :: CSRF Tokens 사용자가 로그인 페이지에 접근할 때마다 서버는 CSRF token을 만들어 응답과 같이 보낸다. CSRF token을 받은 사용자는 자신의 로그인 정보를 입력한 form을 제출할 때 이 토큰을 함께 보내야 한다. 만약 CSRF token이 서버가 만든 값과 일치하지 않으면 사용자의 요청을 처리해주지 않으며 Session token과 달리 CSRF token은 req..

XSS :: cross site scripting XSS에서의 script는 javascript를 얘기한다. client & server가 통신하면서 web page에 대한 정보를 받으면 browser가 분석해서 client 쪽에 페이지를 출력해 준다. web page에 대한 정보가 html 파일로 오면 해당 파일에서 사용된 css나 js 파일도 같이 들어있다. 그렇다 보니 javascript는 client side에서 실행된다고 할 수 있다. Xss 공격이 가능한지 확인해 볼 때 사용하는 대표적인 js는 다음과 같다. 위의 코드는 간단하게 " 1 "이라는 내용의 팝업창을 띄워라 하는 문구이다. 간단하게 확인차 사용하는 코드이다 보니 독립적인 js 파일로 작성하기보다는 script tag로 작성한다. X..

CSRF :: Cross Site Request Forgery web은 client & server 사이에서 request & response를 주고받으며 동작한다. client가 server에게 요청을 보내고 server는 자신이 받은 요청대로 응답을 만들어 client에게 답장을 보내는데 이런 부분을 이용해 사이트를 거쳐 client가 보내는 요청을 위조해서 이뤄지는 공격을 CSRF 라고 한다. CSRF의 전반적인 과정을 살펴보자. 1) 사용자가 로그인을 하면 서버로부터 받은 Session token을 가지고 있을 것이다. 이 token을 보고 서버는 "이미 로그인 된 사용자다"를 알고 이 사용자로부터 오는 요청을 처리해준다. 2) 이런 상황에서 공격자가 어떻게든 사용자를 속여 악의적인 요청을 보내게..

Cookie cookie에 대해 살펴보기 전에 cookie가 왜 필요한지에 대해 먼저 알아보도록 하자. web을 사용하다고 하면 Application layer에서는 HTTP(s) 프로토콜을 사용한다. HTTP의 특징 중 하나는 "Stateless protocol"이라는 것! *Stateless = client가 보낸 요청에 대해 server가 그 어떤 내용도 유지하고 있지 않은 것을 의미한다. server가 어디까지 처리했었는지, 어느 상태까지 진행되었는지 기억하지 않는 걸 말한다. Stateless를 왜 언급했느냐! 를 설명하기 위해 어떤 쇼핑 사이트에 방문해서 로그인을 하고 A & B라는 상품을 각각 장바구니에 담는 상황을 상상해 보자. 1) 사용자는 우선 사이트에 방문할 것이고 2) 로그인을 한 ..

HSTS :: Http Strict Transport Security user의 브라우저가 항상 https를 통해서 web page에 연결되도록 보장함으로써 user를 보호하는 역할을 수행한다. 쉽게 말해, HSTS의 역할은 http connection → https connection으로 redirect 하는 것!! 어떤 Domain에 대해 HSTS를 적용할 수 있다면 Browser는 HTTP 대신 HTTPS를 사용한다. 그렇다면 HSTS 정보는 어디서 볼 수 있을까? HSTS Response Header http or https protocol에서는 server와 client 사이의 request & response가 오고 간다. 여기서 말하는 response의 header에서 HSTS 정보를 볼 수..