WebGoat(웹고트) LAB: Role Based Access Control Stage4

WebGoat(웹고트) LAB: Role Based Access Control

Stage 4 : Add Data Layer Access Control

 

이전 포스트에 이어서 작성하였습니다.

[보안 취약점 진단 및 대응/WebGoat] - WebGoat(웹고트) LAB: Role Based Access Control Stage3

WebGoat(웹고트) LAB: Role Based Access Control Stage3

 

---

(1) eclipse에서 Ctrl + Shift + R을 눌러 ViewProfile.Java를 검색합니다.

 

(2) 문제가 되는 부분을 확인합니다.

 

(3) 문제가 있는 코드를 수정합니다.

SELECT * FROM employee, ownership

=> employee : 직원 정보를 저장하고 있는 테이블

=> ownership : 직원(employer)이 볼 수 있는 직원(employee) 정보를 저장하고 있는 테이블

=> ownership.empolyer_id = userId : 현재 로그인한 직원ID(세션에서 추출)

=> ownership.empolyer_id = subjectUserId: 조회 대상 직원 ID(파라미터로 전달된 값을 사용)

 

(4) 실행결과 

이전 포스트 Stage 3과 동일하게 실습을 진행합니다.

1. LAB: Role Based Access Control - Stage4를 찾아 이동

2. Tom Cat으로 로그인(비밀번호 tom)

3. Proxy에서 Intercept is on으로 설정하고 SearchStaff 또는 ViewProfile 버튼을 클릭

4. employee_id=112로 변경 후 Intercept is off로 설정

5. 미션 완료

 

Stage 3과 동일하게 tom으로 로그인합니다. 이어 Proxy에서 Intercept is on으로 설정하고 ViewProfile을 클릭합니다.

 

이전과 동일하게 employee_id=112로 바꾸고, Intercept is off로 설정합니다.

실행된 결과를 확인합니다.

=>전체 null로 표시됩니다.

=> 안전한 쿼리로 바꾸게 되면 112는 tom이 조회할 수 없는 사용자가 됩니다. 즉, 조회결과가 없기 때문에 Employee profile이 null이 됩니다. 

 

접근통제를 할 때, 파라미터 또는 URL을 분석하여 패턴을 찾아야합니다. 그리고 주소를 호출하거나 매개변수를 바꾸어 가면서 노출되지 않는 패턴을 적용해봅니다. 이 부분에서 취약점이 발견되면 "기능 수준에서 접근통제 누락"이라고 판단할 수 있습니다. 

일반적으로 단일 데이터를 가져와서 그 데이터만 출력해준다면, 페이지 쪽으로 전달되는 값을 조작하여 원래 안보이는/보이면 안되는 정보를 찾습니다. 이 부분에서 취약점이 발견되면 "데이터 수준에서 접근통제 누락"이라고 판단할 수 있습니다.