웹해킹 5주차 - XSS

XSS(Cross Site Scripting)

 - 특정한 스크립트를 삽입하는 공격

 - 웹에는 CSS, JS로 구성되어 있는데 JS를 공격하는 것

 - 쿠키나 세션에 저장된 세션 아이디를 탈취하는 방법도 있음

                 =>한 쿠키에 모든 http 요청을 보내기 때문

 

가장 기본적인 공격법

 - 게시글에다가 스크립트 코드를 작성하여 게시글을 들어가면 코드가 발동하도록 하는 것

                               다채로운 공격이 가능함 -> <a>나 <img>태그로 감싸서 우회로 공격 가능(링크,이미지 등)

 

 

아스키 코드를 이용한 공격법

 - 코드를 아스키코드로 변환 후 공격

 

다른 공격법

 - IFRAME 태그 내에 직접 코드를 작성하여 보이지 않아도 코드가 실행되게끔 코드를 작성함

 

Same Origin Policy

 - 웹 브라우저를 통한 호스트에 요청 시 사용자 정보가 담긴 쿠키도 전송되므로 외부 리소스를 불러                              오는 엘리먼트들을 자바스크립트를 이용하여 읽거나 변조 가능함

 - 이를 방지하기 위해 만든 정책 (서로 다른 오리진의 엘리먼트와 스크립트의 상호 작용을 제한함)

 - 오리진은 프로토콜, 포트, 호스트로 구성되어 있고 이들 중 하나라도 다르면 다른 오리진

 

SOP가 있을 때에도 리소스 공유하는 방법

 - postMessage => 메시지를 주고 받기 위한 이벤트 핸들러

 - JSONP - 스크립트 태그를 이용하여 외부 자바스크립트 코드를 호출

 - Cross Origin Resource Sharing 헤더 => HTTP 헤더로 다른 오리진이 허용하는 설정 등을 허용하는 요청을 보냄

                                                  => HTTP, HTTPS와 같이 서로 다른 스킴을 사용하면 허용하지 않을 수 있음

 

Reflected XSS 

 - 악성 스크립트를 사용자의 요청과 함께 전송하는 방법

 - Stored XSS와는 다르게 사용자의 요청이 있는 경우 전송되도록 형태를 짜야함 (링크 등으로)

 

XSS 방어 방법

 - Server-side Mitigation => HTML에서 사용하는 <>나 , 같은 특수문자를 태그로 인식하지 않도록 수정

                                   > HTML을 써야할 경우 화이트리스트 필터링을 거침

                                   > 사용자의 IP주소를 저장하여 현재 IP 주소와 계속해서 비교하는 방법도 있음(현재는 사용                                        하지 않음)

 

 - HTTPOnly Flag => 서버측에서 응답 헤더에다가 Set-Cookie 헤더를 넣어서 쿠키 접근을 못하게 만듬

 

 - Content Security Policy => 응답 헤더나 meta 태그에서 Content-Security-Policy로 선언하여 사용 가능

                                    > CDN 서버가 해킹당할 경우 무력화될 수 있음

                                    > 서버에서 생성한 nonce 값을 알아야하므로 XSS공격이 어려워짐

 

- X-XSS-Protection-Header => 응답 헤더에 X-XSS-Protection: <값> 으로 선언하여 사용 가능

                                      > 웹 브라우저 내의 XXS Filter를 활성화 할것인지를 판단 후 차단할지 안할지 결정

                                      > Request 값과 Response를 비교하는 방법을 사용 -> Reflected XSS 공격을 막는데 용이

 

 

CSRF

 - 사용자의 의도와 관계없이 다른 사이트에 HTTP 요청을 보내는 공격

 - 이를 통해 해당 세션 쿠키를 가진 사람만 사용 가능한 기능을 요청 가능

 - 보호법

       => 세션 쿠키를 사용하지 않고 커스텀 헤더를 사용하여 사용자를 인증함

       => 비밀번호 재기입, 자동가입문자 등 공격자가 모르는 파라미터를 추가함

 

