사이트 오픈 초기에는 문제 이름이 "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 값을 임의의 값으로 갱신 정말 운이..

이전 hell fire 문제와 동일한 곳에서 인젝션이 발생한다. 문제는 에러 부분인데, 이전 문제에서는 적어도 리턴 페이지에 에러를 출력해 줬으나 이번 문제는 에러가 나면 리턴 페이지는 무조건 빈 페이지가 된다. limit 인젝션 특성 상 공격 쿼리가 무조건 오류가 나는데, 오류를 안 보여주니 미칠 노릇일 수 밖에 없다. 힌트는 바로 시간인데, 이번 문제는 "time based - sql injection" 기법을 사용해야 한다. 이전 문제에서 읽어보라고 했던 링크의 마지막 쿼리 끝에 보면 BENCHMARK 함수가 존재한다. 해당 함수가 실행되면 약간의 타임 딜레이가 발생하는데 이것을 이용하여 공격 쿼리의 성공/실패 여부를 판단할 수 있다. 즉, if 조건문을 이용해서 (공격쿼리, 참(시간 발생), 거짓..

limit 에서 sql injection이 발생하는 특이한 구조이다. 설명은 아래 글을 참고하길 바란다. SQL Injection in MySQL LIMIT