모처럼 조치가 쉬워 상호 원만한 합의?를 볼 수 있는 취약점이 나와 담당자에게 보고서를 보내는 데 부담이 없습니다.
메일을 보내고 전화를 받을 가능성이 거의 없는 취약점이기도 합니다.
그래도 우리는 취약점에 조금의 관심은 있는 사람들이니 한번 생각해 봅시다.
왜 불필요한 페이지를 삭제하라고 하는 걸까요?
정보 누출? 정보 노출?이라는 취약점은 왜 있는 걸까요?
지금 사용하고 있지도 않은 페이지인데 왜 굳이 삭제를 해야 하는지... 어차피 기능도 없을 텐데 말이죠.
사실 불필요한 페이지가 야기하는 공격의 영향도가 어마어마하게 큰 경우는 흔하지 않을 겁니다. 그렇지만, 한 가지 취약점만으로 엄청 큰 해킹 사례가 발생하는 경우도 별로 없다는 것도 우리는 알고 있습니다.
공격자에게 정보란 티끌과 같습니다. 공격 시나리오를 완성하기 위해 여러 취약점들을 통해 정보를 수집하고 재조합하면서 정보의 양을 키워나가기 때문입니다. 톰캣 디폴트 페이지나 에러정보를 가지고 해당 서버가 톰캣을 사용하는지에서부터 접근 안 되는 페이지가 권한 때문에 접근이 안 되는 건지 아니면 파일이 없는 건지 등을 확인도 해봅니다. 개발 단계에서 사용하다 남아있는 개발 관련 정보들도 유심히 살펴보기도 합니다. 해당 서비스를 만든 개발팀에서 자주 사용하는 계정명이 있는지, 디폴트 패스워드는 없는지 그런 흔적을 찾아봅니다. 그리고 서버 버전을 확인해서 해당 버전의 서버에서 발견된 취약점이 있는지도 찾아보고 에디터를 사용한다면 에디터 취약점도 찾아볼 수 있습니다. 개발자에겐 사용하지 않아 잊혔지만 업로드 기능이 있는 디폴트 페이지를 찾는다면 이제 본격적으로 여러 가지 악의적인 행위들을 시도해보기도 할 것입니다.
그래서 우리는 가능한 우리의 사이트의 정보를 최소한으로만 보여주려고 노력해야 합니다. 서버 버전 정보를 친절히 알려줘서는 안 되고, 에러 번호로 해당 서비스가 어떤 어려움에 처해있는지 말해줄 필요도 없습니다. 그리고 웹 서버는 어떤 걸 쓰는지, DB는 어떤 걸 사용하는지, 바쁘게 개발하느라 미처 지우지 못했던 디폴트 페이지들을 통한 정보들을 보여주지 않아야 합니다.
꼭 삭제해야 하나요?라는 질문이 자주 오진 않겠지만, 그래도 대답할 수 있는 가상의 시나리오 몇 개를 가지고 있다면 우리는 취약점을 조금은 알고 있는 사람이 된 겁니다.
