소스코드 상에 var 변수와 관련하여 해결방안이 있을것 같음 check(x)함수는 사용자 입력값(x)을 받아와서 정답(RawrRawr)을 비교하는 함수 같다. 결론은 정답에 해당하는 변수(RawrRawr)의 값을 알아내야 하는데... 소스코드상에서 혹시 하드코딩되어 있는지 확인하기 위해 find 했더니... 다음과 같이 창을 오른쪽으로 쭉 넘기면 저기에 선언이되어있다....일부러 안보이게 해놓으려고 지금 저렇게 해놓은건가? ㅋㅋㅋ moo 입력 시, 문제 해결됨

보물 문제는 page 버튼 번호에 따라서 특정 값이 나오는 것을 확인할 수 있었다. 소스보기(F12)를 통해서 더 확인해 보자 별로 특별한 내용은 보이지 않고 button을 누르게 되면 action을 통해 각 번호에 해당하는 내용을 get 방식으로 불러오는듯 하다. 해서 해당 url의 page 파라미터에 4를 넣어보니 page=4에 대한 답이 나왔다. 9번까지 해보다가 파이썬 반복문을 활용해서 찾아보도록 하자. 간단한 반복문을 활용해서 HackCTF{라는 문자열이 나오면 그 해당 번호를 출력하게 작성하였다. flag 값이 1225번에 있다고 나온다. 그렇다면 실제로 들어있는지 확인보도록 하자. 이렇게 flag 값으로 HackCTF{0hhhhh_5o_g0od_try!}를 찾을 수 있었다.

이번 문제는 id와 pw를 입력받는 문제인데 where절에 id='{$_GET[id]}' and pw='{$_GET[pw]}'으로 들어간다. 문제는 두 파라미터가 '을 필터링을 하고 있는 것이 문제이다. 인터넷에 검색해본 결과 \를 사용하면 된다는 것을 알 수 있었다.만약 id 값이 ’ 것을 찾고 싶어서 쿼리문을 SELECT id FROM test WHERE id = '''로 작성하면 에러가 난다. 그 이유는 '를 문자로 인식하지 않기 때문이다. 이러한 문제 때문에 특수문자 예외처리를 해줘야하는데, 이것이 \이다. SELECT id FROM test WHERE id = '\''로 처리하게 되면 id가 '인 것을 찾는 쿼리문으로 된다. 이것을 이용하면, SELECT id FROM prob_succubus ..

해당 문제의 입력 파라미터는 pw 뿐이며, '를 필터링하고 있다. 또한 쿼리문을 보니, '' 안에 입력값이 들어가서 문제 해결에 어려움이 있을 것 같다. 결국 몇시간을 시도한 끝에 다른 사람의 문제풀이를 살펴보니 쿼리문에서 =를 대신 LIKE를 사용한 이유가 있었다. LIKE에선 약간의 정규식을 사용할 수 있다. 특정 문자% : 특정 문자로 시작 %특정 문자 : 특정 문자로 끝남 %특정 문자% : 특정 문자을 포함 위를 이용하여 pw를 찾으면 된다. import requests, string, itertools url = 'https://los.rubiya.kr/chall/assassin_14a1fd552c61c60f034879e5d4171373.php' headers = {'Cookie': 'PHPSE..

그동안 익숙했던 문제 스타일이 아닌 새로운 문제 스타일이 나왔다. 사이트에서 입력 받는 파라미터는 shit 하나이며, 이 파라미터는 from prob_giant의 사이에 들어가게 된다. shit의 필터링은 공백, \n, \r, \t이며, 입력 길이가 1보다 커서는 안된다. 나는 필터링 목록 대신에 사용할 만한 것을 생각하다가, addslashes 함수의 우회 방법이 생각이 났다. addslashes 함수의 우회 방법은 특정 인코딩 기법을 적용한 함수에 %01와 같이 의미가 없는 URL 인코딩 값을 넣어줌으로써 우회를 하는 방법이다. 이처럼 의미가 없는 URL 인코딩 값을 보내주면 될 것 같아서 %01를 서버에 보내봤다. 공백처리는 되었지만, 결과값을 반환하지 않고 있다. 인터넷에 검색하니, %01 ~ %..

AWS를 통한 웹 3-Tier Architecture를 구성하고 이에 따른 단계적 설정을 진행해보도록 하겠습니다. 최근엔 서버리스 Architecture를 구성해 서버나 트래픽을 분산처리 해주는 ELB 없이 많이 구축하는데 서버리스 Architecture는 이번 3-Tier 구성 완료 후에 다뤄볼까 합니다 :) 위의 그림은 기본적인 Web 3Tier Architecture 입니다. 데이터 흐름을 보자면, 외부에서 Client에 의해 Request가 들어오면 외부 ELB를 통해 웹서버로 로드밸런싱되고, 내부 ELB를 통해 WAS 서버를 거쳐 Database로 접근하는 흐름을 가집니다. 반대로 내부에 있는 서버가 외부와 통신할 경우 NAT Gateway를 통해 통신을 하게 됩니다. 해당 구조를 구성하기 위해..