인증 / 인가 취약점

이정민·2024년 2월 21일

웹 해킹 공부 정리

목록 보기
17/18

이번에는 인증과 인가의 개념과 취약점에 대해 알아보겠습니다.

인증

인증은 그 사람이 본인이 맞는지 확인하는 작업이라고 보면 됩니다. 예를 들면 로그인을 하기 위해서 비밀번호를 입력하고, 본인이 맞는지 확인하기 위해 핸드폰으로 인증번호를 받아 입력하는 것 등이 인증이라고 보면 됩니다.

인증 취약점

인증 취약점은 인증하는 과정에서 일어나는 취약점, 인증을 무시하고 넘어가버리는 취약점 등이 있습니다. 케이스로 나눠보겠습니다.

클라이언트 측 정보를 통해 인증하는 경우

클라이언트 측 정보를 이용해서 인증하는 케이스입니다.
Cookie를 통해 로그인을 인증하는 경우가 있다고 생각해보면 a라는 계정으로 로그인할 때, 쿠키가 name=a 등으로 요청에 입력됩니다. 이 때 요청을 가로채서 a를 b로 바꾸면 b의 계정으로 로그인 되는 등 악용될 수 있습니다.
그 외에도 익명 게시판에 댓글을 작성할 때 비밀번호를 쓰는 형식이고 수정이나 삭제를 하려면 작성했던 비밀번호를 입력해야 하는 경우가 있는데, 이런 것도 스크립트를 까거나 하면 다 드러나는 등 취약한 모습을 보이니 주의해야합니다.

Process를 점프하는 경우

회원가입같은 경우에는 1. 약관 동의, 2. 본인인증, 3. 회원가입 등 절차가 있습니다. 이 때 각각의 페이지가 url이 다르고, 해당 url을 알고 있는데 각 페이지에서 절차를 넘어도 문제가 생기지 않도록 설계가 되어있는 경우에 약관 동의 페이지에서 본인인증을 건너뛰고 회원가입으로 넘어가는 등 url 직접접근을 통해 절차를 점프하는 경우도 있습니다.

파라미터 응답값 변조 경우

파라미터의 응답값을 변조해서 로그인 되는 경우입니다. 예를 들면 로그인을 시도 했을 때 보통은 id와 pw를 확인하고 맞으면 세션값을 주고 처리하는 반면 이 문제에 해당하는 경우에는 시도한 id의 세션값부터 주고, 그 이후 id와 pw를 검증하고 loginStatus같은 파라미터를 통해 ok, fail 등의 파라미터를 줘서 로그인 실패와 성공을 제어하는 케이스입니다. 일반적으로 웹 페이지에서는 흔하지 않으며, 프로그래밍이 잘 못된 경우라고 볼 수 있지만 모바일앱에서는 이러한 취약점이 상당수 존재합니다.

인증 횟수 제한을 하지 않은 경우

말 그대로 횟수에 제한을 두지 않은 경우로 무작위 대입 공격에 취약합니다. 특히 비밀번호 입력의 경우에는 제한을 두는 경우가 많지만 종종 마이페이지에서 비밀번호 변경을 했을 때, 비밀번호를 확인하는 페이지에서는 제한을 두지 않는 경우가 종종 있습니다. 이런 경우 다른 방식으로 해당 계정으로 로그인했을 때 비밀번호를 변경하기가 수월해집니다.

인가

인가는 특정 권한을 부여하는 것입니다. 이 권한은 게시판을 예를 들면 a가 글을 썼다면 a는 그 글을 읽고, 수정하고, 삭제할 수 있지만 다른 사람인 b는 읽을 수는 있지만 수정, 삭제를 할 수 없습니다. 다른 경우로 예를 들면 관리자는 게시판에 새로운 항목을 만들거나 삭제하고, 공지사항을 쓰는 등 다양한 일을 할 수 있지만 일반 유저는 그런 것을 할 권한이 없습니다. 이러한 특정 권한에 대한 것이 인가입니다.

인가 취약점

인가 취약점은 위에 적혀있듯 권한을 가진 것만 할 수 있는데 이런 권한이 없어서 원래는 할 수 없는 일을 할 수 있도록 하는 취약점이 인가 취약점입니다.

주석으로 접근을 제한하는 경우

권한에 따라 행동을 제어하는데 이것을 주석이나 css에서 display:none; 등 페이지 내에서 제어하는 경우 단순히 페이지를 보고 주석을 지우거나, css에서 none을 지우는 등 쉽게 제한을 풀 수 있습니다.

인가 확인을 클라이언트 측에서 하고 있는 경우

인가에 대한 부분을 해당 계정이 맞다면 함수를 실행해서 인가하는 등 클라이언트 측에서 하고 있는 경우가 있을 수 있습니다. 이런 경우 해당 페이지, 페이지와 연결된 js를 분석해보면서 취약한 부분을 공격할 수 있습니다.

guessing 공격

guessing 공격은 이름 그대로 추론해서 공격하는 방법입니다. 예를 들면 일반 계정으로는 공지사항을 볼 수는 있지만 작성하는 것은 불가능합니다. 그러나 각 페이지에 따른 url이 공지사항 리스트는 notice_list, 읽었을 때는 notice_read일 경우에 각 페이지의 url을 보고 추론해서 공지사항 작성 페이지의 url이 notice_write, notice_create 등의 url을 지닐 것이라고 추론할 수 있는데 이런 방법으로 공격하는 것이 guessing 공격입니다.

파라미터 변조

파라미터 변조는 게시판으로 예를 들면 내가 글을 작성했을 때, url에 id=43이 붙습니다. 그런데 다른 사람의 id가 46일 때 글을 삭제하면서 해당 id를 46으로 변조하면 id가 46이 붙는 사람의 글이 삭제되는 경우가 있습니다. 이런 방식으로 파라미터를 변조해서 내가 아닌 다른 사람의 이름으로 글을 작성하거나, 다른 사람의 글을 삭제하는 등의 행위를 하는 것이 파라미터 변조를 통한 공격입니다.

profile
공부중

0개의 댓글