Oh! JUN

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)의 프로필을 수정합니다. 역할을 더 낮은 것으로 변경합니다(권한이 높은 역할과 사용자는 일반적으로 숫자가 낮기 때문). 또한..

추측 및 예측 패턴 자신의 프로필을 다른 방법으로 보기 우리가 작업 중인 애플리케이션은 프로필에 관한 한 RESTful 패턴을 따르는 것 같습니다. 많은 앱에는 승격된 사용자가 다른 사용자의 콘텐츠에 액세스할 수 있는 역할이 있습니다. 이 경우에는 자신의 사용자 세션/인증 데이터에서 보고 싶은 프로필이 누구인지 알려주지 않기 때문에 /profile만으로는 작동하지 않습니다. 그렇다면 직접적인 개체 참조를 사용하여 자신의 프로필을 명시적으로 보는 패턴은 무엇이라고 생각하시나요? 자신의 프로필을 보려면 URL에 대한 대체 경로를 입력하세요. 'WebGoat'로 시작하십시오(예: 'http://localhost:8080/' 무시). 의미 없는 경로를 전송했더니 위와 같이 /WebGoat/IDOR/profile..

먼저 인증하고 나중에 악용 승인 많은 액세스 제어 문제는 인증되었지만 권한이 없는 사용자의 공격에 취약합니다. 그럼 본격적으로 인증을 시작해 보겠습니다. 그런 다음 인증을 우회하거나 남용하는 방법을 찾아보겠습니다. 이 경우 계정의 아이디와 비밀번호는 'tom'과 'cat'입니다(안전하지 않은 앱이겠죠?). 인증 후 다음 화면으로 진행합니다. 아이디: 'tom' 비밀번호 : 'cat' 입력하면 인증완료입니다. 차이점 및 행동 관찰 AppSec 공격 측면의 일관된 원칙은 눈에 보이는 것과 원시 응답의 차이점을 확인하는 것입니다. 즉, 클라이언트 측 필터링 강의에서 이미 언급한 것처럼 화면/페이지에 표시되지 않는 원시 응답의 데이터가 있는 경우가 많습니다. 아래 프로필을 보고 차이점을 확인하세요. 아래 텍스트..