XSS 공격에 대한 나의 이해는 양식을 통해 악의적 인 입력을 입력하는 사람들 (집중 XSS 공격)에 중점을 둡니다.이것은 유효한 XSS 공격입니까
그러나 나는 비 지속성을 이해하려고 노력하고 있습니다. 예를 들어이되어 아무것도, 당신은 누군가에게이 같은 XSS 코드와 링크를 보낼 수없는 경우
http://localhost/MyProject/action.do?Title=<script>alert('XSS');</script>
예, 로그인 한 경우 스크립트에서 쿠키에 액세스하여 모든 곳으로 보낼 수 있습니다.
그것은 확실히 취약점이다 (분명히 경고가 ... 더 불길한 뭔가를 대체 할 수있다).
해당 링크의 한 가지 문제점은 일반적으로 <tags>이며, URL 인코딩이없는 URL에서는 일반적으로 허용되지 않습니다. 그래서 링크를 우편으로 보내거나 게시하면 좋지 않을 것입니다.
그것의보다 현실적인 URL 인코딩 된 형태가 될 것이다 ..
http://localhost/MyProject/action.do?Title=%3Cscript%3Ealert%28%27XSS%27%29%3B%3C%2Fscript%3E%
이 URL을 클릭하면 대상 웹 서버는 Title 값을 언 이스케이프와 것입니다 ... 만약
<script>alert('XSS');</script>
... 그대로 으로 쓰여졌 고, 페이지에는이 HTML로 이스케이프 처리되었습니다. 이것은 절대적으로 XSS입니다.
제프 앳 우드의 답변에 대한 평판이 없기 때문에 여기에 동의하지 않을 것입니다. 이와 같은 링크는 분명히 메일로 보내질 수 있으며 반영된 XSS에 취약한 사이트를 악용하는 데 사용될 수 있습니다. 필자는 Gmail과 내가 제어 할 수있는 사이트에서 테스트를 실시했습니다.
아마도 인코딩이 백그라운드에서 수행되었지만 관계없이 링크를 입력하고 이메일을 보낸 다음 링크를 클릭하고 악용 할 수있었습니다. 또한 모든 브라우저에서 인코딩없이 페이로드에 직접 입력 할 수 있었고 스크립트를 실행할 수있었습니다.
그렇습니다. 해당 코드는 "유효한 XSS"이며 사이트에서 해당 자바 스크립트를 트리거하는 경우 사이트는 반사 된 XSS 공격에 취약합니다.
예 이것은 XSS 취약점입니다. The Tittle 문자열을 렌더링하기 전에 위생 처리하지 않고 그대로 표시합니다. OWASP와 같은 웹 응용 프로그램 방화벽을 사용하여 XSS를 막을 수 있습니다. 스틱저
경고를 두는 것은 크로스 사이트 스크립팅 또는 XSS에 대한 응용 프로그램 취약점을 테스트하는 가장 널리 사용되고 널리 사용되는 방법입니다.
내부적 사람에게 쿠키 또는 세션에서 복사 한 정보를 보내시겠습니까 악의적 인 사이트 또는
에 고객을 재 - 같은 URL 표시는 경고, 매우 가능성이 동일한 URL 수 있다면.
고객은 URL에서 신뢰할 수있는 사이트 도메인을 계속 볼 수 있기 때문에이 작업을 수행 한 신뢰할 수있는 사이트라고 생각할 것입니다.