Programing

HTML 인코딩은 모든 종류의 XSS 공격을 방지합니까?

lottogame 2020. 11. 28. 08:35
반응형

HTML 인코딩은 모든 종류의 XSS 공격을 방지합니까?


나는 다른 종류의 공격에 대해 걱정하지 않습니다. HTML Encode가 모든 종류의 XSS 공격을 막을 수 있는지 알고 싶습니다.

HTML Encode를 사용하더라도 XSS 공격을 할 수있는 방법이 있습니까?


아니.

HtmlEncode는 일부 태그를 허용하는 주제를 제쳐두고 (실제로 질문의 요지가 아님) 모든 XSS 공격을 다루지는 않습니다.

예를 들어, 서버 생성 클라이언트 측 자바 스크립트를 고려해보세요. 서버는 html 인코딩 된 값을 클라이언트 측 자바 스크립트에 직접 동적으로 출력하지만 htmlencode는 삽입 된 스크립트 실행을 중지하지 않습니다 .

다음으로 다음 의사 코드를 고려하십시오.

<input value=<%= HtmlEncode(somevar) %> id=textbox>

이제 즉시 명확하지 않은 경우 somevar (물론 사용자가 보낸)가 예를 들어 다음과 같이 설정되면

a onclick=alert(document.cookie)

결과 출력은 다음과 같습니다.

<input value=a onclick=alert(document.cookie) id=textbox>

분명히 작동합니다. 분명히 이것은 (거의) 다른 스크립트가 될 수 있으며 HtmlEncode는별로 도움이되지 않습니다.