Open Redirect

 - 사용자의 위치를 강제 이동 시키는 기능 중 하나

 - HTTP Response의 300번대 영역 혹은 자바스크립트를 통해 이동될 경우 공격

 - 리다이렉트가 발생될 경우 경로에 공격자의 값을 함께 넣어 다른 url로 이동되도록 유도함

 - 보호법

      => 이동을 허용한 주소만 따로 저장하여 그곳만 이동 가능하도록 설정

      => 외부로 이동 시 사용자에게 경고메시지를 띄우는 방법도 있음

 

Click Jacking

 - 화면 출력에 영향을 미치는 HTML, JS 등을 이용하여 클릭을 유도하는 방법

 - 사진에다가 투명도를 이용하여 다른 링크를 집어넣는다거나 하는 방법

 - 이는 iframe 태그가 웹 브라우저 상에서는 더 앞에 있기 때문에 사용자가 보는 페이지와 실제가 차이가 있기 때문

 - 보호법

      => X-Frame-Option : 응답 헤더로 URL 이동을 차단하는 것

      => frame-ancestors : CSP 지시어로 값 설정, 모든 parent의 URL을 검사함(위보다 많이 쓰임)

 

fh: <지시어>; ...'''fsd-XS

과제1 - xssgame 1번

오오오 게임같당 대충 해석하자면(사실 해석 안하고 구글 번역기 썼어요) alert 터트리기만 하면 된다는 것! search 안에 간단히 <script>alert();</script> 만 넣으면 될 거 같다

헤헤

 

과제2 - xssgame 2번

다음 문제. 이번에는 페이스북과 같은 형식의 실시간 채팅? 같은거에다가 alert를 띄우는 거 같다.

일단 안될걸 알면서도 막무가내로 alert를 집어넣어본다

역시 안된다.

 

다음은 이미지 어....이렇게 하는게 맞나?

될리가. 이미지 태그의 사용법을 까먹어서 내 블로그도 찾아보고 구글링도 해보았다

 

onerror 속성을 이용하면 된단다. 도전!

 

오오오오 됐다

 

하지만 클리어가 되지 않는다 아마 confirm을 써서 그런거 같다. 머리 없이 구글링 한거 따라만 하면 이렇게 된다

 

confirm을 alert로 바꿔보았다

 

1 확인이 몇번 뜨고 나서(이전에 내가 쳤던 confirm때문인거 같다 문제에 나오는 힌트가 이런 의미였구나) 완료문구가 떴다

 크 역시 난(구글) 잘해

 

과제3 - webhacking-kr old.23

난 이 화면이 제일 좋아

안될 걸 알면서도 넣어보는 alert

 

no hack 핵쓰지마라

네

음.....일단 코드를 보자

 

오....이건 아닌거 같다

 

아 이때야말로 영상에서 배운 아스키 코드로 변환하여 XSS 공격을 하는 것을 써보는거야!

구글링으로 찾은 아스키코드 변환사이트

헤헤 깼다

 

어...아 url로 입력해야 하구나 저기 +되있는걸 보니까 ㅋㅋㅋ 아 난 또 뭐라고 ㅋㅋㅋ 어.....

 

어림도 없지!

근데 잘 보니 url에 내가 친 적이 없는 %20? 이 엄청나게 많다 

아마 url에서 특수문자를 별도로 처리하는 코드인것 같다

그럼 저걸 이용해서 alert를 직접 입력 할 수 있지 않을까?

 

휴....진짜 재밌는 노가다였어

 

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ아마 %20은 띄어쓰기를 처리하는 특수문자였나보다

그럼....영어를 2개 이상 쓰면 안되는거 같으니 영어를 모두 특수문자 처리하면 되지 않을까?

 

구글에서 찾은 url 인/디코더 이것을 이용해서 영어를 특수문자로 바꿔보자

 

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ아나 어쩔 수 없지

 

 

노가다 ON

 

이게 바로 <script>alert(1);</script> 입니다... 두근두근

 

ㅋㅋㅋㅋ안해

다시 한번 찾아보니 url에는 널 문자를 처리하는 특수 코드가 있다고 한다

이름하야 '%00' 

후...

 

 

직접 노가다를 뛴 모습

 

 

 

오오오옹오오오ㅗㅇ

 

완료!!!!