2010-03-16 5 views
6

사용자가 다양한 정보를 입력하는 양식이 있다고 가정 해보십시오. 우리는 정보를 검증하고 무언가가 잘못되었음을 확인합니다. 입력란이 누락되었거나 이메일이 잘못되었습니다.위생 처리없이 사용자 입력을 입력 값으로 표시하는 것이 안전합니까?

양식을 사용자에게 다시 표시 할 때 나는 입력 필드를 채우기 위해 모든 것을 다시 입력하지 않아도됩니다. 위생 처리없이 이것을하는 것이 안전합니까? 그렇지 않다면 먼저 수행해야하는 최소 살균 처리는 무엇입니까?

그리고 clearify : 예를 들어 데이터베이스에 추가되거나 사이트의 다른 곳에 표시되기 전에 위생 처리됩니다.

+1

Ahem. 나는 ** 위생 **보다는 위생 **을 의미한다고 생각합니다! –

+0

@ 존 : 당신은 매우 정확할 수 있습니다 : p – Svish

+0

http://xkcd.com/327/이 문제를 설명해야합니다. –

답변

8

아니요. 사용자는 타사 사이트의 양식으로 이동하거나 HTML을 위반하는 데이터 (무심결에)를 입력 할 수 있습니다.

특별한 의미를 지닌 모든 문자를 해당 HTML 항목으로 변환하십시오.

&amp;-&, <&lt;에, >&gt;"&quot;에 ( 이 펄에서

는 TT에 PHP에서 html filter를 사용 HTML::Entities를 사용하면 "하지 '.

를 사용하여 속성 값을 구분 가정 htmlspecialchars을 사용하십시오. 사용하는 언어에서 비슷한 것을 찾으십시오.

+0

당신이 맞을 때, OP는 컨텍스트를 언급하지 않았으며, 입력 된 데이터의 맥락에서만 * 다른 사람 *이 볼 수 있거나 (또는 ​​자동 채워서 기존 데이터를 리디렉션 할 수 있음)/귀하의 페이지에 사용자가 로그인). 이것이 없다면, 당신은 단지 자신에게 XSS를하고있는 것이며, 이것은 꽤 쓸모가 없습니다. –

+0

공격자가 양식을 보내는 것을 시뮬레이트하는 링크를 생성 할 수 있으므로 (GET-params) 다른 사람에게 XSS 공격을 수행 할 수 있습니다. – Mnementh

+0

모든 주입 문제를 해결할 수있는 원 스톱 숍을 제공하려는 이러한 기능을 사용하는 데주의하십시오. HTML 페이지의 모든 영역에서 어떤 언어로든 본 적이없는 사람은 없습니다. (적어도 데이터를 파괴하지 않고). 여기에 언급 된 PHP htmlspecialchars() 만 적용해도 속성 값에서 안전하게 유지되지는 않습니다. – Cheekysoft

0

예, 물론 적절한 값을 인코딩해도 안전합니다. 어.

HTML의 속성 내부에 배치되는 값은 HTML로 인코딩되어야합니다. 사용중인 서버 측 플랫폼에는 이에 대한 메소드가 있어야합니다. ASP.NET의 경우 예를 들어 Server.HtmlEncode 메서드가 있고 TextBox 컨트롤은 Text 속성에 입력 한 값을 자동으로 HTML 인코딩합니다.

+0

-1 안전하지 않습니다. – rook

+0

@Rook : 정확하지 않습니다. 내가 같은 문장에서 말한 상황을 고려하면 안전하다. 전체 답을 읽지 않아도된다면, 적어도 첫 번째 문장 전체를 읽어야 downvoting을 할 수 있습니다. – Guffa

+0

"물론 값을 올바르게 인코딩해야합니다." 참으로 여기서 핵심이었습니다. 틀림없이 크고 복잡한 단서가 있지만 중요한 부분입니다. 여기에서 중요한 단계는 입력 인코딩이 아닌 출력 인코딩입니다. 물론 입력 검증은 매우 바람직합니다. 출력 인코딩 단계가 XSS를 보호한다는 점을 이해하는 것이 중요합니다. – Cheekysoft

1

누군가가 사용자가 양식에 특정 데이터를 제출하도록 강요 할 수 있으면 출력하고 브라우저에서 "실행"하므로 안전하지 않습니다. 예를 들어 사용자가 '/><meta http-equiv="refresh" content="0;http://verybadsite.org" />을 제출해야하는 경우 원치 않는 리디렉션이 발생합니다.

