los - rubiya / umaru

 

 

사이트 오픈 초기에는 문제 이름이 "rubiya" 였는데, 직접 구축하면 이름이 "umaru"로 변경되어 있다. 이유는 모르겠음

 

 

reset_flag 가 추가되어서 꽤 어렵게 보이지만 따지고 보면 그렇게 어렵지는 않은 문제이다.

 

어쨌든 소스를 분석하면 다음과 같다.

> flag 파라미터 길이가 100이 넘어가면 에러 발생

> realflag 변수에는 실제 flag 값이 저장됨

> prob_umaru_temp 라는 임시 테이블에 prob_umaru 값이 복사됨

> 입력한 flag 값이 prob_umaru_temp 테이블의 flag 컬럼으로 복사 됨

> 입력한 flag 값이 실제 flag와 일치하지 않으면 reset_flag 함수 호출

> reset_flag 함수는 flag 값을 임의의 값으로 갱신

 

 

정말 운이 좋게 아무렇게 flag 값을 입력했는데 그게 우연히 일치해서 한방에 풀리면 좋지만 그럴 일은 로또 보다 낮은 확률이다.

 

쿼리 테스트를 위해 flag 파라미터에 어떠한 값을 입력 할 때 마다 update 구문이 호출되어 flag는 계속 바뀐다. 그렇다면 update 실행을 막는 쿼리가 공격 쿼리 내 포함되어야 한다.

 

힌트는 "time-based sql injection", "^" 연산자, "에러 발생 쿼리" 이다.

 

 

 

prob25.py