htmlspecialchars와 mysql_real_escape_string은 PHP 코드를 주입으로부터 안전하게 보호합니까?

오늘 초 웹 앱의 입력 유효성 검사 전략에 대한 질문이있었습니다 .

상단의 대답은, 작성시에 제시 PHP단지 사용 htmlspecialchars하고 mysql_real_escape_string.

제 질문은 이것이 항상 충분합니까? 우리가 알아야 할 것이 더 있습니까? 이러한 기능은 어디에서 분해됩니까?

데이터베이스 쿼리의 경우 항상 준비된 매개 변수화 된 쿼리를 사용하십시오. mysqli및 PDO라이브러리는이 기능을 지원. .NET과 같은 이스케이프 함수를 사용하는 것보다 훨씬 안전 mysql_real_escape_string합니다.

예, mysql_real_escape_string사실상 문자열 이스케이프 함수입니다. 마법의 총알이 아닙니다. 단일 쿼리 문자열에서 안전하게 사용할 수 있도록 위험한 문자를 이스케이프 처리합니다. 그러나 미리 입력을 삭제하지 않으면 특정 공격 벡터에 취약해질 수 있습니다.

다음 SQL을 상상해보십시오.

$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);

이것이 악용에 취약하다는 것을 알 수 있어야합니다. 매개 변수에 일반적인 공격 벡터가 포함되어
있다고 상상해보십시오 id.

1 OR 1=1

인코딩 할 위험한 문자가 없으므로 이스케이프 필터를 통과합니다. 우리를 떠나 :

SELECT fields FROM table WHERE id= 1 OR 1=1

이것은 멋진 SQL 주입 벡터이며 공격자가 모든 행을 반환 할 수 있도록합니다. 또는

1 or is_admin=1 order by id limit 1

생산하는

SELECT fields FROM table WHERE id=1 or is_admin=1 order by id limit 1

이것은 공격자가이 완전히 가상의 예에서 첫 번째 관리자의 세부 정보를 반환 할 수 있도록합니다.

이러한 기능은 유용하지만주의해서 사용해야합니다. 모든 웹 입력이 어느 정도 검증되었는지 확인해야합니다. 이 경우 우리가 숫자로 사용하던 변수가 실제로 숫자인지 확인하지 않았기 때문에 악용 될 수 있음을 알 수 있습니다. PHP에서는 입력이 정수, 부동 소수점, 영숫자 등인지 확인하기 위해 함수 세트를 광범위하게 사용해야합니다. 그러나 SQL에 관해서는 준비된 명령문의 대부분의 값에 유의하십시오. 위의 코드는 데이터베이스 함수가 1 OR 1=1유효한 리터럴이 아니라는 것을 알았 기 때문에 준비된 문이라면 안전했을 것 입니다.

에 관해서는 htmlspecialchars(). 그것은 그 자체로 지뢰밭입니다.

PHP에는 다양한 html 관련 이스케이프 기능이 선택되어 있고 정확히 어떤 기능이 무엇을하는지에 대한 명확한 지침이 없다는 점에서 PHP에는 실제 문제가 있습니다.

첫째, HTML 태그 안에 있다면 정말 문제가됩니다. 보다

echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';

우리는 이미 HTML 태그 안에 있으므로 위험한 작업을 수행하기 위해 <또는>가 필요하지 않습니다. 우리의 공격 벡터는javascript:alert(document.cookie)

이제 결과 HTML은 다음과 같습니다.

<img src= "javascript:alert(document.cookie)" />

공격이 곧장 진행됩니다.

더 나빠집니다. 왜? htmlspecialchars(이 방법으로 호출하면) 작은 따옴표가 아닌 큰 따옴표 만 인코딩 하기 때문 입니다. 그래서 만약 우리가

echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";

우리의 사악한 공격자는 이제 완전히 새로운 매개 변수를 주입 할 수 있습니다.

pic.png' onclick='location.href=xxx' onmouseover='...

우리에게 주어지다

<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />

이러한 경우에는 마법의 총알이 없으며 입력을 직접 확인하면됩니다. 나쁜 문자를 걸러 내려고하면 확실히 실패 할 것입니다. 화이트리스트 접근 방식을 취하고 좋은 문자 만 통과 시키십시오. 벡터의 다양성에 대한 예 는 XSS 치트 시트 를 참조하십시오.

htmlspecialchars($string)HTML 태그 외부에서 사용하더라도 다중 바이트 문자 집합 공격 벡터에 여전히 취약합니다.

가장 효과적인 방법은 다음과 같이 mb_convert_encoding과 htmlentities의 조합을 사용하는 것입니다.

$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
$str = htmlentities($str, ENT_QUOTES, 'UTF-8');

이것조차도 UTF를 처리하는 방식 때문에 IE6를 취약하게 만듭니다. 그러나 IE6 사용이 감소 할 때까지 ISO-8859-1과 같은 더 제한된 인코딩으로 대체 할 수 있습니다.

멀티 바이트 문제에 대한 심층 연구는 https://stackoverflow.com/a/12118602/1820을 참조 하십시오.

Cheekysoft의 탁월한 답변 외에도 :

