솔루션을 납품하는 경우와 같이 웹 애플리케이션을 고객에게 쥐어주면 웹 취약점 스캐닝 툴로 돌린 결과를 가지고 뭐라뭐라 하는 경우들이 있다. 보통 보안팀이 따로 있어 납품된 애플리케이션의 보안 부분을 검수하는 회사들이 주로 그러는데 그런 걸로 돌렸을 때 취약하다고 나오는 것 중에 대표적인 예가 바로 '관리자 페이지 노출'이다.
물론 관리자 페이지가 아무런 보안 장치 없이 통째로 노출되어 있다면 말도 안되게 위험한 일이다. 하지만 대부분의 취약점 툴이라는 애들은 http://abcd.com/admin 과 같이 그냥 주소 뒤에 admin, administrator, administration, manage, manager 등으로 인증없이 들어가서 들어가지면 그냥 위험하다고 나온다. 그리고 제대로 개발했다면 이 페이지는 그냥 관리자 로그인 페이지일 것이다. 뭐 그래도 취약하다면 할 수도 있다. 무차별대입을 하다가 보면 관리자 로그인이 될테니 말이다.
우리의 고객(이라 쓰고 갑님이라 읽는다)은 '어쨌거나 니네 취약하다고 하지 않냐 얼른 고쳐라'라고 할테고, 실제로도 단지 저 상태라면 무차별 대입에 취약하다고 할 수 있으니 손 보긴 해야 한다.
설계가 최선
이걸 해결하는 가장 좋은 방법은 아예 애플리케이션을 설계할 때 관리자 로그인과 사용자 로그인을 따로 두지 않는 것이다.
이렇게 하면 URL로 어딜 가든 하나 밖에 없는 로그인 페이지로 보내거나 아니면 로그인이 안되어 있는 상태로 접근을 했다고 에러를 뿜어내기만 하면 된다. 실제로 많은 툴은 요청된 후에 경로가 /admin 같은 곳에서 벗어나면 안전하다고 여기거나 http 응답 코드로 404 등 정상 응답이라고 여겨지지 않는 경우에 안전하다고 여겨진다.
하지만 의외로 /admin 등이 있긴 있는 거구나... 라고만 느껴진다면 취약하다고 진단하는 툴들이 있는데 이럴 경우에는 에러 코드로 404 Not Found를 던지면 피해갈 수 있다.
하지만 이미 개발 다 된 애플리케이션이라면 구조를 바꿔가며 어떻게 로그인을 하나로 합치겠는가. 어쩔 수 없이 다른 방법을 찾아야 한다.
IP로 접근제한 걸기
관리자 페이지에 접근할 수 있는 IP에 제한을 두고 모든 관리자 페이지로의 접근 시 마다 검사를 하는 방법이다.
내부 IP를 사용한다거나 등등의 이유로 검사툴이 실행되는 환경과 실제 관리자가 운영해야 할 환경의 IP가 같은 경우에는 소용이 없는 방법이다. 그렇긴 해도 운영하는 주체와 보안 검사를 행하는 주체는 보통 다르기 때문에 쓸만한 방법이긴 하다.
공통되는 코드에 적용해서 구현할 수도 있고 서버 인증이나 기타 서버 설정을 이용해서도 구현할 수 있다.
URL 꼬기
관리자 페이지를 http://abcd.com/djemals ('어드민'을 영어로 놓고 썼다) 으로 바꾼다거나 ../power 로 바꾼다거나 하는 방법이다.
어차피 검사 툴로 하는 검사이기 때문에 관리자 페이지라고 예측되어지는 URL만 피하면 되니 이렇게 할 수도 있다.
이 방법은 관리자 페이지의 각종 리소스(이미지, CSS, Javascript)의 링크에 ./admin /admin 등등의 방법으로 이미 잔뜩 써져 있다면 적용하기가 쉽지 않을 수도 있다. 게다가 꼭 URL에 admin이 들어가야 동작하는 부분이 있다던가 한다면 그냥 다른 방법을 찾아보자. 이 방법을 적용하다가 버그만 생긴다.
다른 도메인으로 옮기기
관리자 페이지만 따로 떼어내서 다른 도메인에 연결하는 방법이다. 원래 사이트 도메인이 abcd.com 라면 admin.abcd.com 에 관리자 페이지를 연결하는 방법이다.
관리자 페이지만 따로 떼어내거나 서버 설정을 통해서 처리할 수도 있고, 동일한 애플리케이션을 두 군데 설치해서 각각 관리자 페이지와 사용자 페이지의 접근을 막는 방법도 생각해 볼 수 있겠다.
협상하기
이런 저런 방법을 모두 쓰기 어렵다면 별 수 없다. 영업으로 해결하는 수 밖에..
로그인 페이지는 원래 노출될 수 밖에 없는 거라고 취약점이 아니라고 얘기하자. 이 정도로 잘 안통하면 로그인 페이지에 captcha를 건다거나 반복해서 로그인 실패하면 잠시동안 로그인 할 수 없게 하는 기능 등을 넣어 무차별대입 공격에 대비하여 보안성을 강화하겠다고 협상해보자.
이런 저런 상황속에서 개발을 하다가 보면 관리자용 로그인을 따로 쓰고 내부에 저장되는 계정 정보도 따로 관리하는 경우가 많은데 나는 일반 사용자 계정에 권한을 두어 관리자로 삼는 것이 더 좋다고 생각한다. 중복되는 계정 관리를 안해도 되고 중간에 관리하는 사람이 바뀌어도 권한만 바꾸어주면 되며 실제 관리자도 계정 정보를 하나만 기억하고 있으면 되기 때문이다. 이런 문제는 차츰 설계를 바꾸는 쪽으로 해결을 하도록 하자.
혹시 다른 방법이 있다면 공유해 주시면 다른 사람들에게 보탬이 될 수 있지 않을까 싶다.