@6번문제

생각보다 오래걸렸다. 너무 쉽게봤는데(그렇다고 어려운문제는 아닌것 같다.)

시간이 걸리는 문제였다.



(6번 문제)




(문제 화면)



문제 화면을 보면
README 라는 3번 게시물은 패스워드를 입력해야 들어갈 수 있었고
나머지는 그냥 글 들이었다. (알고보니 힌트들, 아닌것도 있지만)

3번 비밀번호 입력하는 팝업창이 뜨고 친절하게 보내지는 쿼리도 보여준다.



(비밀번호 입력창)



Injection이라면 조금 자신있어서 신나게 풀었다.
먼저 입력이 string이다.
필터링 되는 단어를 확인해 본다.




(sql injection)





(결과)



결과를 보니 #이 필터링 되고 있었고 다른 주석으로 -- 을 사용했다.





(다른 주석 사용)




(노필터링)



필터링 되지 않고 쿼리가 날라갔다. 이제 주석은 --을 사용할 것이다.
보통 MySQL에서는 1이 참이라고 인식되던데 False가 나와
1=1(참)로 바꿔서 입력해주었다.




(=필터링)



= 이 필터링 되고있다..ㅎㅎ

=은 like, in 등으로 대체할 수 있다.
그 중 쉽게 like를 써보았다.



(like로 대체)






(문제 해결?)



문제가 해결되었다.

뭔가 싱거운 기분이 들었다. 이게뭐야

하지만 지금부터 시작이라는걸 알았다.
이 인증키를 답에 입력해보니...



(틀림)



틀린다고 나온다. 답이 아니다...
뭐야..

아까 비밀번호 인증 성공 후 아래와 같은 팝업창이 떳었는데..




(접근 제어)



이 팝업창을 무시했었는데 아무래도 여기에 문제가 있었나보다.

접근 권한을 어디서 체크하겠는가. Cookie 값 혹은 SesssionID로 체크하니까

현재 cookie를 살펴보았다.




(쿠키값)



세션아이디도 있고, 인증키?도 적혀있다.
세션아이디는 아무래도 아이디 관련이 있는 거 같고
auth%5Fkey가 지금 제어당하고 있는 값인거 같다.




(인증키 설정)



인증키를 설정해준다! 아까 받았던거로
그러니 당연하다듯이 실패...

여기서 인증키를 변환해주어야한다

게시물중에 참조하라는 게시물이 있는데 그 게시물에 인코더 사이트가 들어있다.
인증키를 Encode해서 입력하라는 뜻인거 같다.
종류는 모르고...




(Base64로 인코딩)






(인증키 설정)



Base64부터 시작하여 저기 있는 방법으로 모두 해보았다.
그 결과 안된다.
심지어 저기 없는 방식으로도 했다. 다른 Encoder사이트 참조
안된다.

이유를 잘보니 키 인증값이 자꾸 %3F로 재설정된다.
그니까 넘겨줄때마다 계속 인증키를 다시 설정해야하는 것이었다.

그래서 여기서.. 툴을 쓰기로 했다:)
버프슈트를 이용해 인증키 변조
그리고 처음부터 다시시작(Base64부터...)

모든 인코딩을 해서 해본 결과 하나가 되긴한다.. :)




(인증키 변조)



성공하니 README의 게시물이 열렸다.




(게시물 오픈)



키를 찾으세요! 라는 문제가있다.

소스코드에 있나 하고 소스코드를 열어보았다.




(문제?)



이상한 action이 있는 form을 발견했다. 키 힌트가 로마의 첫번째 황제?

Rome's First Emperor 를 그대로 인터넷에 검색했다.
이게 답맞나... 싶었지만



(정답)



정답이었다..
:)


'WarGame > SuNiNaTaS' 카테고리의 다른 글

SuNiNaTaS : Challenge WEB 22  (0) 2017.03.29
SuNiNaTaS : Challenge WEB 8  (0) 2017.03.29
SuNiNaTaS : Challenge WEB 5  (0) 2017.03.27
SuNiNaTaS : Challenge WEB 4  (2) 2017.03.23
SuNiNaTaS : Challenge WEB 3  (0) 2017.03.22



