낭만있는 컴퓨터와의 대담집 낭만있는 컴퓨터와의 대담집

normaltic / 1234 로 정상 로그인이 가능하며 post로 보낸다. 자세한 페이지 분석은 생략한다.SQL Injection 가능성 확인id에 normaltic' and '1'='1 , pass에 1234를 입력했는데도 정상 로그인이 되므로 SQL Injection이 가능하다고 판단된다.  Error 출력이 되는지 확인데이터 쿼리 결과가 출력되는 곳이 아니기 때문에 Union SQLi가 불가능하다. 그렇기 때문에 에러가 출력되는지 확인해서, 만약 그렇다면 Error Based SQLi를 실시한다. 확인해보기 위해 id에 normaltic' 을 삽입해서 문법 에러를 유발한다. /*예상 sql querySELECT * from member WHERE id='___' and pass='___'여기에 n..

목표: id 중복 검사를 하는 페이지에서 flag를 찾는 것이다.  실습 페이지기 때문에 Blind SQL Injection을 하면 되지만, 쿼리 결과가 출력되지 않기 때문에 Union sqli를 사용할 수 없으며, 에러가 발생하는지 확인해야한다. 물론 SQL Injection이 가능하다면 모든 곳에 Blind SQLi가 가능하지만 Error Based SQLi가 가능하다면 그것을 사용하는 것이 더욱 효율적이기 때문이다. 일단 id 중복 검사이기 때문에 select문에 where id가 있을 것이고 like 연산자는 사용되지 않았을 것이라고 추정한다. 물론 실습 사이트기 때문에 페이지 아래에 sql query문을 표시해주고 있지만 없다고 가정하더라도 충분히 추정가능하다.# SELECT id from me..

이번 wargame의 목표는 Error Based SQL Injection의 실습이다. 그래서 전체적인 웹페이지 분석은 생략한다. 다만 post로 query를 보내고 있다.     id 중복 검사를 하는 페이지다. select문을 쓸 것이고 like 연산자를 쓰지 않을 것이라고 추측할 수 있다. 친절하게 실행되는 질의문도 보여준다. 만약 아무 쿼리나 넣으면 존재하지 않는 아이디라고 나온다.  SQL Injection 가능성 확인normaltic'      을 삽입하면 에러 메시지가 출력된다.  normaltic' and '1'='1을 넣어도 존재하는 아이디라고 정상적으로 나오는 것을 보아 SQL Injection이 가능하다고 판단된다. SQL Injection을 이용한 flag 찾기1. 에러 출력 함수 ..

페이지 모습은 다음과 같다. 이번에도 검색 창이 존재하고, 검색 옵션은 User ID밖에 안된다. 다만 저번문제와 달리 아무 데이터도 초반에 보이지 않는다. 그러나 placeholder에 normaltic이 있는 것을 보아 이 아이디로 힌트를 준 것 같다. 먼저 normaltic을 검색해본다. get 방식으로 search=normaltic 처럼 담겨 전달된다. 이번에는 burp 캡쳐화면보다 브라우저가 많이 나올 것이다.ID에 normaltic이 나오고, Level, Rank Point는 필터처리되었으며, info에는 특정 데이터가 출력된다. 이제 sql 추측을 하기 위해 nor 을 삽입해서도 검색해본다. 그러나 아까와 달리 ID에는 nor이 나오고 Info에는 아무것도 출력되지 않은 것을 알 수 있다. ..

/sqli_1/ 에 접속하면 /sqli/search.php로 redirect 된다. 검색창에 존재하는 검색옵션은 User ID 밖에 없다. 지금 보이는 유저중에 mario를 검색해보겠다.검색 시 동일한 페이지에 get 방식으로 search=mario로 담아서 보낸다. 결과는 mario가 정상적으로 출력된다. 그러나 검색페이지 이기 때문에 select문에서 like 연산자를 쓸 가능성이 높기 때문에 mario 전체를 검색하지 않고 ma 만 검색해보겠다. 결과는 다음과 같이 mario도 정상출력 되었고 그 뿐 아니라 normaltic도 출력되었다. 따라서 추측 가능한 sql문은 다음과 같다.# SELECT * from member WHERE id like '%__%'SQL Injection 가능성 확인 여기..

이번에는 주어진 내용이 좀 다르다! 똑같이 doldol / dol1234 는 존재하지만 어떤 아이디로 로그인해야하는지가 나와있지 않다. 단순히 관리자 계정으로 로그인 하라고 되어있다. 물론 admin으로 가정하고 진행하는 것이 문제의 취지는 아닐 것이다.  그래서 일단 주어진 계정으로 먼저 로그인 하고 페이지를 살펴보려고 한다. 아래는 post 요청의 응답 데이터이다. 문제를 내신 분이 친절하게도 사용되는 sql문을 출력해서 보여주고 있다. 그러나 이것이 없더라도 문제풀이에 지장은 없다. 앞의 문제들에서 했던 것과 마찬가지로 다시 로그인 우회 인증이 되는지 확인을 해야한다. 로그인 우회 가능성 확인 이 데이터로 보내도 정상적으로 로그인이 되기 때문에 로그인 우회 가능성이 존재한다고 할 수 있다.참고로 친..

doldol / dol1234 으로 로그인 해서 burp로 살펴보겠다. 로그인 시 보내는 post 요청의 응답 헤더에 loginUser를 doldol로 쿠키설정을 하게 되어 있는 것을 볼 수 있다. 따라서 이것을 normaltic5로 변조해보려고 한다. 방법은 저 응답 자체를 변조해서 저장되는 것 자체를 바꿀 수도 있고, 그 다음에 쿠키를 요청에 담아서 보내는 것을 바꿀 수도 있다. 전자로 진행해보겠다. burp의 intercept를 활성화 시키고 로그인 버튼을 누른 뒤 Action 버튼에서 Do intercept -> Response to this request 를 눌러준다. 그 다음 Forward 버튼을 눌러 Response를 확인한다. Set-Cookie의 loginUser의 doldol을 norm..

목표와 주어진 데이터, 페이지 분석은 이전 글들에 충분히 서술되어 있기 때문에 따로 설명하지 않겠다. 또한 Login Bypass 3의 마지막 과정까지 동일하게 진행되다가 마지막에서 로그인 우회에 실패했으므로 그곳부터 다루도록 하겠다. 로그인 우회 식별/인증 분리 케이스이고 남은 경우는 다음과 같다./*식별/인증 분리 | 괄호없음 | 개행X | 해쉬O | '사용 SELECT id,pass from member WHERE id='___'식별/인증 분리 | 괄호있음 | 개행X | 해쉬X | '사용 SELECT id,pass from member WHERE (id='___')식별/인증 분리 | 괄호있음 | 개행X | 해쉬O | '사용 SELECT id,pass from member WHERE (id='___'..