+0

누군가가 나를 브라우저에 입력하고 제출하도록 강요한다면 브라우저가 다음에 수행하는 작업이 내 걱정거리 중 가장 적은 것입니다. –

+0

@Paul : 예, 저는 http://imgs.xkcd.com/comics/security.png를 생각했습니다. –

+0

OP의 로그인 양식을 제출하는 양식은 별도의 사이트에 있기 때문에 나쁜 예를들 수 있습니다. 따라서 공격자는 바로 verybadsite.org로 리다이렉트 할 것이고, 다른 사이트를 통해 갈 수있는 이점은 없습니다. – DisgruntledGoat

1

사용자 제공 데이터를 먼저 인코딩하지 않고 HTML 문서에 삽입 할 수 없습니다. 귀하의 목표는 문서의 구조를 변경할 수 없으며 데이터가 항상 HTML 값 또는 자바 스크립트 코드가 아닌 데이터 값으로 취급된다는 것입니다. 이 메커니즘에 대한 공격은 일반적으로 "교차 사이트 스크립팅"또는 간단히 "XSS"라고합니다.

HTML 속성 값에 삽입하는 경우 문자열로 인해 속성 값이 중간에 종료되지 않도록해야합니다. 물론 태그 자체를 끝낼 수 없도록해야합니다. 안전하다고 보장되지 않는 문자는 HTML 인코딩으로 확인할 수 있습니다.

태그 특성의 값이 큰 따옴표 나 작은 따옴표 쌍 안에 표시되도록 HTML을 작성하면 사용하기 위해 선택한 따옴표 문자 만 html로 인코딩해야합니다. 위의 설명대로 이 아니고이 속성을 올바르게 인용하고 있다면 공백, 기호, 구두점 및 기타 ASCII 제어 문자를 비롯한 더 많은 문자에 대해 걱정할 필요가 있습니다. 솔직하게 말하자면, 어쨌든이 문자가 아닌 영숫자 문자를 인코딩하는 것은 틀림없이 가장 안전합니다..당신은 적절한, HTML에 큰 따옴표 문자를 인코딩해야

두 번 인용 속성 값

<input type="text" value="**insert-here**" /> 

:

하는 HTML 속성 값이 3 가지 구문 컨텍스트에 나타날 수 있음을 기억하라 &quot;

작은 따옴표로 묶은 속성 값

<input type='text' value='**insert-here**' /> 

당신은 적절한 HTML 안전한 값으로 작은 따옴표 문자를 인코딩 할 필요가 같은 &#145;

지 않은 속성 값

<input type='text' value=**insert-here** /> 

혹시 HTML 태그가 없어야합니다 속성 값을 따옴표없이 표시하지만 때로는이 값을 제어 할 수 없습니다. 이 경우 공백, 구두점 및 기타 제어 문자에 대해 걱정할 필요가 있습니다. 속성 값에서 벗어날 수 있기 때문입니다.

영숫자 문자를 제외하고는 &#xHH; 형식 (또는 사용 가능한 경우 명명 된 엔터티)을 사용하여 256 미만의 ASCII 값을 갖는 모든 문자를 이스케이프 처리하여 특성이 전환되지 않도록하십시오. 인용 부호 속성은 [space]%*+,-/;<=>^| (등)를 포함하여 많은 문자와 함께 밖으로 나눌 수 있습니다. [para from OWASP]

위의 규칙은 HTML 속성 값에 삽입 할 때 컨트롤 삽입에만 적용된다는 점에 유의하십시오. 페이지의 다른 영역에는 다른 규칙이 적용됩니다.

자세한 내용은 XSS prevention cheat sheet at OWASP을 참조하십시오.

+0

그래서 PHP에서는'htmlspecialchars'로 속성 값을 큰 따옴표로 묶어두면 충분할 것입니다. 'name = "value"'처럼. – Svish

+0

@Swish 정확한 상황에서 나타냅니다. 그렇습니다. ... 우리가 멀티 바이트 문자 공격과 멀티 바이트 문자 공격에 대해 걱정하기 시작할 때까지 ... 그러나 여기는 약간 복잡합니다. – Cheekysoft

관련 문제