저번에 이어서 세션 이야기를 마무리해보겠다.

세션을 사용하려면 페이지 시작할 때 session_start()를 넣어준다.

세션을 이용해 간단한 인증을 해볼것이다.
세션인증을 위한 세션값을 만들어야하는데
islogin 값으로 아이디와 비밀번호를 연결해 해쉬값으로 저장하고
name 값으로 아이디를 저장했다.



(세션인증값 설정)



로그인 해보겠다.



(로그인)





(세션 확인)



로그인 후 세션쿠키값을 확인 할 수 있다.
하지만
세션값으로 우리는 알아낼 수 없다.
세션 쿠키값에 저장된 값들은 서버에 있기 때문이다!

그렇다면 서버에 가서 세션에 우리가 설정해 놓은 값이 잘 저장되었는지 확인해 보겠다.



(세션값 확인)



우리가 설정한 대로 해쉬값과 아이디 값이 보인다.

그러면 전에 쿠키값을 이용한 간단한 인증을 한 것 처럼
세션도 똑같이 해보겠다.
DB를 지금은 다루지 않을 것이므로
간단하게 세션값이 있으면 인증을 성공시켜 줄 것이다.



(인증 코드)




(인증 성공)




그렇다면
세션값을 어떻게 파기 시킬까?
세션 값은 세션이 종료되면, 즉 웹브라우저가 닫히면 세션값이 파기된다.

그렇지 않고
웹 브라우저가 켜진 상태에서 세션값을 파기하려면??
session_dstroy() 함수가 php에 있다. (사용해보겠다.)



(session_destroy() 사용)




사용 후 확인해보니..



(세션 파일 존재)




세션 파일이 존재한다.
그 세션파일에 들어가보니 내용은 전부 사라져있다.

즉 파기할 때 session_destroy()만 사용하면 세션 파일은 사라지지 않고
그 세션 파일에 저장된 값들이 지워지는 것이다.

그렇다면 세션 파일까지 지워주려면?
쿠키값을 제거할 때랑 똑같다.



(세션파일 삭제)




즉 세션을 파기하려면
세션 내용도 지워줘야하지만 세션 쿠키도 지워주어야 한다.




웹 서버에서
사용자들을 어떻게 인증할까?

* 웹에서의 인증 특징
 - TCP통신을 한다. 일반적인 인증과 동일하게 진행할 수도 있다.
 - 웹의 특성상 세션을 유지하지 않는다.
 - 웹 서버 어플리케이션은 사용자 인증을 위한 인증 토큰을 발행한다.

인증 토큰에는 두가지가 있다.
1. 쿠키 (Cookie)
-> 보안에 취약하다.
-> 사용자 정보가 로컬 컴퓨터에 남는다.

2. 세션 (Session)
-> 쿠키의 보안 취약점을 개선하기 위해 나온 것이 세션이다.

그렇다면 이러한 인증 과정을 직접 확인해보겠다.
먼저 간단한 웹 인증페이지를 만들어 볼것이다.

auth 폴더를 따로 만들어서 여기서 작업을 하겠다.



(auth 폴더 생성)



vi 편집기를 이용해 login.php 파일을 작성한다.
#> vi login.php



(login.php)



간단하게 아이디와 비밀번호를 입력 받아
login_ok.php 파일에 전송해주는 페이지이다.



(페이지 모습)



그렇다면 이제 login_ok.php 파일을 만들어서
인증 과정을 만들어볼 것이다.

아직 DB를 손데지 않고 간단히 연관배열을 사용하여 인증을 해보겠다.

연관 배열 사용 테스트이다.
user1 ~ 3을 만들고 해당 비밀번호를 연관 배열로 설정한다.
그리고 입력받은 아이디의 비밀번호를 화면에 출력해보겠다. (테스트)



(login_ok.php)



이제 잘 동작하는지 체크해보겠다.
실행



(아이디 user1 입력)




(실행화면)



실행 화면에 user1의 비밀번호가 잘 출력된 것을 확인 할 수 있다.

이제 이 것을 사용하여 인증을 해보겠다.
php 언어에서 array_key_exists 함수를 사용해 해당 아이디에 관해 연관배열의 값이 있는지 체크하고
있다면 비밀번호가 입력받은 것과 일치하는지 체크해서 인증을 하겠다.



