JavaScript Hijacking
귀차니즘에 안 읽고 있다가 관련글이 trax씨 홈에 있어서 읽어보게됐습니다. 단지 CSRF (Cross Site Request Forgery)의 변형이라는 비판도 있지만 그게 본질은 아니고.. 이 페이퍼는 해당 공격방법이 AJAX를 대상으로한 최초의 취약점 공격이라고 주장함.

가정: vulnerable.com은 vulnerable.com/object.json 파일을 통해 confidential한 데이터를 전달하는 곳입니다.
1) victim은 vulnerable.com에 로그인한 상태.
2) attacker.com은 Object의 생성자를 오버라이딩하여 객체의 값이 바뀔때 이를 로깅하게 하는 코드를 쓴 다음 <script src=”http://vulnerable.com/object.json”></script>를 합니다.
3) victim을 대신하여 attacker.com은 vulnerable.com을 접속하게 되고 따라서 object.json을 받아오게되고 이 객체가 initialize되면서 오버라이딩된 Object의 생성자가 불리고 이때 2단계에서 작성한 로깅 코드에의해 confidential 데이터가 누출됨.

막는 방법들..
1) 일단 CSRF에서 막는건 다 사용가능. 예를들면 요청시 쿠키 박아넣어야만 되도록 한다던가, 세션 아이디를 http://vulnerable.com/object.json?sid=… 과 같이 꼭 붙이도록 하는 것들.
2) script src=”…”을 사용해 object.json을 불러오지 못하도록 object.json의 앞부분에 while(1) 넣기

다음으로 ASP.NET의 javascript hijacking 방어 기법으로 소개된 내용.(JSON Hijacking and How ASP.NET AJAX 1.0 Avoids these Attacks)
3) 기본적으로 GET method를 막기때문에 script src=”…” 로 object.json을 부를 수 없다.
4) 자동으로 HTTP 헤더의 Content-Type: 필드가 application/json인지를 점검함. 만약 앞서의 예처럼 script src=”…”로 부르게되면 헤더가 text/javascript로 설정되므로 이를 막을 수 있다.

그러나 3, 4의 방어기법중 3번은 당연히 다른 웹 프레임웍에서도 모든 메소드를 마구 허용해서는 안되며 특히나 GET으로 sensitive info를 주고 받아서는 안되겠죠. 4번의 경우는 ASP.NET의 흥미로운 특징이지만 마찬가지로 phishing 사이트를 잘 구성했다면 뚫을 수 있다고 봅니다. 가장 강력한 해결방법은 1번. attacker.com은 victim의 세션을 읽을 수가 없으므로(same origin policy) 세션 아이디를 GET메소드의 뒤에 붙여서 보내는지 점검하면 이 경로로는 뚫기가 불가능합니다.