로 구분 지어 판단하고 있습니다. 하지만 점검을 하다 보면 이 두 가지 명칭을 나누는 게 의미가 있을까 싶기도 합니다.
우리가 제공하는 서비스에는 다양한 사용자가 존재합니다. 일반 사용자는 게시판에 글은 쓰지만 공지사항에 글을 올리고 삭제할 권한까지 부여받을 필요는 없습니다. 사용자가 클릭하는 메뉴를 변경할 권한도마찬가지로 필요가 없습니다.
그렇기 때문에 권한을 나누어 계정을 관리해야 합니다. 일반 사용자의 권한으로는 관리자 권한의 메뉴들을 이용할 필요가 없거든요.
취약점 점검을 진행할 때는 관리자 권한의 계정과 일반 사용자 권한의 계정을 각각 받아 로그인할 때 각 계정별 송신되는 값 중에 다른 점이 있는지 확인합니다. 단순히 파라미터에 관리자는 admin, 사용자는 user 이런 식으로 구분해서 날리는 경우도 있고 단순 숫자나 특정 코드만으로 권한을 식별하는 경우도 있습니다. 송신되는 권한 식별 값에만 의존하도록 되어있으면 점검자들은, 공격자들은 관리자의 식별값을 찾아 변조해보려고 합니다.
그리고 관리자만 이용할 수 있는 메뉴가 있을 경우. 그 메뉴 접근 시 확인되는 URL을 직접 입력하여 접근이 가능한지 확인합니다. 그리고 단순히 응답 값에 '권한이 없는 메뉴입니다'란 내용이나 단순 코드만 돌아온다면 이 값들도 변조해 봅니다. 그래서 권한이 없는 메뉴와 서비스를 접근할 수 있는지로 이 취약점을 판별하고 있습니다.
관리자를 식별하는 값이나 응답 값의 경우 송수신되는 패킷을 통해 유추할 수도 있고 구글 같은 검색엔진을 이용해 해당 정보들을 획득할 수도 있습니다.
그렇다면 왜 계정을 두 개 이상씩 받아서 진행하는 걸까요? 이 질의는 앞에서 소개했던 관리자 페이지에서도 나왔지만 한번 더 고민해 보도록 하죠.
취약점 점검을 할 때도 직접 찾으면 될 텐데요..라는 의문을 가지시는 분이 있다면 이렇게 답변하면 됩니다.
실제 공격과 달리 취약점 점검은 정해진 기간 내에 완료를 해야 합니다. 대상별 달라지기도 하지만 보통 웹사이트는 일주일에 1개, 모바일 앱은 2개 정로 공수를 잡고 있습니다.(실제로는 1주일 n개 이상.. 더 열악.. 음.. 음) 하지만 타깃을 정해서 하는 해킹의 경우 공격자의 실력과 공격 기간이 얼마나 될지는 가늠할 수 없습니다. 그렇기 때문에 취약점을 확인하는 기간 내에 우리가 서비스 입구에 만들어 놓은 여러 방어 로직이 우회된 경우까지도 고려해야 합니다. 취약점 점검자도 공격자도 권한 식별 값과 메뉴에 직접 접근하는 URL 경로를 획득하는 데 넉넉하게 1주일이 소요됐다고 하면, 취약점 점검자는 그다음 주에는 다른 서비스를 점검해야 하지만
타깃을 잡은 공격자는 더 많은 시간을 추가로 쓰고 있을 테니까요.
그렇게 해서 뚫렸을 때 우리는 추가적인 최소한의 방어는 할 수 있어야 합니다. 사용자 계정이 뚫렸다면 관리자 권한을 이용하지 못하게 해야 하고, 관리자 권한이더라도 권한을 세분화시켜 모든 메뉴와 서비스를 바꿀수있는 슈퍼 관리자 권한을 얻지 못하도록 해야 합니다.
부적절한 인가 취약점에 대응방안을 간략하게 설명해 달라는 문의가 온다면 사용자의 권한을 분리해서 관리하고 민감한 메뉴 접근 시에는 추가 인증 수단을 구현해야 한다고 답변해 주시면 되십니다.