(login_ok.php)



결과 인증에 성공하면
로그인 성공이라고 팝업창을 띄우고
실패하면 실패라고 팝업창을 띄우는 script를 추가했다.

실행해서 확인해보겠다.



(접속)




(로그인 성공)






(로그인 실패)



비밀번호를 올바르게 입력했을 때 success가 뜨고
실패했을 때는 fail이라고 잘 떴다.

로그인 인증까지 확인했으니
이제 토큰 방법 중 하나로 쿠키를 사용해보겠다.
인증에 성공했을 경우에
쿠키를 추가해주는 코드를 추가해줄 것이다.
쿠키 설정 php 언어
setcookie("쿠키이름", "쿠키에 넣을 값", 유효기간, 쿠키값이 적용될 영역)
하나는 user_id의 쿠키 변수에 id를 그대로 사용했고
session_id 쿠키 변수에는 ID와 비밀번호를 연결해 해쉬함수로 바꾸어서 사용했다.



(쿠키 생성)




login.php 페이지에서
쿠키 값을 출력해보겠다. (쿠키값이 잘 설정되는지 확인하기 위하여)



(쿠키값 확인 코드)





실행



(실행 화면)




실행 화면을 보니 위에 우리가 설정해준 쿠키값이 잘 저장되 있는 것을 확인 할 수 있다.

F12 키를 눌러 관리자 모드에서 네트워크 부분으로 어떤 통신을 주고 받는지 확인 할 수 있는데
여기서 응답으로 쿠키 값을 보내준 것을 확인 할 수 있다.




(쿠키값 전달(응답))




혹은
관리자 모드에서 Console창에서도 확인 할 수 있다.
document.cookie
를 입력하면 나온다.


(저장된 쿠키값)




이제 이 쿠키값으로 인증을 해보겠다.
사실 이 쿠키값을 비교하여 일치하면 인증을 해주는 방식인데
우리는 여기서 간단하게 해보겠다.! ㅎㅎ
간단하게
쿠키값이 저장되어있다면!
로그인 을 해주도록 할 것이다.



(인증 코드 추가)





그렇게 하여 인증이 되면 해당 ID를 불러와 Welcome 페이지를 보여주고
인증이 안되었으면 로그인하는 페이지가 보이도록 하였다.

인증에 성공하면 아래와 같이 나온다.




(인증 성공)





(Console에서 확인)




콘솔에서도 확인 할 수 있다.

이렇게 편하고 좋은 쿠키가 보안에는 취약할 수 있다.
쿠키가 로컬 컴퓨터에 그대로 저장되기 때문에
만약 쿠키값으로 ID 혹은 패스워드를 그대로 사용하면
굉장히 위험하게 된다.

윈도우 IE에서 쿠키 값을 저장하는 곳을 확인해보겠다.
인터넷 옵션에 들어간다. 그 후 설정을 눌러준다.




(설정 클릭)




여기서 아래의 표시된 부분이
쿠키값이 저장되는 부분이다.




(쿠키 위치)




파일 보기를 누르면 해당 폴더가 열린다.




(쿠키 파일)





여기에는 쿠키파일 뿐 아니라 인터넷 임시 파일들도 저장되어 있다.

한번 로그인하여 우리의 소중한 쿠키가 어떻게 저장되는지 확인해 볼 것 이다.




(로그인)





(성공)



해당 폴더에 들어가서 확인해보니 우리가 방금 얻어온 쿠키값이 그대로 저장되 있는 것을
확인할 수 있다.



(쿠키값 파일)




이제 로그아웃 링크를 하나 만들어주어 쿠키값을 없애보도록 할 것이다.
만약 이 기능이 없다면
로그인이 한번 되면 적어도 하루 동안은 그 페이지 로그인 페이지를 볼 수 없다...

로그아웃 기능 추가!



(링크추가)



로그아웃에 하이퍼링크로 logout.php 페이지를 입력해놓았다.
우리는 logout.php 페이지에서 logout을 해줄 것이다.



(logout.php 파일 생성)




