WebGoat는 취약점을 테스트할 수 있는 애플리케이션이라고 한다. 이론 공부하고 실습을 여러 번 해봤으니 문제를 좀 풀고 싶어서 설치해봤다. 내 실력에 도움이 됬으면 좋겠다!! 더불어 재미도 보구 ㅎㅎ
아래에서 다운 받을 수 있다.
Releases · WebGoat/WebGoat
WebGoat is a deliberately insecure application. Contribute to WebGoat/WebGoat development by creating an account on GitHub.
github.com
2-5번 문제는 기본적인 DCL/DDL/DML 등을 묻고 있었음 -> 패쓰
문제가 요구하는 것은 테이블의 모든 유저를 조회하라는 것이었다.
select * from user_data where first_name='John' and last_name='raw query를 이용해 모든 내용을 조회하는 쿼리를 만들어보자! 난이도가 굉장히 쉬운 편이라 어렵지 않게 할 수 있을 것이다. 모든 유저를 조회하라는 것은 where 절 자체를 참으로 만들어 버리면 된다.
위와 같이 넣어주면 성공할 것이다.
싱글 쿼터를 넣어 우리가 입력할 구문이 SQL문으로 처리되도록 끝맺어주고, 조건절을 참으로 만들어주기 위해 or '1'='1 를 넣어주어 전체 조회를 할 수 있게 된다.
물론 싱클 쿼터 대신 Smith' 라는 보기도 있었다. 이 역시 상관 없다. 그냥 싱글 쿼터를 넣게 되면 or 앞의 조건이 거짓이 될 뿐이고, Smith'를 넣게 되면 단지 앞의 조건이 참이 될 뿐이다. 뒤의 or True 구문으로 인해 결과적으로 조건문은 참이 되어 모든 구문이 나오는 것은 동일하다.
+언제 한 번 다뤄봤던 것 같은데 복습 차 한 번만 더 해보기로 한다!
or 구문 앞의 조건식이 틀렸을 때의 결과. 이는 당연히 or 1=1에 의해 참이 되어 전체가 조회될 것이다.
or 구문 앞의 조건식이 맞았을 때의 결과. 쇼트 서킷을 아는 사람이라면 오히려 헷갈릴 수 있다. 앞의 and 구문이 맞으니까 뒤의 or 구문 볼 필요 없이 guest에 해당하는 데이터만 출력될꺼라 생각하겠지만 or이 붙어버려 뒤의 문은 보지 않겠지만 구문이 True인 결과가 되버리는 것을 생각해야 한다. DB 종류나 버전이 달라지면 달라지려나 라는 생각은 들지만..
일단은 알아두기!
Numeric SQL Injection를 시도해봐라!! 라고는 하는데 이게 뭔지는 모르겠고 숫자와 관련된 SQLi 같은데 숫자로 하는 특별한 방법이 있나 솔직히 모르겠다.
그저 SQL 문을 보니까 문자열을 받지 않고 숫자만 받게 되있어서 Numeric이라고 했나보다. 라고 생각하고 이번에도 역시 조건절을 참으로 만들어 줬더니 바로 풀렸다.
이번에는 SQL 인젝션을 통해 기밀성을 훼손시키라는 문제이다.
우선 나(?)는 John Smith라는 인간이고 내 인증 TAN은 3SL99A라고 한다.
나(???)는 아주 나쁜 인간이라 내 정보가 아니라 다른 직원들의 정보를 모조리 확인하고 싶다!!!
우선 정상적으로 내 자신을 조회해봤을때 정보를 확인하고,
내 응답이 SQL문으로서 제대로 작동하는지 확인도 해준다. # 주석이 안되는 걸로 보아 Oracle 아니면 MSSQL 같은 DB인 듯 하다. 깨알같은 소소한 핑거프린팅..
작성했던 쿼리에 조건식이 참이 되도록만 추가해준다. 아직까지는 난이도가 쉽다 (다행히 ㅠㅠ)
다음 문제는 무결성을 훼손하라고 합니다이
이번 목표는 나보다 돈 잘버는 직원들에게 질투심과 부러움을 느낀 나머지 내가 돈을 제일 잘 벌게끔 바꿔버리는 것!!
우선 먼저 전체 직원들을 조회를 해본다. 저 정도 벌면 잘 벌지 뭘 바라는 건가
union으로 화면에만 돈을 잘 벌게끔 찍고 싶었는데 union select문은 먹지 않았다. 어쩔 수 없이 update문으로 데이터를 바꿔버리는 수 밖에..
select문에 냅다 update문을 박아버릴 수는 없고 select문을 강제로 끝낸 후에 update문으로 급여를 바꿔버리면 된다.
Employee Name: X'; update employees set salary='99999' where userid=37648-- -
Auth TAN: 0위와 같이 쿼리를 넣어주었다. 테이블명은 게싱한게 아니라 문제가 계속 같은 테이블을 기준으로 해결하는 거라 이미 알고 있었던 것이다.
마지막 문제. CIA Triad의 마지막 부분인 가용성을 훼손하면 된다.
이제 내가 돈도 잘 버는 못된 인간도 됬겠다 내가 했던 행동에 대한 로그가 남아있는 테이블을 없애버려라!!가 이 문제의 요지인 것 같다.
우선 access_log 테이블을 날려버리라길래 그냥 drop table access_log를 입력했는데 문제가 풀리지 않아서 뭔가 했는데 쿼리 형식인가? 하고 저래 집어넣으니 됬다.