• 예, 그들은 당신을 안전하게 지킬 것이지만 절대적으로 올바르게 사용되는 경우에만 가능합니다. 잘못 사용하면 여전히 취약하고 다른 문제 (예 : 데이터 손상)가있을 수 있습니다.
• 대신 매개 변수화 된 쿼리를 사용하십시오 (위에 설명 된대로). 예를 들어 PDO 또는 PEAR DB와 같은 래퍼를 통해 사용할 수 있습니다.
• magic_quotes_gpc와 magic_quotes_runtime이 항상 꺼져 있는지 확인하고, 잠깐이라도 실수로 켜지지 않도록하십시오. 이것은 보안 문제 (데이터 파괴)를 방지하기 위해 PHP 개발자가 시도한 초기의 심오한 잘못된 시도입니다.

HTML 삽입 (예 : 교차 사이트 스크립팅)을 방지하는 은색 총알은 없지만 HTML을 출력하기 위해 라이브러리 또는 템플릿 시스템을 사용하는 경우 더 쉽게 달성 할 수 있습니다. 적절하게 탈출하는 방법에 대한 설명서를 읽으십시오.

HTML에서는 상황에 따라 다르게 이스케이프 처리해야합니다. 이것은 특히 자바 스크립트에 배치되는 문자열에 해당됩니다.

위의 게시물에 확실히 동의하지만 Cheekysoft의 답변에 대한 답장으로 추가해야 할 작은 것이 하나 있습니다.

데이터베이스 쿼리의 경우 항상 준비된 매개 변수화 된 쿼리를 사용하십시오. mysqli 및 PDO 라이브러리가이를 지원합니다. 이것은 mysql_real_escape_string과 같은 이스케이프 함수를 사용하는 것보다 훨씬 안전합니다.

예, mysql_real_escape_string은 사실상 문자열 이스케이프 함수입니다. 마법의 총알이 아닙니다. 단일 쿼리 문자열에서 안전하게 사용할 수 있도록 위험한 문자를 이스케이프 처리 할 수 ​​있습니다. 그러나 입력 내용을 사전에 삭제하지 않으면 특정 공격 벡터에 취약해질 수 있습니다.

다음 SQL을 상상해보십시오.

$ result = "테이블에서 필드 선택 WHERE id =".mysql_real_escape_string ($ _ POST [ 'id']);

이것이 악용에 취약하다는 것을 알 수 있어야합니다. id 매개 변수에 일반적인 공격 벡터가 포함되어 있다고 상상해보십시오.

1 또는 1 = 1

인코딩 할 위험한 문자가 없으므로 이스케이프 필터를 통과합니다. 우리를 떠나 :

테이블 WHERE id = 1 OR 1 = 1에서 필드 선택

나는 숫자가 아닌 것을 제거하는 데이터베이스 클래스에 넣은 간단한 함수를 코딩했습니다. preg_replace를 사용하기 때문에 좀 더 최적화 된 기능이 있지만, 핀치에서 작동합니다.

function Numbers($input) {
  $input = preg_replace("/[^0-9]/","", $input);
  if($input == '') $input = 0;
  return $input;
}

그래서 사용하는 대신

$ result = "테이블에서 필드 선택 WHERE id =".mysqlrealescapestring ( "1 OR 1 = 1");

나는 사용할 것이다

$ result = "테이블에서 필드 선택 WHERE id =".Numbers ( "1 OR 1 = 1");

쿼리를 안전하게 실행합니다.

테이블 WHERE id = 111에서 필드 선택

물론, 그것은 올바른 행을 표시하지 못하도록 막았지만 사이트에 SQL을 주입하려는 사람에게는 큰 문제라고 생각하지 않습니다.)

이 퍼즐의 중요한 부분은 컨텍스트입니다. 쿼리에서 모든 인수를 인용하면 "1 OR 1 = 1"을 ID로 보내는 사람은 문제가되지 않습니다.

SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"

결과 :

SELECT fields FROM table WHERE id='1 OR 1=1'

효과가 없습니다. 문자열을 이스케이프하기 때문에 입력은 문자열 컨텍스트를 벗어날 수 없습니다. 나는 이것을 MySQL 5.0.45 버전까지 테스트했으며 정수 열에 문자열 컨텍스트를 사용하면 문제가 발생하지 않습니다.

$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];

64 비트 시스템에서 더 잘 작동합니다. 그러나 많은 수를 처리하는 데 대한 시스템 제한에 유의하십시오. 그러나 데이터베이스 ID의 경우 99 %의 시간 동안 매우 효과적입니다.

또한 값을 정리하기 위해 단일 기능 / 방법을 사용해야합니다. 이 함수가 mysql_real_escape_string ()의 래퍼 일지라도. 왜? 선호하는 데이터 정리 방법에 대한 익스플로잇이 발견 된 어느 날 시스템 전체의 찾기 및 바꾸기가 아니라 한 곳에서만 업데이트하면됩니다.

왜, 왜, SQL 문에서 사용자 입력 주위에 따옴표를 포함 하지 않습니까? 어리석은 것 같지 않습니다! SQL 문에 따옴표를 포함하면 "1 또는 1 = 1"은 결실없는 시도가됩니다.

이제 "사용자가 입력에 따옴표 (또는 큰 따옴표)를 포함하면 어떻게됩니까?"라고 말할 것입니다.

글쎄, 쉽게 고칠 수 있습니다. 사용자가 입력 한 따옴표 만 제거하면됩니다. 예 : input =~ s/'//g;. 이제는 어쨌든 사용자 입력이 보호되는 것 같습니다 ...