사용자가 텍스트를 입력하고 텍스트를 사용자에게 보여주고 모든 공백을 유지하고 싶습니다. 나는 어떤 악용도 원하지 않으며 사용자가 html이나 자바 스크립트를 주입하게한다. HttpUtility.HtmlEncode를 사용하면 충분히 안전합니까? ATM <> 및 기타 테스트 문자가 올바르게 인코딩 된 이후로 올바른 것으로 보입니다. 텍스트를 올바르게 표시하려면 무엇을 사용해야합니까? 지금은 <pre><code>을 사용하고 있습니다. 괜찮아 보이는데, 이것을 표시하는 올바른 방법입니까?HttpUtility.HtmlEncode는 안전한가요?
HTML 코드 또는 JavaScript까지 HtmlEncode는 안전해야합니다. HTML 마크 업 문자는 웹 페이지에 표시 될 때 다른 문자로만 표시되도록 인코딩됩니다.
예, 모든 공백을 포함하여 서식을 유지하려면 <pre>을 사용합니다.
HtmlEncode는 안전합니다. < > & ""을 해당 HTML 이스케이프 시퀀스 (예 : < 등)로 바꿀뿐만 아니라 멀티 바이트 문자를 숫자로 이스케이프 된 표현으로 바꿉니다 (즉, ☺) –
가능하면 멀티 바이트 문자를 대체하지 않습니다 160에서 255까지의 정수 값을 갖는 문자는 숫자 이스케이프 시퀀스 (즉, ÿ)로 변환되지만, 255보다 크거나 160보다 작은 값을 가진 문자 (예 : ÿ)는 소스 코드에서 볼 수 있습니다. 구체적으로 언급 된 다섯 개의 문자를 제외한 < > & " ')는 그대로 출력됩니다. 160-255를 피하려고하는 것조차 왜 미스터리입니까 (예 : 160은 확장 된 ASCII 범위의 중간에 있습니다). 어쨌든 HTML 텍스트에 예약 된 문자가 아니기 때문입니다. – Triynko
Web Protection Library의 AntiXSS 섹션에서 GetSafeHTMLFragment 메서드를 살펴볼 수 있습니다. 이것은 XSS 목적을 위해 HTML이 '안전'하다고 여겨지는 화이트리스트를 사용하며 화이트리스트에없는 것은 제거됩니다. Blowdart (WPL 팀에서 일하는 사람)은이 방법을 사용할 때 매우 blogpost입니다.
+ -0. 잘못된 나는 html을 sanitizes려고하지 않고, 텍스트를 다시 표시합니다. 그래서이 대답은 옳지 않습니다. 그러나 읽을 때 다른 사람들에게 유용 할 수 있습니다. –
소스 코드를 반향시키려는 의도입니까, 아니면 일반적으로 사용자가 제공 한 텍스트입니까? –