Table of Contents
서치 콘솔 도움말에서 ‘원래 사이트 경로에서 다른 경로의 사이트로 이동이 됩니다.’는 글이 올라왔습니다. 구글에서 자신의 사이트가 검색되는 것을 발견하고 클릭을 했을 때, 공식페이지 co.kr/ 만 정상적으로 접속이 되고 나머지는 다른 곳으로 자꾸 이동이 된다는 내용이었습니다.
일반적 GPE 활동
일반적으로 GPE 활동을 하다 보면 질문자가 구글 제품 관련 고객센터로 착각하고, 자신의 문제를 말하면서 수정을 요구하는 경우가 많습니다. 이처럼 상대가 직접 해결을 원하는 경우도 많기도 하지만, 일반적으로 서버 단에서 처리해야 하는 경우가 대부분이기 때문에 해결이 쉽지 않은 것이 사실입니다. 또 개별 서버 환경은 다르고, 개발자가 직접 묻기보다 다른 분야 실무자의 질문 글이 대부분이기 때문입니다. (GPE에 관한 사용법은 이전 글을 참고 해 보세요.)
납치 스크립트 사례는 해결이 되었을까?
실제로 검색을 하고, 링크를 눌러보니 아직 해결되지 않은 질문이었고, 유입 시 납치를 당하고 있는 것을 확인 했습니다. 공식 홈페이지를 통해서 들어가면 어떠한 문제를 확인할 수 없고, 직접 도메인을 입력하고 들어오는 사용자의 경우에는 사이트에 문제가 있는지 알 수가 없는 상황이었습니다.
301 리디렉션은 아닐까?
사이트가 해킹을 당한 상황에서 납치라면, 301 302로 도메인 주소 이전을 보내거나, 스크립트로 납치를 하는 경우가 있을 수 있습니다. 여기서는 공식 홈페이지에서 납치 문제가 없기도 하고, 공유 디버거 체크 해 보아도 301 이전 사항이 없는 것으로 보아 스크립트가 심어져 있는 것으로 파악했습니다. 그리고 이동하기 직전에 아래 스크립트가 작동되는 것을 확인할 수 있었습니다. location replace를 활용하고 있네요.
location.href와 location.replace 비교
location.replace를 이용하는 경우에 이전 페이지로 이동할 수 없는 것이 특징이고, 사용자의 입장에서 이전 페이지 기록이 남지 않아 내가 납치되어 왔는지 알 수 없게 됩니다. js 중 location.href와의 비교를 하면 아래와 같습니다.
| 항목 | location.href | location.replace() |
|---|---|---|
| 기능 | 새 페이지로 이동 | 기존 페이지를 변경 |
| 히스토리 | 기록 o | 기록 x |
| 뒤로가기 | 호출 전 페이지로 이동 | 불가능 |
| 사용법 | location.href=’xxx.html’; | locaion.replace(‘xxx.html’); |
스크립트 사용 사례 구분
둘을 사용하는 때는 일반적으로 명확하게 구분할 수 있습니다. 이를테면, 일반적인 홈페이지를 둘러보는 경우에 새 페이지로 이동을 하게 되면서 기록을 남겨야 이전 뒤로 가기 기능을 이용해서 내가 원하는 위치로 이동이 가능합니다. 반면 기존 페이지를 변경해야 하는 경우라면, 쇼핑몰 결제 프로세스나 중요 정보를 다른 주소로 이동하게 되는 경우 뒤로 가기를 막아서 접근을 차단합니다.
자바스크립트 location 구글 권고
검색 최적화 입장에서 서버 단의 301 302를 이용해서 봇에게 해당 페이지가 이동 되었음을 알리는 것이 원칙입니다. 또한 구글은 사이트가 이전 되었을 때 납치 스크립트를 이용하지 말 것을 권고하고 있습니다.
해킹의 결과
사이트 납치로 해커가 이득 보는 것
취약점이 노출 된 서버가 가장 공격 받기 쉬운 것이 사이트의 트래픽을 다른 곳으로 끌어들이는 것입니다. 실제로 내가 구글 검색과 같이 유입 대상이 되어보지 않으면 한 눈에 알기 어려울 뿐 아니라, js 사용이 허락 된 티스토리와 같은 서비스는 해킹 사건이 많았습니다. 서버 자체에서 해킹이 아니라 ID 비밀번호 탈취와 같은 형태로 과거에 유행했던 방식이고, 지금은 과거에 구축된 서버 운영에 악용되는 정도로 남아있습니다. 이런 웹사이트를 활용해서 한 곳으로 몰아주는 트래픽은 결국 재산과 힘이 됩니다. 그리고 이전에는 EXE 파일 설치를 유도하는 방식으로도 많이 활용되었는데, 지금 모바일에 악성 앱 설치를 유도하는 방식과도 유사하죠.
특정 위치에서 사이트 납치 어떻게?
같은 하위 도메인으로 이동하더라도 ‘구글검색 > 하위 도메인 주소’는 납치가 되고, ‘홈페이지 > 도메인 주소’는 문제가 없는 것으로 나오는데 이는 스크립트 document.referrer를 이용한 조건문으로 쉽게 구성할 수 있습니다.
<script language="javascript" type="text/javascript">
var url = document.referrer;
if (url.indexOf("google")>0){
window.location.href="https://spam.html";
}
</script>웹 분석에 사용되는 리퍼러는 ‘참조하다’는 의미를 가지고 있는데, 사용자가 사이트를 어떻게 방문했는지를 수집하기 위한 것으로 남기는 흔적을 말합니다. 그 흔적이 구글이라면 구글 입력을 하면 되고, 저 스크립트에 공식 페이지는 예외 페이지로 추가하면 되겠죠?
해결 방법
외부적 입장에서 할 수 있는 얘기는 삭제 밖에 없는 것 같습니다. 하나의 문제인지, 여러 부분 중 일부의 문제인지는 정밀한 체크가 필요하겠죠. 일단 스크립트 설치가 되어 있는 위치가 확인되면 당장이라도 삭제하고, 전문가를 통해 사이트 검수가 필요한 부분이라 생각됩니다.(아마 신규 구축을 포함한 이전을 말하겠지만요)
마치며
관리자가 설치 하지 않았고, 원하지 않는 방향이라면 해킹에 의해 일어난 것으로 보입니다. 일반적으로는 들키지 않기 위해서 검색 결과로만 접근하게 하며, 손대지 않고 코 풀어서 트래픽을 야금야금 모으고 있는 해커는 참 영악하네요. 이런 경우에 운영하는 실무적인 입장에서는, 서버 이전이 어려운 이유로 발생한 문제만 해결(이를테면 스크립트 찾아 지우기)되면 끝이라고 생각하기 쉽습니다. 또한 10년, 20년 전에 턴 키, 솔루션, 아웃소싱으로 구축한 서버 작업이었다면, 당장 작업할 개발자가 없는 경우가 대부분이기도 할 것입니다. 해킹은 교묘하고 악랄하며 끝이 없는 데 비해, 지속적인 업데이트와 관리가 필요한 것이 사실 운영하는 반대의 입장입니다. 하지만 결국 인력 문제나 비용 문제로 해커의 기지국으로 전락하게 되는 상황과 더불어, 나아가 사용자의 사이트 납치나 앱 설치 유도로 2차 3차 문제로 이어질 수 있습니다. 이 건은 결국 해결이 되겠지만, 지금도 비슷한 문제를 지니고 있지만 인지조차 못하는 사이트가 많습니다. 업체의 인력 비용 문제 정도에 불가하던 것이, 사회적 비용 문제가 될 수 있기에 개인적으로 안타깝게 여기는 부분 중 하나입니다.
FAQ
외부적 입장에서 할 수 있는 얘기는 삭제 밖에 없습니다. 하나의 문제인지, 여러 부분 중 일부의 문제인지는 정밀한 체크가 필요하겠죠. 일단 스크립트 설치가 되어 있는 위치가 확인되면 당장이라도 삭제하고, 전문가를 통해 사이트 검수가 필요합니다.
location.href는 사용자의 이동 기록을 히스토리로 남깁니다. 하지만 location.replace는 기존 페이지 자체를 변경하면서 이전으로 이동할 수 없습니다.
웹 분석에 사용되는 리퍼러는 '참조하다'는 의미를 가지고 있는데, 사용자가 사이트를 어떻게 방문했는지를 수집하기 위한 것으로 남기는 흔적을 말합니다.
