Knowledge/웹보안 / / 2016. 7. 26. 17:16

웹보안(xss,크로스 사이트 스크립팅,Cross Site Scripting,owasp top 10)

반응형



웹보안



owasp top 10



A1. 인젝션
SQL, 운영체제, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 질의문의 일부분으로서 인터프리터로 보내질 때 발생한다. 공격자의 악의적인 데이터는 예상하지 못하는 명령을 실행하거나 적절한 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.

A2. 인증 및 세션 관리 취약점
인증과 세션 관리 관련된 애플리케이션 기능은 정확하게 구현되어 있지 않아서, 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점은 공격하여 다른 사용자 ID로 가장할 수 있다.

A3. 크로스 사이트 스크립팅 (xss)
xss 취약점은 애플리케이션이 신뢰할 수 없는 데이터를 가져와 적절한 검증이나 제한 없이 웹 브라우저로 보낼 때 발생한다. xss는 공격자가 피해자의 브라우저에 스크립트를 실행하여 사용자 세션 탈취, 웹 사이트 변조, 악의적인 사이트로 이동할 수 있다.

A4. 취약한 직접 객체 참조
직접 객체 참조는 개발자가 파일, 디렉토리, 데이터베이스 키와 같은 내부 구현 객체를 참조하는 것을 노출시킬 때 발생한다. 접근 통제를 통한 확인이나 다른 보호수단이 없다면 공격자는 노출된 참조를 조작하여 허가 받지 않은 데이터에 접근 할 수 있다.

A5. 보안 설정 오류
훌륭한 보안은 애플리케이션, 프레임웤, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 보안 설정이 정의되고 적용되어 있다. 기본으로 제공되는 값은 종종 안전하지 않기 때문에 보안 설정은 정의, 구현 및 유지되어야 한다. 또한 소프트웨어는 최신의 상태로 유지해야 한다.

A6. 민감 데이터 노출
많은 웹 애플리케이션들이 신용카드, 개인 식별 정보 및 인증 정보와 같은 중요한 데이터를 제대로 보호하지 않는다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하는 등 약하게 보호된 데이터를 훔치거나 변경할 수 있다. 중요 데이터가 저장 또는 전송 중이거나 브라우저와 교환하는 경우 특별히 주의하여야 하며, 암호화와 같은 보호조치를 취해야 한다.

A7. 기능 수준의 접근통제 누락
대부분의 웹 애플리케이션은 url에 해당 기능을 보이게 하기 전에 기능 수준의 접근권한을 확인한다. 그러나, 애플리케이션은 각 기능에 접근하는 서버에 동일한 접근통제 검사를 수행한다. 요청에 대해 적절히 확인하지 않을 경우 공격자는 적절한 권한 없이 기능에 접근하기 위한 요청을 위조할 수 있다.

A8. 크로스 사이트 요청 변조 (CSRF)
CSRF 공격은 로그온 된 피해자의 취약한 웹 애플리케이션에 피해자의 세션 쿠키와 기타 다른 인증정보를 자동으로 포함하여 위조된 HTTP 요청을 강제로 보내도록 하는 것이다. 이것은 공격자가 취약한 애플리케이션이 피해자로부터의 정당한 요청이라고 오해할 수 있는 요청들을 강제로 만들 수 있다.

A9. 알려진 취약점이 있는 컴포넌트 사용
컴포넌트, 라이브러리, 프레임워크 및 다른 소프트웨어 모듈은 대부분 항상 전체 권한으로 실행된다. 이러한 취약한 컴포넌트를 악용하여 공격하는 경우 심각한 데이터 손실이 발생하거나 서버가 장악된다. 알려진 취약점이 있는 컴포넌트를 사용하는 애플리케이션은 애플리케이션 방어 체계를 손상하거나, 공격 가능한 범위를 활성화하는 등의 영향을 미친다.

A10. 검증되지 않은 리다이렉트 및 포워드
웹 애플리케이션은 종종 사용자들을 다른 페이지로 리다이렉트 하거나 포워드하고, 대상 페이지를 결정하기 위해 신뢰할 수 없는 데이터를 사용한다. 적절한 검증 절차가 없으면 공격자는 피해자를 피싱 또는 악성코드 사이트로 리다이렉트 하거나 승인되지 않은 페이지에 접근하도록 전달할 수 있다. 





xss(Cross Site Scripting)





vReflective XSS ( non-persistent )
u공격자는 악성 스크립트를 포함한 URLVictim에게 노출
l이메일, 메신저, 웹 게시판 등을 이용
u악성스크립트는 서버에 저장되지 않는다.




vStored XSS ( persistent )
u공격자는 악성 스크립트를 XSS에 취약한 웹 서버에 저장
l웹 게시판, 방명록 등

u공격자는 해당 게시물을 Victim에게 노출시킴




XSS에 취약한 페이지 유형


uHTML을 지원하는 게시판
uSearch Page
uPersonalize Page
uJoin Form Page
uReferer 를 이용하는 Page

u그 외 사용자로부터 입력 받아 화면에 출력하는 모든 페이지에서 발생 가능


        
  

 Test          

게시판에 스크립트 언어 작성해보기.

<script>

alert("XSS!!");

</script>




이렇게 게시판에 작성한 스크립트 언어가 뜨면 xss에 취약하다고 할수있습니다.



<script>

alert(document.cookie);

</script>



쿠키값 출력 함수 document.cookie 를써서 쿠키값을 알아낼수도 있습니다.




백트렉에서 /var/www/xss.php 라는 파일에 
<?
echo "id= ",$_GET["id"];
?>

(아이디 값 가지고와서 출력해줘라)
작성하면 됩니다.



백트렉이서 작성한 xss.php를 xp로와서 이렇게 작성하시면 아이디가 출력됩니다.


빨간색으로 밑줄친 곳에 아이디가 나오는것을 확인할수 있습니다.

attack


공격자 서버에서 서버열고 난후 (백트렉 아파츠서버) 작성을 합니다.



xp 게시판에 들어가서 스크립트 언어 이렇게 작성을 합니다.



피해자가 (xss)게시판을 누르게되면 로그인한 쿠키값이랑 아이피가 공격자 tmp 밑에 cookie.dat라는

파일이 생성됩니다.



cookie.dat 에 들어가면 피해자의 아이피랑 쿠키값이 들어가 있습니다.



이미지 스크립트 위에처럼 작성하시면 됩니다.

위에 작성한 스크립트 언어랑 똑같은 역활을 하고 있습니다.



tail -f cookie.dat 이라고 명령어쓰시면

사용자가 (xss)게시물을 클릭할때마다 아이피랑 로그인 쿠키값이 서버로 실시간으로 보여집니다.





이렇게 공격하는 방법이 있으면 막는 방법도 있겠지요 다음 링크에서xss방어하는

 방법을 알아보겠습니다.

http://itrh.tistory.com/19











[출처] OWASP TOP 10|작성자 정자몽


반응형
  • 네이버 블로그 공유
  • 네이버 밴드 공유
  • 페이스북 공유
  • 카카오스토리 공유