broken access control.txt

OWASP
 Open Worldwide Application Security Project
  --> 단체 이름임. 소프트웨어 보안 개선을 위해, 전 세계의 개발자/보안 전문가가 참여

OWASP Top 10
 -> 웹 애플리케이션에서 발생하는 치명적이고, 빈번하게 발생하는 10대 보안 취약점 목록
 --> 새로운 항목도 추가되지만..
 ---> 기술적 연관성에 따라 독립된 항목이 특정 카테고리로 흡수·통합되거나, 반대로 세분화되는 등 지속적인 재분류 과정을 거침
 ----> 오늘 소개할 OWASP2021-A01 도 여러 취약점이 하나의 카테고리로 합쳐지며 분야가 넓어졌기 때문에, 1순위가 된 것

CWE(Common Weakness Enumeration) -> 취약점을 유발하는 근본 원인이나 결함. 즉 '개념'
CVE(Common Vulnerabilities and Exposures) -> 실제 취약점 번호별 분류. 즉 '실제 사례'

인증(Authentication) <-> 인가(Authorization)
 -> 구분을 잘 해야 한다.
 - 인증은 '당신은 누구입니까?' -> 내가 특정 사람이라는 것을 증명 가능한 것
   ex) 로그인
 - 인가는 '당신이 가진 권한은 무엇입니까?' -> 인증을 거친 사용자가 어떤 '권한'을 가지고 있는가?

그렇다면, 웹 애플리케이션은 어떻게 사용자 인증을 받는가?
 -> HTTP의 특성을 알아야 함: Stateless -> 서버가 클라이언트의 이전 상태를 기억하지 않는다
     : 점원에게 아메리카노 한잔 주세요(주문 완료) -> 샷 하나만 추가해 주세요 -> 점원은 이전에 아메리카노 한잔 주문한 것을 기억하지못함
         --> 왜 이렇게 만들었나? : 요청이 들어오는 대로 처리만 하면 되니까 서버 자원을 아낄 수 있다
-> 쿠키와 세션: HTTP의 Stateless를 보완하기 위한 기술
 -> 유저가 로그인 요청을 하면, 서버에 사용자 정보를 저장함(세션) -> 이후 세션 ID를 유저에게 리턴함
  --> 이후 유저는 세션 ID를 요청에 붙여서 보내며, 서버는 해당 ID를 보고 해당 유저임을 알수 있음(놀이공원 입장팔찌같은거임: 이때, 세션ID가 저장되는 곳이 웹 브라우저의 쿠키)
   --> 쿠키란 웹 브라우저가 사용자의 컴퓨터에 저장하는 작은 텍스트 파일임

예를 들면, 일반 사용자 계정으로 로그인
 -> 게시글 작성이나 조회 가능. 하지만 관리자 페이지에는 접근 불가능
 --> 관리자가 아닌, 일반 사용자 계정으로 로그인 한 후, 관리자 페이지에 접근 가능하면 안 됨
 ---> OWASP Top 10 2021:A01 - Broken Access Control
 ----> 즉, '인증' 단계에서 문제가 발생한 것이 아닌, '인가된 권한을 제대로 제한하지 않은 것'에서 발생하는 문제

수평적 /수직적 권한 상승(Horizontal/Vertical Privilege Escalation)
 -> 수평적의 경우, 동일한 권한 레벨을 가진 '다른 사용자의' 데이터에 접근
 --> 수직적의 경우, 더 상위의 권한 레벨을 필요로 하는 데이터에 접근
 ! 왜 발생하나? -> Client-Side 검증에 의존하거나, 기본 정책 설정의 오류 등.

Client-Side 검증이란?
 - UI 관리자 메뉴 버튼을 숨기거나, 자바스크립트로 API 접근을 막는 것
 --> 악의를 가진 사용자가 노출되지 않은 API/데이터 에 접근하려 할 때, Server-Side에서의 검증이 필요함

 단순하게 말하면 -> 단순히 URL 창/Burpsuit에에서 아이디나 요청값 변경 등, 요청하면 무조건 주는 것 X
  --> 어떤 아이디로 로그인했나, 어떤 IP 대역에 있나 등, 해당 사용자에게 '인가'된 요청인가? 를 서버사이드에서 신경써야 함

하위 항목으로는?

강제 브라우징 및 경로 조작(Forced Browsing/Path Traversal)
 -> 인증되지 않은 일반 사요자가 URL(URI) 경로를 직접 조작/수정해 관리자 페이지 혹은 보호된 파일에 접근

[가장 대표적]
Missing Authorizaion CWE-862
방금 말씀하신 실습(주소창에 관리자 URL을 직접 입력하여 접근에 성공하는 행위)이 정확히 A01: 깨진 접근 제어 항목의 가장 대표적인 공격 사례(강제 브라우징/수직적 권한 상승)에 해당합니다.

안전하지 않은 직접 객체 참조(IDOR -> Insecure Direct Object References)
 ->서버가 클라이언트 요청 시 파라미터로 전송되는 ID값(사용자 ID 혹은 문서 번호 등)을 검증하지 않아 타인의 데이터에 접근 가능한 경우
https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/ 여기에 CWE-639에 있음

권한 상승(Privilege Escalation)
 -> 사용자의 접근 권한을 잘못 할당하거나 검증하지 않아 일반 사용자가 관리자 권한을 획득하는 경우

기능 및 메서드 권한 누락(Missing Function Level Access Control)

잘못된 기본 권한(Incorrect Default Permissions / CORS)

위조 및 리디렉션(Forgery / Redirection)




CWE-862 실습
admin / password 로그인
authorization bypass 항목 확인 -> 유저의 db 바꿀 수 있는 것 확인하기
url 복사해놓기
로그아웃
pablo / letmein (저번에 sql injection으로 비밀번호 크랙했던) 으로 로그인
authorization bypass 항목이 안 보이는 것 확인
복사해놓았던 url로 접속 가능한 것 확인 + 유저의 정보 바뀌는 것 확인

! 세션개념 설명도 해야함
 -> rocky기준 /var/php/session 에 있는 세션아이디를
 칼리 파이어폭스에서 스토리지 -> phpsessid 에 일치하는게 있는거 보여주기
  + burpsuite에서도 세션아이디 날아가는거 보여주기

sess 파일 안 내용 설명 -> 제미나이 참고해서 써놓자

+ 모의해킹이나 취약점 진단 시, "로그아웃을 했는데도 세션 파일 내부 데이터(username 등)가 여전히 그대로 남아있고, 
브라우저에서 해당 쿠키 값으로 재요청했을 때 다시 로그인이 유지된다"면 
이는 명백한 세션 만료 미흡(Weak Session Management) 취약점입니다.