XSS 공격 벡터

Question

텍스트 필드의 비 초기화 된 입력 이외에도 웹 사이트에 대한 일반적인 XSS 벡터는 페이지로 돌아 오는 길을 찾는 방법은 무엇입니까? 쿠키에서 csrf 토큰에 대한 악의적 인 액세스를 막으려고합니다. 안전하지 않은 문자를 텍스트 입력으로부터 이스케이프 처리합니다 (데이터베이스 서블릿이나 UI에 인쇄하기 전에 자바 서블릿에 추가하는 것으로 끝날 것입니다). 사이트에 XSS가 들어가기 위해서는 어디에서해야합니까?

Answer 1

질문을 올바르게 이해하면 UI의 입력 필드에서 사용자 입력을 인코딩하여 반사되고 저장된 XSS의 일부 양식이 완화되었습니다.

당신은 몇 가지에주의해야합니다

• 모든 사용자 입력은 UI 입력 필드를 통해입니다. 쿠키와 요청 헤더는 또한 사용자 입력의 예이고 물론 숨겨진 필드 또는 json/xml/다른 모든 유형의 매개 변수입니다. 응용 프로그램에서 파일을 처리하거나 http 외의 외부 요청을 수신하는 경우에도 사용자 입력입니다. 데이터베이스의 필드조차도 사용자 입력으로 처리하는 것이 가장 좋으며 특히 다른 구성 요소가 데이터베이스에도 쓰는 경우 페이지에 쓰는 과정에서 인코딩됩니다.
• 어쩌면 이미 응용 프로그램에있는 경우일지도 모르지만이 대답을 좀 더 포괄적으로 만들 수 있습니다. XSS는 사용자 입력의 출처와 관계없이 출력 문제와 관련이 있습니다. 솔루션은 대부분의 경우 인코딩으로 출력됩니다 (입력되지 않음). 유효화/위생 처리 그 자체로는, 특히 블랙리스트에는 해당되지 않음). 그러나 이것에주의 깊은 예외가있을 수 있으며 물론 입력 유효성 검사는 실제로 적절한 출력 인코딩을 훌륭하게 보완합니다.
• 인코딩 방법은 데이터가 기록되는 컨텍스트에 따라 선택되어야합니다 (즉, 자바 스크립트 블록이나 일반 HTML을 작성할 때 다른 인코딩이 필요하며 자바 스크립트 블록은 스크립트 태그 내부에있을뿐만 아니라 예를 들어 onclick 및 기타와 같은 내부 이벤트 속성).
• DOM XSS는 전적으로 클라이언트에 있으므로 Javascript로 완화해야합니다. 아래의 관련 OWASP 가이드를 참조하십시오.

일반 OWASP XSS page은 매우 유용합니다. 또한 몇 가지 가이드가 있습니다 reflected, stored 및 DOM XSS에 대한

• Stored and Reflected XSS prevention cheat sheet
• DOM XSS prevention cheat sheet
• 테스트.