P0l4ris

#Main

 - 아무리 눌러도 반응이 없어서 프록시로 잡아보기로 했다.

프록시 : 본문에서는 클라이언트가 서버에게 보내는 값을 가로채서 수정하는 용도로 사용하였다.

참고 : https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84

#Burp suite

#button에 button값을 넘겨주는데 플래그를 출력하게 해달라고 했으니 'flag'를 집어넣어 보자.

#end

#Main

#번호들 클릭

 - 1번부터 4번까지 모두 Nop을 출력한다.

 - URL을 보니 get 방식으로 호출함을 알 수 있다.

#5번 파일에 플래그가 있다고 했으니 파라미터에 5를 삽입해보자.

#Main

#Robots.txt경로 탐색

 - 경로가 하나 출력되었다.

User-agent: *  ---> 모든 로봇

Disallow : /robot_flag/  ---> "/robot_flag/" 경로에 접근을 제한 

 즉, `모든 로봇은 "/robot_flag/" 경로에 접근을 제한한다.` 가 페이지가 의미하는 내용이다.

 Robots.txt란?

 -> 웹 사이트에 로봇(봇)이 접근하는 것을 방지하기 위한 프로토콜을 사용하는데, 이에 대한 접근제한에 대한 설명 기술

- 출처 -

https://ko.wikipedia.org/wiki/%EB%A1%9C%EB%B4%87_%EB%B0%B0%EC%A0%9C_%ED%91%9C%EC%A4%80

#/robot_flag/로 접속

 - 해석

해보자 다른 사용자의 로그인 자격 증명이 포함 된 요청을 보내려면 "로그인"버튼을 클릭하십시오.

그런 다음 이러한 자격 증명을 적절한 필드에 쓰고 확인을 위해 제출합니다.

패킷 스니퍼를 사용하여 요청을 가로 채십시오.

#패킷스니퍼(Burp Suite) 사용

#end

#XSS - Cross Site Script

 -> CSS가 맞지만 이미 CSS(Cascading Sytle Sheets)가 존재해서 XSS가 되었다.

 -> 서버에 프로그램이 코딩되어 있지만, 실행은 클라이언트에서 하기 때문에

     동작주체가 클라이언트로 넘어오게 된다.

 -> 발생하는 위치 : 클라이언트의 입력창, http header, 사용자의 응답 등

#XSS 취약점 판단

 -> 아무 스크립트 코드(ex:Java Script)나 넣었을 때, 스크립트가 정상적으로 작동하면

     취약점이 존재하는 것.

 -> 단순 필터링 우회 : ex ) <script> 필터링

  --> <scr<script>ipt> / <src+ipt> 등으로 우회가 가능하다.

#7) Reflected XSS

- 해석

XSS에 취약한 필드 식별 항상 서버 측에서 모든 입력의 유효성을 검사하는 것이 좋습니다.

XSS는 확인되지 않은 사용자 입력이 HTTP 응답에 사용될 때 발생할 수 있습니다.

반사 된 XSS 공격에서 공격자는 공격 스크립트를 사용하여 URL을 만들어 다른 웹 사이트에 게시하거나

이메일을 보내거나 피해자가 클릭하도록 할 수 있습니다.

필드가 XSS 공격에 취약한 지 확인하는 쉬운 방법은 alert () 또는 console.log () 메소드를 사용하는 것입니다.

그중 하나를 사용하여 취약한 분야를 찾으십시오.

#end / alert 삽입

 - <script>alert("hi")</script>

  -> 'hi'라는 메세지박스를 출력하는 스크립트 코드

 - 스크립트 코드를 넣으니까 문제가 해결되었다.

#10) Identify potential for DOM-Based XSS

- 해석

DOM 기반 XSS의 잠재력 파악 DOM 기반 XSS는 일반적으로 클라이언트 측 코드에서

경로 구성을 검색하여 찾을 수 있습니다.

페이지에 "반영되는"입력을받는 경로를 찾으십시오.

이 예제에서는 경로 핸들러에서 '테스트'코드를 찾고 싶을 것입니다

