[6주차] 5주차 복습, CSRF

** XSS

● 루틴

Burp suite

Target → 우클릭, Add to Scope (이 Domain만 본다) → 이 영역의 패킷만 나온다

 

> 특정 형식의 파일 걸러내서 보고싶을 때

→ Filter settings에서 Hide 기능 사용

 

Parameter 체크되어있을때 → 파라미터가 있다 → 모든 파라미터가 있는 요청에는 XSS 취약점의 가능성이 있다

→ 파라미터로 전달한 값이 Response에 응답되지 않으면 테스트 하지말고 넘어가기

 

GET 방식은 띄어쓰기 하면 안 된다 (띄어쓰기 하면 띄어쓰기 이후를 버전으로 인식해서 400대 http 에러 발생)

 

띄어쓰기 대신 %20(URL Encoding) 또는 +으로 처리한다 → 원하는 스크립트가 삽입되었는지 확인 → Copy URL

 

만약 repeater에서는 스크립트가 잘 삽입됐는데 실제로 Copy URL 해서 봤더니 실행이 안되는 경우가 있다. 이 경우에는 취약점이 아니기 때문에 꼭 Copy URL로 확인한다

 

 

* 보고서를 쓸 때

> 위치 URL : ~~

(파라미터까지는 잘 안 씀) 

> 취약 파라미터 : ~~

 

내가 입력한 게 나오는 곳이 있다! (ex. 게시글)

① XSS 체크 <'">

② Burp suite의 페이지 호출하는 곳에 와서 <'">이 어떻게 보여지는치 체크

③ 게시글의 수정 기능을 사용해서 어떤 단어가 필터링 되어있는지 하나씩 확인한다 

④ 스크립트가 다 들어간다면 stored XSS 취약점

 

> Stored XSS의 경우

보고서에 취약점 위치를 2개 명시한다

- Form page url : ~~

 취약 파라미터 : ~

- View page url: ~~

 

SQL error msg → SQLi 가능성이 매우매우 높다

 

 

** XSS 대응방안

● HTML 특수문자를 HTML Entity로 치환한다

 

→ HTML Editor

Step 1. 사용자 입력에서 HTML 특수문자를 전부 HTML Entity로 치환한다

Step 2. 허용해줄 태그를 화이트 리스트 기반으로 복구한다

Step 3. 악성 이벤트 핸들러들을 블랙 리스트 기반으로 필터링한다

 

 

** DOM Based XSS

내가 입력한 정보가 출력되는데 입력한 값이 Response에 없는 경우

→ 역으로 분석해서 찾아야한다

 

만약 <script src='/base.js'> 와 같이 있을 때 history에서 base.js 찾아보고 document.write와 같이 쓰여진 요소를 기점으로 해서 찾아본다

또는 F12 눌러서 요소 검사로 찾아본다 → 내가 모르는 어디선가 동작하는 JavaScript 코드 추적

 

 

** CSRF (Cross Site Request Forgery)

> 요청을 위조한다

> 모든 요청을 대상으로 CSRF 를 잡아낼 수 있다

> 클라이언트가 임의의 요청을 하도록 한다.

> 피해자가 의도치 않게 임의의 요청을 서버로 전송하게 만드는 공격

> 사회 공학 기법

 

XSS는 클라이언트 측 공격이다

CSRF는 서버 측에서 그 처리를 한다

높은 확률로 면접 때 물어봄

 

 

** 임의의 요청 (Request)

GET / POST

① GET

링크를 그대로 전달하는 것이기 때문에 공격하기 쉽다

 

② POST

GET 방식으로 바꿔본다 → 처리되면 취약점

처리 안 될 경우 <form> 태그 만들기

 

ex)

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

요청이 POST 방식으로 나가게 된다 

 

 

CSRF

> 어느정도 주관적이다. 이 요청이 보호되어야 할 요청인지 판단하고 취약점을 잡아야한다

> XSS와 CSRF는 별개의 취약점이다

→ CSRF의 공격을 좀 더 자연스럽고 활용도를 높이기 위해서 XSS 취약점을 연계한다

크사가 csrf에 날개를 달아주는 격

 

> GET 방식으로 보낼 때 XSS가 없어도 CSRF는 있을 수 있다

→ GET 방식으로 보냈는데 CSRF가 있으면 XSS 없어도 쓸 수 있다

> POST 방식으로만 가면 XSS를 찾아야한다

최근 정책 때문에 POST 방식에서도 XSS를 찾는다

 

 

** 대응방안

> CSRF를 막는 근본적인 방안은 요청에 공격자가 예측할 수 없는 정보를 포함시켜 처리하는 것이다

ex) 비밀번호 변경 시 현재 비밀번호도 입력

 

예측할 수 없는 정보

① 인증정보 (비밀번호, OTP)

② CSRF Token (페이지에 방문할 때마다 토큰을 발급해준다)

근데 이것도 우회할 수 있다 → 다음 시간에..

 

PortSwigger Lab에서 문제 풀어볼 수 있다

최대한 solution 보지 말고 풀기. 영영 못 풀어도 된다. 정처기 끝나고 해보기

https://portswigger.net/web-security/all-labs

All labs | Web Security Academy