$ _REQUEST 데이터가 안전한지 확인하는 좋은 방법입니까?

Question

기본적으로 내 생각에 내용을 예측할 수없는 문자열을 16 진수 문자열로 변환 한 다음 데이터를받는 스크립트에서 다시 읽을 수있는 문자열로 변환하면 잠재적 인 XSS 취약점도 예방할 수 있습니다. 앰퍼샌드, 물음표 등과 같은 특수 문자가 Script2.php의 실행을 엉망으로 만들지 않도록하십시오. 이게 맞습니까? 아니면 더해야합니까? Script1.php에서

: Script2.php에서

echo('<TD><A HREF="Script2.php?reason=' . bin2hex($input['reason']) . '">Proceed</A></TD>'); 

:

echo('<input type="text" name="reason">' . strlen($_REQUEST['reason'])?pack('H*', $_REQUEST['reason']):'<I>No reason specified</I>' . '</input>'); 

Answer 1

을,이 당신이주의해야 할 정확히 한 가지 : 외부 시스템에 명령을 내릴 때, 당신은 그 명령이 당신이 생각하는 것과 정확히 일치 하는지를 확인해야합니다. 당신이 PHP로 프로그래밍하는 경우

, 자주이 외부 시스템과 거래 :

1. 웹 브라우저는 당신이 당신의 HTML을 보내 이십 기가 바이트에,
2. 데이터를 저장하는 데이터베이스를.

포인트 1의 경우 데이터베이스에서 제공하는 데이터를 htmlspecialchars()으로 필터링하십시오. 이 작업을 수행하지 않으려는 경우가 있지만 그 경우 사용자가 보안을 손상시키지 않는 이유가 정확히 인 을 알아야합니다.

포인트 2의 경우 준비된 명령문을 사용하여 데이터베이스 레코드를 삽입하고 업데이트하십시오. 새 코드의 경우 데이터가 어디에서 왔는지에 관계없이 예외가 있습니다. 준비된 명령문을 지원하지 않는 인터페이스를 사용하는 오래된 코드의 경우 mysql_real_escape_string()과 같은 것을 사용하여 데이터베이스에 삽입하거나 데이터베이스를 업데이트하기위한 값을 준비하십시오. 데이터가 어디에서 왔는지에 관계없이

이 두 요소는 기술적 요구 사항 (즉, 사용중인 기술에 따라 달라짐)입니다. 또한 비즈니스 요구 사항 (예 : 신용 카드 번호가 유효하거나 1995 년 8 월 30 일 이전에 생년월일, 장소는 최대 7 일 동안 만 예약 가능)이있을 수 있습니다. 기술 요구 사항과 비즈니스 요구 사항은 각기 다른 속도로 변경되므로 다른 구성 요소에서 처리해야합니다. 데이터가 비즈니스 요구를 충족시키는 지 여부를 검증하여 데이터베이스에 삽입하기 위해 기술적으로 적합한 데이터를 준비하지 마십시오.

이 시나리오를 특수 시나리오에 적용하면 Script1.php에서 HTML 문서의 URL 쿼리 문자열에 일부 데이터를 사용하려는 것으로 보입니다. 그것은 urlencode()을위한 것입니다. Script2.php에서 브라우저는 브라우저로 다시 보내려는 데이터를 보냈습니다. 이는 일반적으로 사용자 나 사용자의 보안에 중요하지 않습니다. 사용자가 </input>을 $_REQUEST['reason']으로 보내면 사용자를 혼동시킬 수 있기 때문에 데이터는 htmlspecialchars을 통해 전달되어야합니다. 명확하지 않다. strlen과 pack; 그렇게하지 않으면 동료 개발자 (나쁘다), 사용자 (나쁘다) 및 잠재적 공격자 (방해가 아닌 도전이라고 생각하는)를 혼동하는 것 이외의 목적을 제공하지 않습니다.

Answer 2

OWASP는 XSS 최고의 방지하는 방법에 대한 몇 가지 매우 상세한 정보가 있습니다 기본적으로 https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#A_Positive_XSS_Prevention_Model