Oh! JUN

1. 신뢰할 수 있는 웹사이트는 XSS 공격으로부터 안전합니까? 해결 방법 1: 예, 브라우저는 실행 전에 코드를 확인하므로 안전합니다. 해결 방법 2: 그렇습니다. Google에는 악성 코드를 차단하는 알고리즘이 있기 때문입니다. 해결 방법 3: 아니요. 실행되는 스크립트가 브라우저의 방어 알고리즘을 뚫기 때문입니다. 해결 방법 4: 아니요. 신뢰할 수 있는 것으로 확인된 경우 브라우저는 해당 웹 사이트를 신뢰하기 때문에 브라우저는 스크립트가 악성이라는 것을 알지 못합니다. 2. XSS 공격은 언제 발생합니까? 해결 방법 1: 데이터는 신뢰할 수 있는 소스를 통해 웹 애플리케이션에 입력됩니다. 해결 방법 2: 데이터는 웹사이트를 통해 브라우저 애플리케이션에 입력됩니다. 해결 방법 3: 악성 콘텐츠인지 ..

Try it! DOM 기반 XSS 일부 공격은 "블라인드"입니다. 다행히 여기에서 서버가 실행 중이므로 성공 여부를 알 수 있습니다. 방금 찾은 경로를 사용하고 WebGoat에서 내부 기능을 실행하기 위해 인코딩 없이 경로의 매개변수를 반영한다는 사실을 사용할 수 있는지 확인하세요. 실행하려는 기능은 ...​ webgoat.customjs.phoneHome() 물론 콘솔/디버그를 사용하여 트리거할 수 있지만 새 탭에서 URL을 통해 트리거해야 합니다. 일단 트리거하면 후속 응답이 임의의 숫자와 함께 브라우저 콘솔에 표시됩니다. 아래에 임의의 숫자를 입력하세요. 1. 콘솔 이전 문제 참고해서 http://127.0.0.1:5555/WebGoat/start.mvc#test/%3Cscript%3Ewebgoat..

DOM 기반 XSS의 잠재력 식별 DOM 기반 XSS는 일반적으로 클라이언트 측 코드에서 경로 구성을 검색하여 찾을 수 있습니다. 페이지에 "반영"되는 입력을 받는 경로를 찾으세요. 이 예에서는 경로 핸들러에서 일부 '테스트' 코드를 찾고 싶을 것입니다(WebGoat는 백본을 기본 JavaScript 라이브러리로 사용합니다). 때로는 테스트 코드가 프로덕션 환경에 남겨지는 경우도 있습니다(그리고 종종 테스트 코드가 매우 단순하고 보안이나 품질 관리가 부족합니다!). 당신의 목표는 경로를 찾아 활용하는 것입니다. 우선...​ 기본 경로는 무엇입니까? 예를 들어, 이 강의의 URL을 살펴보세요. /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9와 같은 형태여야 ..

Try It! Reflected XSS XSS에 취약한 필드 식별 항상 서버 측에서 모든 입력의 유효성을 검사하는 것이 좋습니다. XSS는 검증되지 않은 사용자 입력이 HTTP 응답에 사용될 때 발생할 수 있습니다. 반사된 XSS 공격에서 공격자는 공격 스크립트로 URL을 만들어 다른 웹사이트에 게시하거나 이메일로 보내거나 피해자가 클릭하도록 유도할 수 있습니다. 필드가 XSS 공격에 취약한지 확인하는 쉬운 방법은 Alert() 또는 console.log() 메서드를 사용하는 것입니다. 그 중 하나를 사용하여 어떤 필드가 취약한지 알아보세요. Enter your credit card number에 삽입해서 응답 값에 어떻게 찍히는지 확인해보겠습니다. 필터링 되는거 없이 잘 적용됩니다. 이번에는 Enter..

XSS란 무엇입니까? Cross-Site Scripting(일반적으로 XSS라고도 함)은 ...​# 인코딩이나 삭제 없이 브라우저에 렌더링되는 입력으로 html/script 태그 허용을 결합하는 취약점/결함입니다. XSS(교차 사이트 스크립팅)는 가장 널리 퍼져 있고 위험한 웹 애플리케이션 보안 문제입니다. 이 공격에 대한 간단하고 잘 알려진 방어 방법이 있지만 웹에는 여전히 많은 사례가 있습니다. 이를 수정하는 측면에서 수정 사항 적용 범위도 문제가 되는 경향이 있습니다. 수비에 대해서는 잠시 후에 더 이야기하겠습니다. XSS는 상당한 영향을 미칩니다 특히 '리치 인터넷 애플리케이션'이 점점 더 보편화됨에 따라 JavaScript를 통해 연결된 권한 있는 함수 호출이 손상될 수 있습니다. 그리고 적절하..