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를 통해 연결된 권한 있는 함수 호출이 손상될 수 있습니다. 그리고 적절하..

그냥 시도 해 봐 이전 페이지에서 언급했듯이 때때로 앱은 클라이언트 컨트롤에 의존합니다. 액세스를 제어합니다(모호함). 눈에 보이는 링크가 없는 항목을 찾으면 시도해 보고 무슨 일이 일어나는지 확인하세요. 예, 그렇게 간단할 수 있습니다! 사용자 정보 수집 SQL 주입과 같은 취약점으로 인해 데이터 덤프가 발생하는 경우가 많지만 액세스 제어가 부족하거나 부족하여 발생할 수도 있습니다. 이를 얻으려면 여러 단계와 여러 번의 시도가 필요할 수 있습니다. 댓글, 유출된 정보에 주의하세요. 추측해야 할 것입니다. 도중에 다른 브라우저/계정을 사용해야 할 수도 있습니다. 정보부터 시작하세요. 사용자 목록을 가져온 다음 자신의 사용자 계정에 '해시'를 제공할 수 있는지 확인하기 위해 이미 (숨겨진 메뉴 항목)을 수..

모호성에 의존 사용자가 일반적으로 액세스하지 않는 링크를 숨기기 위해 HTML, CSS 또는 자바스크립트에 의존하는 경우. 조금 오래된 내용이지만 네트워크 라우터가 UI에서 자바스크립트로 관리 기능을 보호(숨기기)하려는 경우가 있었습니다 숨겨진 항목 찾기 일반적으로 UI가 공개적으로 노출하지 않는 기능을 찾는 힌트가 있습니다.​ #HTML 또는 자바스크립트 주석 #주석 처리된 요소 #CSS 컨트롤/클래스를 통해 숨겨진 항목 당신의 임무 아래 메뉴에 표시되지 않지만 공격자/악의적인 사용자가 관심을 가질 만한 두 개의 메뉴 항목을 찾아 해당 메뉴 항목에 대한 레이블을 지정합니다(현재 메뉴에는 링크가 없습니다). burp 잡아서 hidden-menu-item CSS 속성 삭제해서 response 해주니까 Ad..

패턴을 가지고 놀기 다른 프로필 보기 자신의 프로필을 보는 데 이미 사용한 대체 경로를 사용하여 다른 사람의 프로필을 봅니다. '프로필 보기' 버튼을 사용하여 다른 프로필 보기 요청을 차단/수정하세요. 또는 브라우저에서 수동 GET 요청을 사용할 수도 있습니다. 다른 프로필 편집 이전 앱은 다른 패턴을 따를 수 있지만 RESTful 앱(여기서 설명하는 내용)은 종종 다른 기능을 수행하기 위해 메서드를 변경하고 본문을 포함할지 여부를 변경합니다. 해당 지식을 사용하여 동일한 기본 요청을 받고 해당 요청의 메서드, 경로 및 본문(페이로드)을 변경하여 다른 사용자(Buffalo Bill)의 프로필을 수정합니다. 역할을 더 낮은 것으로 변경합니다(권한이 높은 역할과 사용자는 일반적으로 숫자가 낮기 때문). 또한..