고려해야 할 몇 가지 추가 벡터가 있습니다. 여기에는 DOM 기반 XSS라고하는 XSS의 세 번째 버전 (예 : # 값에 따라 악성 스크립트가 클라이언트에서 동적으로 생성됨)이 포함됩니다.

또한 UTF-7 유형 공격을 잊지 마세요-공격이 보이는 곳

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

인코딩 할 내용이 많지 않습니다 ...

물론 해결책은 (적절하고 제한적인 화이트리스트 입력 유효성 검사 외에) 상황에 맞는 인코딩 을 수행 하는 것입니다. 출력 컨텍스트가 HTML이거나 JavaScriptEncoding, VBScriptEncoding 또는 AttributeValueEncoding이 필요한 경우 HtmlEncoding이 좋습니다. , 또는 ... 등

MS ASP.NET을 사용하는 경우 필요한 모든 컨텍스트 인코딩 방법을 제공하는 Anti-XSS 라이브러리를 사용할 수 있습니다.

모든 인코딩은 사용자 입력으로 제한되지 않아야하며 데이터베이스, 텍스트 파일 등의 저장된 값도 포함해야합니다.

아, 그리고 HTTP 헤더와 META 태그 모두에서 명시 적으로 charset을 설정하는 것을 잊지 마십시오. 그렇지 않으면 여전히 UTF-7 취약성이 있습니다.

더 많은 정보와 매우 명확한 목록 (계속 업데이트 됨)은 RSnake의 Cheat Sheet를 확인하십시오 : http://ha.ckers.org/xss.html


를 표시하기 전에 모든 사용자 입력을 체계적으로 인코딩 하면 여전히 100 % 안전하지 않습니다.
(자세한 내용은 @Avid의 게시물 참조)

또한 사용자가 이미지 나 굵은 텍스트 또는 사용자 입력이 필요한 기능을 인코딩되지 않은 마크 업으로 처리 (또는 변환) 할 수 있도록 일부 태그를 인코딩되지 않은 상태로 두어야 할 때 문제가 발생 합니다.

허용되는 태그와 허용되지 않는 태그를 결정하기 위해 의사 결정 시스템을 설정해야하며, 누군가가 허용되지 않는 태그를 통과하도록 허용하는 방법을 항상 알아낼 수 있습니다.

잘못된 코드를 잘못 보이게 만드는 Joel의 조언을 따르 거나 처리되지 않은 사용자 데이터를 출력 할 때 (정적 타이핑) 경고 / 컴파일하지 않음으로써 언어가 도움이 되는 경우 도움이 됩니다.


모든 것을 인코딩하면됩니다. (플랫폼과 htmlencode 구현에 따라 다름) 그러나 유용한 웹 응용 프로그램은 너무 복잡해서 모든 부분을 확인하는 것을 잊기 쉽습니다. 또는 타사 구성 요소가 안전하지 않을 수 있습니다. 아니면 인코딩을했지만 다른 코드 경로를 잊었을 수도 있습니다.

따라서 입력 측면에서도 확인하고 싶을 수 있습니다. 그리고 데이터베이스에서 읽은 내용을 확인하고 싶을 수도 있습니다.


다른 모든 사람이 언급했듯이 모든 사용자 입력을 표시하기 전에 인코딩하는 한 안전 합니다. 여기에는 사용자 입력으로 변경할 수있는 데이터베이스에서 검색된 모든 요청 매개 변수 및 데이터가 포함됩니다.

으로 팻 언급 가끔 몇 가지 태그, 그냥 모든 태그를 표시 할 수 있습니다. 이를 수행하는 일반적인 방법 중 하나는 Textile , Markdown 또는 BBCode 와 같은 마크 업 언어를 사용하는 것 입니다. 그러나 마크 업 언어조차도 XSS에 취약 할 수 있습니다.

# Markup example
[foo](javascript:alert\('bar'\);)

"안전한"태그를 사용하기로 결정했다면 출력 전에 코드를 구문 분석하고 삭제하기 위해 기존 라이브러리를 찾는 것이 좋습니다. 있다 XSS의 많은 벡터 당신의 소독제는 매우 안전하기 전에 탐지 할 것이라고 거기.


출력 필터링을 처리 할 타사 라이브러리를 찾으려면 metavida의 조언을 두 번째로 제공합니다. HTML 문자를 무력화하는 것은 XSS 공격을 막는 좋은 방법입니다. 그러나 메타 문자를 변환하는 데 사용하는 코드는 회피 공격에 취약 할 수 있습니다. 예를 들어 유니 코드와 국제화를 제대로 처리하지 못하는 경우입니다.

홈브류 출력 필터가 저지르는 고전적인 간단한 실수는 <와> 만 잡는 것이지만 "와 같은 것을 놓치는 것입니다.이 경우 사용자가 제어하는 ​​출력을 HTML 태그의 속성 공간으로 분리 할 수 ​​있으며, 여기서 Javascript가 DOM에 첨부 될 수 있습니다.


아니요, 일반적인 HTML 토큰을 인코딩하는 것만으로는 XSS 공격으로부터 사이트를 완전히 보호 할 수 없습니다. 예를 들어 google.com에서 발견 된 다음 XSS 취약점을 참조하십시오.

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

이러한 유형의 취약성에 대한 중요한 점은 공격자가 UTF-7을 사용하여 자신의 XSS 페이로드를 인코딩 할 수 있고 페이지에 다른 문자 인코딩을 지정하지 않은 경우 사용자의 브라우저가 UTF-7 페이로드를 해석하고 공격 스크립트를 실행합니다.


확인해야 할 또 다른 사항은 입력의 출처입니다. 리퍼러 문자열 (대부분의 경우)을 사용하여 자신의 페이지에서 가져온 것인지 확인할 수 있지만 숨겨진 임의 번호 또는 양식에 무언가를 입력 한 다음이를 확인 (세션 세트 변수 포함)하는 것도 입력은 일부 피싱 사이트가 아니라 자신의 사이트에서 나옵니다.


HTML Purifier ( http://htmlpurifier.org/ ) 를 제안하고 싶습니다 . html을 필터링하는 것이 아니라 기본적으로 토큰 화하고 다시 컴파일합니다. 진정한 산업적 강점입니다.

유효한 html / xhtml 출력을 보장 할 수있는 추가 이점이 있습니다.

또한 섬유는 훌륭한 도구이며 항상 사용하지만 html 정화기를 통해 실행했습니다.

나는 당신이 내가 토큰을 의미하는 것을 이해하지 못했다고 생각합니다. HTML Purifier는 단순히 '필터링'하는 것이 아니라 실제로 html을 재구성합니다. http://htmlpurifier.org/comparison.html


나는 그렇게 믿지 않는다. Html Encode는 모든 기능 문자 (브라우저에서 코드로 해석 할 수있는 문자)를 브라우저에서 구문 분석 할 수 없으므로 실행할 수없는 엔티티 참조로 변환합니다.

&lt;script/&gt;

There is no way that the above can be executed by the browser.

**Unless their is a bug in the browser ofcourse.*

참고URL : https://stackoverflow.com/questions/53728/will-html-encoding-prevent-all-kinds-of-xss-attacks

반응형