(WebGoat는 백본을 기본 JavaScript 라이브러리로 사용).

때로는 테스트 코드가 프로덕션에 남아 있습니다

(그리고 종종 테스트 코드는 매우 간단하고 보안이나 품질 관리가 부족합니다!).

당신의 목표는 경로를 찾아 그것을 활용하는 것입니다.

우선… 기본 경로는 무엇입니까? 예를 들어,이 강의의 URL을보십시오.… /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9와 같은 형식이어야합니다.

이 경우 '기본 경로'는 다음과 같습니다.

start.mvc # lesson / CrossSiteScripting.lesson / 9는 JavaScript 경로 처리기에 의해 처리되는 매개 변수입니다.

그렇다면 프로덕션 중에 앱에 남아있는 테스트 코드의 경로는 무엇입니까?

이 질문에 답하려면 JavaScript 소스를 확인해야합니다.

 - 경로 처리기를 찾아야 한다고 말한다.

 - mvc를 언급하는 것으로 보아 mvc와 관련이 있어 보인다.

#mvc(Model View Controller)

출저 : https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8-%EB%B7%B0-%EC%BB%A8%ED%8A%B8%EB%A1%A4%EB%9F%AC

 - Model : 무엇을 할지 결정. 로직처리(알고리즘, DataBase와의 상호작용 데이터 등)

 - Controller : 앞의 모델이 어떻게 처리할지 결정

 - View : 화면의 출력을 담당. Model과 Controller로 인한 것을 출력함.

출저 : https://medium.com/@jang.wangsu/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-mvc-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80-1d74fac6e256

#mvc route

 -> 쉽게 설명하면 경로를 찾는 것인데, mvc와 route에 대해서는 다른 글에서 더 자세하게 다룰 예정

 -> start.mvc # lesson / CrossSiteScripting.lesson / 9는 JavaScript 경로 처리기에 의해 처리되는 매개 변수

  --> 부분에서 테스트코드의 경로를 찾으라고 했으므로, test route를 찾아야 하는 것임을 알 수 있다.

#mvc 요소 중에서 획득

 - test/:param이 testRoute임을 명시해주는 코드를 획득할 수 있었다.

#test 경로 확인

 - start.mvc#test/ 부분에서 XSS취약점이 발생하는 것을 확인하였다.

#end

#11) Try It! DOM-Based XSS

 - 해석

시도 해봐! DOM 기반 XSS
일부 공격은 '블라인드'입니다. 다행히 여기에서 서버를 실행하고 있으므로 성공했는지 알 수 있습니다. 방금 찾은 경로를 사용하고 인코딩없이 경로의 매개 변수를 반영한다는 사실을 사용하여 WebGoat에서 내부 기능을 실행할 수 있는지 확인하십시오. 실행하고자하는 기능은…

DOM 기반 XSS 실습입니다.
일부 공격들은 성공 여부를 확인할 수 없다 (blind). 그러나 운 좋게도 당신은 스스로 서버를 구동하고 있으므로 성공 여부를 확인할 수 있습니다. 당신이 금방 전 확인한 경로를 이용하여, 경로 내에서 값이 있고 필터링하여 발생하여, WebGoat 내 특정 함수가 있는지 확인하라. 당신이 할 함수는 같다.

webgoat.customjs.phoneHome ()

물론, 콘솔 / 디버그를 사용하여 트리거 할 수 있지만 새 탭의 URL을 통해 트리거해야합니다.
당연히 당신은이 이벤트를 콘솔이나 디버그를 호출 할 수 있습니다. 많은, 새 탭의 URL을 통해 호출 시도십시오.
트리거를 실행하면 후속 응답이 임의의 숫자로 브라우저 콘솔에 표시됩니다. 그 난수를 아래에 넣으십시오.
이 함수가 호출되면 임의 번호가 당신의 브라우저의 콘솔에 출력 될 것입니다. 아래 폼에 그 번호를 삽입하십시오.

#제공받은 함수로 10번문제에서 획득한 test경로에 스크립트를 작동시키자.

  - 콘솔을 확인하면 난수가 생성된 것을 확인할 수 있다.

