mysql > SELECT id FROM test WHERE id='admin' limit 0,1 procedure analyse(extractvalue(1, concat(0x3a, (if(mid(version(),1,1) like 5, sleep(5),1))), 1);
CORS(Cross Origin Resource Sharing)는 브라우저가 XHR(XMLHttpRequest)을 이용해 Cross-Origin 요청이 가능하여, 서로 다른 도메인(사이트) 간 자원을 공유할 수 있게 해주며, 특정 조건들이 만족할 경우동일 출처 정책(SOP : Same Origin Policy)에 의한 제한을 완화하는 데 사용될 수 있습니다.
동일 출처 정책(SOP : Same Origin Policy)은 보안 상의 이유로, 브라우저들의 스크립트 내에서 초기화되는cross-origin HTTP요청을 제한하는 것으로 다른 웹페이지에서 접근할 때는 동일한 출처, 즉 프로토콜, 호스트명, 포트가 같은 웹페이지에만 접근이 가능합니다. 예를 들면, XMLHttpRequest는 동일 출처 정책을 따르기에, XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능합니다. 즉, 웹페이지의 스크립트는 그 페이지와 같은 서버에 있는 주소만 ajax 요청을 할 수 있습니다.
먼저Scheme은 http://나 https://나 ftp://와 같은 URI의 맨 앞에 붙는 문자열을 의미합니다.
이는 클라이언트에서 이를 처리하는 방식을 지정해줍니다. http가 붙으면 해당 프로토콜로 작동하는 것처럼요.
다음으로Host는 "www.tistory.com"이나 "www.google.com"과 같은 도메인을 의미합니다.
이 뒤에 붙는 /index.html과 같은 PATH는 Host에 포함되지 않습니다.
마지막으로Port는 말 그대로 포트입니다. 도메인은 IP와 대응되고, 이 뒤에 포트를 지정해 줄 수 있죠.
"www.tistory.com:8081"과 같이 도메인 뒤에 붙여 접속할 포트번호를 지정할 수 있습니다.
아래는 이와 관련된 예제입니다. 이를 보시면 쉽게 이해하실 수 있습니다.
기본 출처 : http://kookhh.ml (80포트)
1번 : http://kookhh.ml/some_dir/index.php -> O
2번 : https://kookhh.ml -> X (Scheme이 다름)
3번 : http://google.com -> X (Host가 다름)
4번 : http://kookhh.ml:4301 -> X (Port가 다름)
kookhh.ml에서 www.naver.com로 요청해도 응답 안줌!
CORS(Cross Orgin Resource Sharing) policy 때문에 XMLHttpRequest가 차단되었다는 메세지입니다.
API같은걸 만드는 개발자 입장에서는 이를 해결하기 위해서는 위의 에러 메세지에 적힌 것과 같이 Access-Control-Allow-Origin 헤더를 보내서, 접근을 허용하는 Origin을 정해주면 됩니다.
또는 JSONP를 이용하거나, 서브도메인 간의 접근을 위해서는 document.domain을 이용하는 방법도 있습니다.
그냥 요청만 보내는 것은 SOP에서 막지 않기 때문이에요, 게시글 수정, 삭제, 비밀번호 변경 등의 요청은 이 정책에 구애받지 않고 할수 있어요.
하지만 CSRF 토큰을 이용해서 막아뒀다거나, 다른사이트의 쿠키값같은걸 들고오고 싶다면(DOM에 접근하고 싶다면) 당연히 SOP를 우회해서 공격해야 합니다.
여기서 보통 일반적으로 생각할 수 있는 방법이 DNS Rebinding 공격입니다.
DNS Rebinding Attack 악의적인 사이트의 도메인에 할당된 IP를 잠재적인 희생자가 사이트에 들어와있는 동안 공격하고자 하는 사이트의 IP로 바꾸어 Same Origin Policy를 우회하는 방법
이 공격을 하기 위해서는 악의적인 DNS 서버를 하나 파서,
낮은 주기의 TTL로 A라는 도메인에 할당된 아이피가 a라는 IP와 b라는 IP 사이를 왔다갔다 해야합니다.
간단한 공격 순서도
위 사진이 공격 순서입니다.
먼저 희생자(Victim)이Domain A로 연결합니다. 브라우저는 이 Domain A의 IP를 얻기 위해 DNS 서버에 요청을 보냅니다.
그러면 악의적인 DNS 서버에서 이에 대한 IP가 111.111.111.111이라고 알려줍니다.
이 IP는 우리가 만든 악의적인 스크립트가 심어진 악의적인 페이지입니다.
여기서 잠시 뒤에 스크립트가 실행됩니다. 이 스크립트는Domain A로 요청을 보내고, 응답을 읽어들입니다.
하지만 Domain A에 대한 ttl이 낮아서, 다시한번 브라우저는 IP를 얻기 위해 DNS 서버에 요청을 보냅니다.
이번에는 악의적인 DNS 서버에서 이 도메인의 IP가 222.222.222.222라고 알려줍니다.
이제 브라우저가 스크립트를 실행시키는데,Domain A의 IP가 222.222.222.222로 바뀌었기 때문에 실제로 요청은 희생양이 될 사이트로 보내지게 됩니다.
브라우저 입장에서는 Domain은 A로 똑같기 때문에, Same Origin Policy에 위배되지 않는다고 생각하고 응답을 읽어들일 수 있도록 허용해줍니다. scheme이나 port는 당연히 똑같이 맞춰줘야겠죠.
이렇게 해서 희생자가 사이트에 들어가는 순간의 Domain A에 할당된 IP가 111.111.111.111,
악성 스크립트가 동작하는 순간의 Domain A의 IP가 222.222.222.222로 브라우저에게 인식된다면 공격 성공입니다.
DNS Rebinding Attack을 위한 DNS Server 소개 whonow, rbndr
이제 이걸 배웠으니 실습을 해보고 싶은데 dns 서버를 직접 파는것은 굉장히 귀찮은 일입니다.
그래서 이미 똑똑한 사람들이 이 공격을 쉽게 할 수 있도록 dns 서버를 만들어 놨습니다.
사용법도 굉장히 간단합니다.
먼저whonow입니다.
# respond to DNS queries for this domain with 34.192.228.43 the first time
# it is requested and then 192.168.1.1 every time after that
A.34.192.228.43.1time.192.168.1.1.forever.rebind.network
# respond first with 34.192.228.43, then 192.168.1.1 the next five times,
# and then start all over again (1, then 5, forever...)
A.34.192.228.43.1time.192.168.1.1.5times.repeat.rebind.network
