사이트 간 스크립팅 테스트

크로스 사이트 스크립팅 (XSS)은 애플리케이션이 신뢰할 수없는 데이터를 가져와 유효성 검사없이 클라이언트 (브라우저)로 보낼 때마다 발생합니다. 이를 통해 공격자는 피해자의 브라우저에서 악성 스크립트를 실행하여 사용자 세션을 가로 채거나 웹 사이트를 손상 시키거나 사용자를 악성 사이트로 리디렉션 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

XSS의 유형

Stored XSS − 영구 XSS라고도하는 저장된 XSS는 데이터베이스 / 메시지 포럼 / 댓글 필드 등과 같은 대상 서버에 사용자 입력이 저장 될 때 발생합니다. 그러면 피해자는 웹 애플리케이션에서 저장된 데이터를 검색 할 수 있습니다.
Reflected XSS − 비 영구 XSS라고도 알려진 Reflected XSS는 사용자 입력이 웹 애플리케이션에서 오류 메시지 / 검색 결과 또는 요청의 일부로 사용자가 제공 한 입력으로 즉시 반환되고 사용자가 제공 한 데이터를 영구적으로 저장하지 않을 때 발생합니다.
DOM Based XSS − DOM 기반 XSS는 데이터 소스가 DOM에 있고 싱크도 DOM에 있으며 데이터 흐름이 브라우저를 벗어나지 않을 때 XSS의 한 형태입니다.

예

응용 프로그램은 유효성 검사없이 구성에 신뢰할 수없는 데이터를 사용합니다. 특수 문자는 이스케이프해야합니다.

http://www.webpage.org/task/Rule1?query=try

공격자는 브라우저에서 쿼리 매개 변수를 다음과 같이 수정합니다.

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

손에

Step 1− Webgoat에 로그인하고 크로스 사이트 스크립팅 (XSS) 섹션으로 이동합니다. XSS (Stored Cross-site Scripting) 공격을 실행 해 보겠습니다. 아래는 시나리오의 스냅 샷입니다.

Step 2− 시나리오에 따라 시나리오 자체에서 언급 한 암호 'tom'을 사용하여 Tom으로 로그인하겠습니다. '프로필보기'를 클릭하고 편집 모드로 들어갑니다. tom이 공격자이므로 해당 편집 상자에 Java 스크립트를 삽입하겠습니다.

<script> 
   alert("HACKED")
</script>

Step 3 − 업데이트가 끝나 자마자 tom은 앱이 취약하다는 "해킹 됨"메시지가 포함 된 경고 상자를받습니다.

Step 4 − 이제 시나리오에 따라 jerry (HR)로 로그인하고 jerry가 삽입 된 스크립트의 영향을 받는지 확인해야합니다.

Step 5 − Jerry로 로그인 후 'Tom'을 선택하고 아래와 같이 '프로필보기'를 클릭합니다.

Jerry의 계정에서 Tom의 프로필을 보는 동안 그는 동일한 메시지 상자를 얻을 수 있습니다.

Step 6 −이 메시지 상자는 예시 일뿐 실제 공격자는 메시지 상자를 표시하는 것 이상을 수행 할 수 있습니다.

예방 메커니즘

개발자는 데이터가 배치되는 본문, 속성, JavaScript, CSS 또는 URL과 같은 HTML 컨텍스트를 기반으로 신뢰할 수없는 모든 데이터를 이스케이프해야합니다.
특수 문자를 입력으로 필요로하는 애플리케이션의 경우 유효한 입력으로 받아들이 기 전에 강력한 검증 메커니즘이 있어야합니다.