#end

 - 난수이므로 그대로 갖고가셔도 문제가 풀리지 않습니다

#12

 - 이 할당에서 ORDER BY 필드를 통해 SQL 주입을 수행하십시오. webgoat-prd 서버의 IP 주소를 찾으십시오. 전체 IP       주소는 너무 오래 걸릴 수 있으므로 마지막 부분 인 xxx.130.219.202를 제공합니다.

 - 참고 :이 할당의 제출 필드는 SQL 주입에 취약하지 않습니다.

#제출필드는 sql을 쓰는것이 아닌 것 같다. 버프슈트로 잡아서 요청값을 보자.

 -  hostname을 GET방식으로 인자 전달을 하는 것을 확인했다.

#test 테이블 존재여부 검사

 - (case+when+exists(select+ip+from+test+where+hostname%3d'webgoat-prd')+then+ip+eles+id+end)

  -> test 테이블에서 ip 컬럼에 hostname이 'webgoat-prd'가 있으면 ip기준으로 정렬, 없으면 id 기준으로 정렬

 - 500에러(서버내부에러)가 출력되는 것을 보아, test테이블이 존재하지 않는다.

 - 좌측 상단에 인자가 servers?column= 인 것으로 보아 servers 테이블인 것 같다.

#servers 테이블로 수정

 - ip기준으로 잘 정렬된 것을 볼 수 있다.

#webgoat-prd가 servers 테이블에 존재한다는 것을 알았지만, 출력은 되지 않는다.

#유효성 검사를 위해 sql문을 사용하여 반응을 유도하자.

 - (case+when+exists(select+ip+from+servers+where+hostname+=+'webgoat-                                                      prd'+and+substring(ip,1,1)='1')+then+ip+else+id+end)

  -> 해당 sql문을 사용하여, webgoat-prd의 ip 첫째자리부터 검사하여 반응을 유도한다,

 - 해당 사진은 1번째 자리가 '1'이 맞아서 ip기준으로 정렬된 모습이다.

 - 문제에서 앞 세자리만 구하라고 했으므로, 30번 안으로 답을 구할 수 있다.

#end

#POST 나 GET방식을 판단해야 하므로 버프슈트로 포워드값을 잡아보자.

 - 상단에 POST와 하단에 magic_num이 보인다.

#end

#별점을 클릭하니 login이 필요하다고 한다.

#버프슈트 사용

 - 실패한 쿼리가 나온다.

++ 로그인 시도를 위해 페이지 분석, 쿼리 분석을 해보았으나 모두 실패..

#서버가 처리할 수 있는 요청방식 확인

 - GET을 OPTIONS로 변경하여 보내면 서버가 허용하는 메소드가 출력된다.

   OPTIONS와 GET은 이미 응답을 알고 있으므로, HEAD로 바꿔서 요청해보자.

#end

#Without password

# ' (쿼터) 입력 확인

 - 쿼터가 들어가긴 하지만, 모종의 이유로 문자로 들어간다.

#버프슈트 확인

 - 패스워드 부분에 '를 넣으니 내부에러가 발생한다. 

#내부 에러 분석

 - 쿼리 형식이 보인다.

#SQL INJECTION

 - 형식에 맞춰 sqli를 써주면 성공

   -> 1'or'1'='1

   --> 1 또는 1=1 일때, 참이다.

# ' 기호를 넣어서 injection이 먹히는지 본다.

 - 다른 기호들도 넣어봤지만 별다른 변화가 없다.

  -> 블라인드 sqli로 풀어볼려고 했지만 응답형식이 같아서 실패

#뭔가 다른 그림

 - 페이지 좌측상단의 그림과 로그인 그림이 뭔가 다르다. 마치 뜯어달라는 것처럼

   하얀 여백도 존재한다. 

#파일 다운로드

 - 별다른 이상은 안보이니 HxD에 넣어서 메타데이터를 보자.

#HxD

 - 파일 안에 잘 숨겨져 있는 것을 확인했다.