티스토리 뷰

Client-script language

 - HTML, javascript

Server-script language

 - PHP

SQL


우리가 다뤘던 언어들이다. 이중에서 우리는 먼저 Javascript 를 이용한 취약점에 대해 알아보자.






XSS : Cross Site Scripting

 - 사이트를 교차해서 스크립트를 발생시킴.

 - 게시판을 포함한 웹에서 자바스크립트같은 스크립트 언어를 삽입해 개발자가 의도하지 않은 기능을 작동시키는것.

 - 클라이언트측을 대상으로 한 공격



XSS의 등장 배경에대해 알아보자면 1995년 '넷스케이프' 사에 의해 자바스크립트가 도입된다.

과거에는 넷스케이프의 점유율이 80퍼센트 이상이었을때가 있었고, 그렇기 때문에 그당시 주류였던 넷스케이프에서 

최초로 자바스크립트를 도입하게 되므로 다른 웹서비스들도 자바스크립트를 채택하게되었다.

2000년에 이르러 '마이스페이스'에서 XSS 공격이 최초로 발견되었다. '마이스페이스'는 미국판 싸이월드.. 정도

2005년에는 악성코드 형태로 발견되었고, 현재까지 다양한 변종들이 등장하게 된다. 

일례로 '리그 오브 레전드(LOL)' 에서도 자바스크립트를 이용한 공격이 등장하였다.

웹에서 빠질수 없는 언어이기때문에, 없어지지않는 취약점 중에 하나라고 볼 수 있다.






owasp

 - 보안 취약점을 연구하는 집단. 비영리 단체이기 때문에 신뢰성이 높다고 평가된다.


# OWASP Top 10항목 

04년도 : A4 - XSS 

07년도 : A1 - XSS

10년도 : A2 - XSS

13년도 : A3 - XSS

17년도 : A7 - XSS



즉, XSS가 발견된 이후로 보안 위험성 차트에 매번 언급되고 있다.

다시말해 20년가까이 이 공격을 막지못하고있다는 얘기다.

공격은 단순하지만 강력하다. 공격이 단순하면 막기가 어렵다.






예제를 진행해보자.



# XSS 예제

글 작성자가 HTML 코드를 삽입하여 글을 읽는사람의 브라우저에서 실행되게하는 원리이다.


  




# 위와같이 글쓴이(해커)가 쓴 html코드 alert가 클라이언트에서 작동한다.

XSS 원리를 생각해보면 당연하게 가능한 이야기이다.

자바스크립트는 클라이언트측 언어(Client-side Language) 이기때문이다.

스크립트가 실행될 수 있다는것 자체만으로도 취약점이 된다.


발신인이 누구인지 모르는 메일을 열어보지 말라는 말도 위와같이 XSS를 이용해 공격을 할 가능성이 있기 때문이다.

테스트이기 때문에 alert문을 실행시켰을 뿐, HTML코드로 악성코드를 삽입한다거나 하는 방법으로 

클라이언트측에 치명적인 공격을 가할 수 있다.


#)_참고

모의해킹 : 점검하려는 대상의 모든 취약점을 찾는것.

실행이 안되더라도 실행될 수 있는 시나리오를 점검한다.


시스템해킹이나 네트워크해킹을 알고난 후 XSS에 대해 더 심도있게 공격이 가능하다.

즉, 클릭만 하면 내가 심어놓은 악의적 스크립트를 열어보게끔 할 수 있다.


여기서 문제는 '어떻게하면 몰래 실행할수있느냐' 와 '코드가 실행됐을떄 어떤 공격을 펼칠수있는가' 이다.

입력가능한부분에 위와같은 스크립트를 다 심어봐서 XSS공격이 가능한지 확인한다.






XSS 공격 방법

1). stored XSS 

 - 스크립트를 저장해뒀다가 공격하는 방법

2). reflected XSS

 - 스크립트를 입력하면 바로 반사되어 바로 실행이 되는 방법



URL을 통해서도 XSS공격이 가능하다.


# 근데 URL을 보면 눈에 드러나게 HTML코드가 삽입되어있음을 알 수 있다.

이런것은 짧은 URL을 이용하여 속일 수 있다.


# 위와같이 짧은 URL을 이용해서 URL의 HTML코드를 숨길 수 있다.






ZERO BOARD 취약점

 - 쪽지, 홈페이지, 댓글, 회원정보, 글제목 


화면에 보이는 입력들을 찾아 모두 테스트를 해볼 것인데, 꼭 화면에 입력 폼이 존재하는것만 공격이 가능한것이 아니다.

실제로는 모든 입력가능한 곳들을 다 찾아내서 테스트를 해야한다.

그러려면 가장먼저 선행되어야 할 부분이 타겟 사이트의 분석이다.


공격자의 입장에서 웹페이지를 분석하는 유일한 수단은 소스코드 보기로 가능하다.

그래서 웹해킹의 기본은 소스보기부터 출발한다.


# 위와같이 소스코드보기로 입력 가능한 모든 여지를 찾아야 한다.

특히 POST같은경우 모든 히든에 다 접근해 봐야 한다.



# 이런곳에서도 공격이 가능하다는거 세부적으로 다 확인해야한다.






고전적인 보안기법

 - 방화벽, IDS, IPS, UTM 같은 장비를 이용(보안 솔루션)

 - 백신

 - 보안패치

 - 서드파티 보안

서드파티 보안이란 제3자가 보안솔루션을 제공하는 것을 지칭한다.

예를들면 제로보드 내의 XSS취약점을 크롬이 차단하는 경우 제 3자의 보안설정에 의해 공격에 노출되지 않는것.


# 이렇게 크롬 자체에서 차단을 해주기도 한다.






그러나 이러한 모든 보안기법을 총 동원해도 XSS공격을 완벽하게 차단할 수 없다.


그래서 이런점을 보완하기위해 등장한 것이 시큐어 코딩이다.



시큐어 코딩

기본적으로 프로젝트의 전 과정을 짧게 요약해보면

기획 → 설계 → 구현 → 배포 → 유지보수 의 흐름을 따른다.

기존의 방법론은 일단 구현및 배포까지 끝마치고 유지보수때 말그대로 추후에 발생하는 버그 등에 대응하는 방법인데

이런 경우 대다수가 비용은 비용대로 올라가고 제대로 수정하기가 어렵다.

그래서 애초에 설계때부터 추후에 등장할 지 모를 버그 등 위험성을 모두 고려하여 설계하는것이 시큐어코딩이다.

실제로 이렇게 설계했더니 IBM의 경우 90%가까이 비용을 절감하였다고 한다.


따라서 예제를 통해 간단하게 시큐어코딩의 예를 알아보자.

예시로 두가지 정도를 들어볼 수 있는데 

첫번째 아예 스크립트가 입력이 안되게 하는 방법

두번쨰 스크립트가 입력이 되어도 실행이 안되게하는 방법이 있다.


첫번째 방법인 입력값을 검증하여서 스크립트 입력을 차단하는 방법에 대해 알아보자.

글을 작성하고 작성된 글을 DB에 넘길때의 페이지인 write_ok.php 파일로 접근하여


# 이렇게 if문 안에 입력값을 검증한다 즉, 입력값에서 html코드를 검사한다.

이런거를 시큐어코딩 이라고 한다~






# 이렇게 XSS에 대한 공격을 차단할 수 있다.


그러나 이와같은 방법은 절대 완벽하지않다.

<Script>..... 와 같은방식으로만 적어도(첫글자 대문자) 바로 우회가 가능하다.

따라서 시큐어코딩이라 하더라도 모든 경우의 수를 완벽하게 방어하는것은 불가능하다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함