To comply with the rule, in this write up, some hints related to this challenge only will be mentioned.
룰을 준수하기 위해, 여기서는 챌린지와과 관련된 몇 가지 힌트만이 언급됩니다.
Identify Potential for DOM-Based XSS
DOM-Based XSS can usually be found by looking for the route configurations in the client-side code. Look for a route that takes inputs that are being 'reflected' to the page.
DOM 기반 XSS 공격이 발생할 가능성 식별.
DOM 기반 XSS 공격은, 일반적으로 클라이언트 측 코드의 경로(URL) 설정과 관련하여 발견되곤 한다. 사용자의 화면에 입력 값이 반영되는(보이는) 웹페이지들을 찾는 것으로부터 공격 가능성을 점검할 수 있다.
For this example, you’ll want to look for some 'test' code in the route handlers (WebGoat uses backbone as its primary javascript library). Sometimes, test code gets left in production (and often times test code is very simple and lacks security or any quality controls!).
이번 예시에서는, 당신은 어떤 테스트용 코드를 확인하고 싶다고 가정한다(참고로, WebGoat는 backbone.js를 주가 되는 자바스크립트 라이브러리로 사용한다.). 때로는 테스트 코드가 소프트웨어 개발 시에 (지우지 않고) 남겨지는 경우도 있다(그리고 때로는 테스트 코드는 간단해 보이지만 보안에 취약할 수 있다.).
Your objective is to find the route and exploit it. First though … what is the base route? As an example, look at the URL for this lesson … it should look something like /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9. The 'base route' in this case is: start.mvc#lesson/ The CrossSiteScripting.lesson/9 after that are parameters that are processed by the javascript route handler.
당신의 목표는 해당 (테스트 코드가 있는) 경로를 찾아 그것을 악용하는 것이다. 이와 관련하여 최초로 시작할 부분은, 해당 코드의 기본 경로가 무엇인지 찾는 것이다. 예를 들어, 현재 페이지의 URL를 보라. 이렇게 적혀 있을 것이다. /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9. 여기서의 기본 경로는 "/WebGoat/start.mvc#lesson"이다. 우측에 붙은 "CrossSiteScripting.lesson/9"는 자바스크립트 라우트 핸들러에 의해 처리되는 파라미터이다.
So, what is the route for the test code that stayed in the app during production? To answer this question, you have to check the javascript source.
자 이제, 소프트웨어 개발 중 이 애플리케이션에 남겨진 테스트 코드의 경로가 무엇인지 찾아 제출하라. 이를 위해서는 자바스크립트 코드를 열어볼 필요가 있다.
DOM-Based XSS can usually be found by looking for the route configurations in the client-side code. Look for a route that takes inputs that are being 'reflected' to the page.
DOM 기반 XSS 공격이 발생할 가능성 식별.
DOM 기반 XSS 공격은, 일반적으로 클라이언트 측 코드의 경로(URL) 설정과 관련하여 발견되곤 한다. 사용자의 화면에 입력 값이 반영되는(보이는) 웹페이지들을 찾는 것으로부터 공격 가능성을 점검할 수 있다.
For this example, you’ll want to look for some 'test' code in the route handlers (WebGoat uses backbone as its primary javascript library). Sometimes, test code gets left in production (and often times test code is very simple and lacks security or any quality controls!).
이번 예시에서는, 당신은 어떤 테스트용 코드를 확인하고 싶다고 가정한다(참고로, WebGoat는 backbone.js를 주가 되는 자바스크립트 라이브러리로 사용한다.). 때로는 테스트 코드가 소프트웨어 개발 시에 (지우지 않고) 남겨지는 경우도 있다(그리고 때로는 테스트 코드는 간단해 보이지만 보안에 취약할 수 있다.).
Your objective is to find the route and exploit it. First though … what is the base route? As an example, look at the URL for this lesson … it should look something like /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9. The 'base route' in this case is: start.mvc#lesson/ The CrossSiteScripting.lesson/9 after that are parameters that are processed by the javascript route handler.
당신의 목표는 해당 (테스트 코드가 있는) 경로를 찾아 그것을 악용하는 것이다. 이와 관련하여 최초로 시작할 부분은, 해당 코드의 기본 경로가 무엇인지 찾는 것이다. 예를 들어, 현재 페이지의 URL를 보라. 이렇게 적혀 있을 것이다. /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9. 여기서의 기본 경로는 "/WebGoat/start.mvc#lesson"이다. 우측에 붙은 "CrossSiteScripting.lesson/9"는 자바스크립트 라우트 핸들러에 의해 처리되는 파라미터이다.
So, what is the route for the test code that stayed in the app during production? To answer this question, you have to check the javascript source.
자 이제, 소프트웨어 개발 중 이 애플리케이션에 남겨진 테스트 코드의 경로가 무엇인지 찾아 제출하라. 이를 위해서는 자바스크립트 코드를 열어볼 필요가 있다.
In the context, "lesson/~" is thought to be the route associated with each lesson page, and "test/~" is thought to be the route associated with the test page.
문맥상 "lesson/~"은 각 레슨 페이지와 연결될 때의 경로일 것으로 추정되고, "test/~"는 테스트와 페이지와 관련된 경로일 것으로 추정된다.