쿠키를 지우는 방법은 아까 setcookie 함수를 사용했던 것과 같다.
다만 쿠키값을 "" 빈 채로 설정하는 것이다.




(logout.php 코드)




다시 화면에 가보면 logout 링크가 되있는 것을 볼 수 있다.




(logout 추가)




버튼을 누르면
다시 login.php 페이지에서 로그인 화면을 볼 수 있다.




(로그인 페이지)




두 번째 토큰 방법으로 session이 있다.
이 session은 브라우저가 열려있을 때만 유효하고
닫히게 되면 session이 사라지는 특징이 있다.

중요한 특징은
서버에 저장된다는 것이다. (그렇기에 쿠키에 비해 안전하다고 할 수 있다.)

login_ok.php 파일에서
아까 만든 쿠키 설정은 주석으로 처리해 두고
세션 값을 설정해주겠다.
방법은
session_start();
를 입력하는 것이다.



(세션 추가 코드)




페이지에 접속하자마자 세션ID 쿠키를 만들어 준다.
바로 이게 session_start() 가 하는 일이다.

이 값을 확인해 보겠다.




(세션ID값 확인)




(콘솔에서 확인)



물론 콘솔에서도 확인 할 수 있다.

이 값은 아까 서버에 저장된다고 했었는데
그 위치는
/var/lib/php/session/ 에 파일로 존재하게 된다.
그렇기에 아까 확인했던 값이 파일 이름형태로
저장되있는 것을 확인 할 수 있다.



(세션 ID 위치)




세션ID가 설정되어있는 것 까지 확인했다.
이제 다음에
이 세션ID에 인증내용을 추가하는 기능을 만들어 확인하겠다.





Wechall 이라는 워게임 사이트가 있다.

여기서 여러 문제를 해결하면서 실력을 쌓을 수 있다.

오늘 풀이를 할 문제는 Coding 카테고리의 Training이다.



(Training: Programing 1 선택)



초록색으로 표시된 이유는 내가 한번 풀었기 때문에
초록색으로 표시된 것이다.

들어가보면



(문제화면)



문제를 보면 this link를 들어가서 받은 메세지를 다시 보내라는 뜻이다.

일단 this link에 들어가보자



(메세지)



메세지가 보인다.
이 메세지를 다시 보내라는 것이다.
어디로?

아래 드래그한 주소로!


(솔루션 보낼 곳)


뒤에 the_message부분에 우리가 받은 코드를 입력해서 전송하면 된다.

물론 시간제한이 1.337초 이므로 손으로는 불가능하며
네트워크 통신도 원활해야한다...

먼저 파이썬 챌린지에서 했던 urllib.request를 이용해 접근해보겠다.!




(??..)



url로 접속하니 로그인을 한 후
해당 쿠키로 접속을 해달라고 메세지가 왔다.

즉, 그냥 url만 보내면 안되고
접속했을 때의 쿠키값을 HTTP 헤더에 포함시켜서 보내야하는 것이다.!

와이어샤크로 나의 쿠키값을 확인해보겠다.



(쿠키값 확인)



와이어샤크로
나의 쿠키값을 확인 할 수 있다.

이제 이 값을 포함시켜서 url접속할 것이다.



(쿠키 추가)



쿠키를 추가한 모습이다.
그리고 code에 decode하여 우리가 원하는 문자열을 받았다.



(결과화면)



우리가 보내야할 코드가 잘 전달 되었다 :)

이제~ 이 값을 url 뒤에 붙여서 전송할것이다.



(답 전송)



전송 하고나서 수신된 메세지는 텍스트로 오기때문에 읽기가 힘들다...
그래서
와이어샤크로 확인을 해야한다.
와이어샤크로 확인!


(..?)



정답이다! 하지만,, timeout... 1.63초로..
현재 카페에서 하고있어서 빠르지 못했나보다..

다시 여러번의 시도를 한 후에야 통과했다. ( 네트워크가 빠른 곳에서 하는걸 추천한다.)



(정답화면)



나는 이미 한번 풀었기 때문에
이미 풀었던 문제라고 메세지가 돌아왔다.

문제 해결!


'WarGame > WeChall' 카테고리의 다른 글

WeChall - (Training) Prime Factory  (0) 2017.02.13

+ Recent posts