서비스를 제공하는 사람, 운영하는 사람, 디자인을 하는 사람 등등 각자 자기 업무에 중심을 두고 서비스를 보고 있을 텐데 말이죠. 취약점이라고 이해되지 않는 내용은 상대방에게 단순한 지적에 불과하지 않는다는 걸 깨달았습니다.
그래서 제가 취약점이라고 생각한 부분이 상대방에게도 취약으로 보여야 서로 간 원활한 대화로 이어질 수 있음을 알게 되었습니다.
흔히 XSS 취약점을 보여줄 때 화면에 팝업창을 띄워서 설명합니다. 자세한 설명은 생략하기 때문에 해당 취약점을 처음 보는 사람에겐
"화면에 팝업이 뜨니 위험하다"
로 밖에 보이지 않습니다.
그럼 취약점을 자세히 모르는, 하지만 자기 업무에선 베테랑인 상대방은 생각하겠죠.
"그래서? 화면에 떠서 뭐"
그리고 그걸 생각만 할 수도 있고,
때로는 보고서를 준 사람에게 물어봐서 점검자를 역 당황시킬 것입니다.
우리 점검자들에겐 당연한 취약점이지만
그래서 왜?라고 물어보는 상대방의 질문도 사실 이상하진 않습니다.
점검자라면, 그리고 보고서를 준 사람이라면 이에 대한 답변을 가지고 있어야 합니다.
우리의 목표는 취약점을 제거해서 안전한 서비스를 제공하는 거니까요.
XSS(Cross Site Scripting)
크로스사이트 스크립팅은 초보 점검자에겐 조금 매력적인 취약점이기도 합니다. 찾는 게 어렵지 않거든요. 진짜 진짜 취약점이 안 나올 때, 취약점 없음 보고서를 내는 내가 부끄러울 때 그래도 하나는 찾았다는 느낌을 주는 몇 안 되는 취약점이기도 합니다.
그리고 정말로 팝업이 뜨는 것만으로 위험하다고 생각해서 취약점으로 잡는 건 아닙니다.
XSS 취약점을 이용하는 방법은 XSS 공격 구문이 포함된 URL을 피해자에게 문자, 메일 등을 이용해 전달할 수 있습니다. 게시물에 숨겨놓고 피해자가 해당 게시물을 클릭할 때 공격자가 의도한 행위를 하도록 유도하기도 가능합니다. 이때, 희생자는 일반 게시물을 보았다고 생각하고 있을 겁니다. 그렇기 때문에 서비스를 제공하는 쪽에서 방어를 신경 써서 해야 합니다.
구체적으로 왜 취약할까요?
크로스사이트 스크립팅 취약점의 영향으로는 여러 가지가 있는 데 그중 다른 사이트로의 리다이렉션과 세션 탈취만 간단히 소개해보겠습니다.
XSS 취약점을 가지고 있는 파라미터로도 URL Redirection 취약점처럼 악성 사이트로 리다이렉션을 시킬 수 있습니다. 그래서 접속을 한 이용자로 하여금 자신이 접속한 A사이트가 아닌 다른 사이트에 접속이 되도록 합니다. 물론 대놓고 악성 사이트 느낌일 수도 있지만, A사이트와 유사하게 만들어 이용자가 A사이트에 정상적으로 접근했다 생각하게 할 수도 있습니다. 로그인 기능도 구현해서 아이디 패스워드를 가져오기도 하고 휴대폰 인증번호를 받도록 유도하여 해당 인증번호를 공격자가 이용자인척 이용 할 수도 있고요.
세션 탈취의 경우, XSS이 발생하는 게시물을 클릭하거나 URL접속 시 해당 사이트를 이용하고 있는 사용자의 세션키 값을 공격자 서버로 전송시킵니다. 그리고 이용자가 다른 메뉴를 클릭하고 서비스를 이용하는 동안 공격자도 함께 이용자의 권한으로 서비스를 이용합니다. 물론 세션에 대해 안전하게 처리하는 사이트라면 어느 정도 보완은 되겠지만 XSS 취약점은 XSS 대응방안으로 조치해야 근본적인 문제 해결이 가능합니다.
그리고 XSS 취약점을 점검을 할 때는 태그가 삽입되느냐를 중심으로 확인합니다.
우선 태그가 삽입되는지 어느 부분에 들어가는지를 확인한 다음 공격구문을 만듭니다. 필터링이 되어 있다면 필터링 처리가 안되어있는 특수문자가 있는지 응답 값의 반응을 살피면서 구문을 완성해 갑니다.
그래서 < ( 등의 대표적인 특수문자를 필터링하더라도 ;' 이런 특수문자만으로도 공격 구문을 완성할 수 있습니다.
창을 띄우지 않고 오히려 은밀하게 숨기는 것도 가능합니다.
그럼 왜 보통 보고서에 팝업창으로만 보여주는 걸까요?
공격 시나리오 기반의 모의해킹 보고서와 달리 체크리스트 기반의 취약점 보고서에서는 취약점이 존재하는지를 중심으로 보여주는 보고서 이기 때문에 취약점 발생을 한 장으로 보여주기 위해 알림 창 화면을 보여줍니다.
단순히 특수문자를 파라미터에 넣었더니 응답값에 필터링되지 않았다로 취약점이라 판단되는 게 아니라 해당 특수문자가 어떤 태그로 삽입되어 어떻게 실행이 가능한지를 보여주기 위함으로 alert을 이용하여 전달하고 있습니다.
XSS 취약점으로 혹시라도 취약점이 맞냐고 물어본다면 다시 위로 가서 설명을 하고
앞으로 다른 취약점에 대한 조치 사항으로도 많이 나올 입력 값 검증을 한번 언급해 줍니다.
"XSS 취약점에 대한 대응방안으로는 입력 값에 대한 검증이 필요합니다. 그리고 입력 값을 웹페이지에 다시 출력할 때 HTML이나 Javascript로 해석될 수 있는 특수문자를 안전하게 변환하도록 처리해 주시면 되세요! 하고 끊으면 됩니다.
