$ _REQUEST [] 사용에있어 문제점은 무엇입니까?

여기에 $_REQUEST변수 를 사용하지 말라고 말하는 많은 게시물을 보았습니다 . 나는 보통 그렇지 않지만 때로는 편리합니다. 뭐가 잘못 됐나요?

둘 다 $_GET그리고 $_POST결합 된 방식으로 입력을받는 데 전혀 문제가 없습니다 . 사실 이것이 거의 항상하고 싶은 일입니다.

• 일반적으로 GET을 통해 제출되는 일반 멱 등성 요청의 경우 원하는 데이터 양이 URL에 맞지 않아 실제 문제로 대신 POST 요청으로 변경 될 가능성이 있습니다.

• 실제 효과가있는 요청의 경우 POST 메서드에 의해 제출되었는지 확인해야합니다. 그러나이를 수행하는 방법 은 GET을 위해 비어있는 것에 $_SERVER['REQUEST_METHOD']의존하지 않고 명시 적 으로 확인 $_POST하는 것입니다. 어쨌든 메소드가 POST이면 URL에서 일부 쿼리 매개 변수를 가져와야 할 수 있습니다.

아니요, 문제 $_REQUEST는 GET 및 POST 매개 변수를 병합하는 것과 관련 이 없습니다. 또한 기본적으로 $_COOKIE. 그리고 쿠키는 실제로 양식 제출 매개 변수와 전혀 다릅니다. 쿠키를 동일한 것으로 취급하고 싶지는 않습니다.

실수로 양식 매개 변수 중 하나와 동일한 이름으로 사이트에 쿠키를 설정하면 해당 매개 변수에 의존하는 양식이 예상 매개 변수를 재정의하는 쿠키 값으로 인해 이상하게도 제대로 작동하지 않습니다. 같은 사이트에 여러 개의 앱이있는 경우이 작업은 매우 쉽고 오래된 쿠키를 사용하는 사용자가 두 명 뿐인 경우 더 이상 사용하지 않고 양식을 깨뜨리는 방식으로 디버그하기가 매우 어려울 수 있습니다. -다른 사람은 번식 할 수 있습니다.

PHP 5.3 의 request_order 구성을 사용하여이 동작을 훨씬 더 합리적인 GP(no C) 순서로 변경할 수 있습니다 . 이것이 가능하지 않은 경우 개인적으로 피하고 결합 된 GET + POST 배열이 필요한 경우 수동으로 생성합니다.$_REQUEST

저는 PHP 내부 에 대한 뉴스 그룹 게시물을 파헤 치고 주제에 대한 흥미로운 토론을 발견했습니다. 초기 스레드는 뭔가 다른,하지만 스테판 ESSER, A (아니라면하여 발언 PHP는 세계에서) 보안 전문가는 몇 게시물 $ _REQUEST를 사용하는 보안 관련쪽으로 논의를 돌았 다.

PHP 내부에 대해 Stefan Esser 인용

$ _REQUEST는 PHP의 가장 큰 디자인 약점 중 하나입니다. $ _REQUEST를 사용하는 모든 응용 프로그램은 지연된 교차 사이트 요청 위조 문제에 가장 취약합니다. (이것은 기본적으로 (age)라는 이름의 쿠키가 존재하는 경우 항상 GET / POST 콘텐츠를 덮어 쓰므로 원하지 않는 요청이 수행됨을 의미합니다.)

그리고 나중에 같은 스레드에 대한 답장에서

누군가가 GET, POST를 위조 할 수 있다는 사실에 관한 것이 아닙니다. COOKIE 변수. COOKIE가 REQUEST에서 GET 및 POST 데이터를 덮어 쓸 것이라는 사실에 관한 것입니다.

따라서 예를 들어 action = logout이라는 쿠키로 브라우저를 감염시킬 수 있으며 그날부터는 REQUEST [action]이 영원히 로그 아웃되므로 (쿠키를 수동으로 삭제할 때까지) 더 이상 응용 프로그램을 사용할 수 없습니다.

그리고 COOKIE로 당신을 감염시키는 것은 매우 간단합니다 ...
a) 하위 도메인의 모든 애플리케이션에서 XSS vuln을 사용할 수 있습니다.
b) 귀하가 a)를 소유 할 때 * .co.uk 또는 * .co.kr에 대한 쿠키 설정을 시도한 적이 있습니다. 거기에 단일 도메인?
c) 어떤 방식 으로든 다른 교차 도메인 ...

그리고 이것이 문제가 아니라고 믿으시면 * .co.kr 쿠키를 설정하여 여러 PHP 버전이 흰색 페이지를 반환하는 간단한 가능성이 있음을 알려 드릴 수 있습니다. * .co.kr의 모든 PHP 페이지를 죽이는 단 하나의 쿠키

그리고 * .co.kr에 유효한 쿠키에 + PHPSESSID = 불법 이라는 변수에 잘못된 세션 ID를 설정하면 PHP 세션을 사용하여 한국의 모든 PHP 응용 프로그램을 계속 도스 할 수 있습니다.

토론은 더 많은 게시물에 대해 계속되며 읽기에 흥미 롭습니다.

보시다시피, $ _REQUEST의 주요 문제는 $ _GET 및 $ _POST의 데이터가 아니라 $ _COOKIE의 데이터가 있다는 것입니다. 목록의 다른 사람들은 $ _REQUEST가 채워지는 순서를 변경하는 것을 제안했습니다. 예를 들어 먼저 $ _COOKIE로 채우는 것과 같이 이로 인해 세션 처리와 같은 다른 잠재적 인 문제가 발생할 수 있습니다 .

$ _REQUEST 전역에서 $ _COOKIES를 완전히 생략하여 다른 배열로 덮어 쓰지 않도록 할 수 있습니다 (사실 variable_order ini 설정 의 PHP 매뉴얼 처럼 표준 내용의 조합으로 제한 할 수 있습니다. 우리에게 말해:

variable_order EGPCS (Environment, Get, Post, Cookie 및 Server) 변수 구문 분석의 순서를 설정합니다. 예를 들어 variables_order가 "SP"로 설정되면 PHP는 슈퍼 글로벌 $ _SERVER 및 $ _POST를 생성하지만 $ _ENV, $ _GET 및 $ _COOKIE는 생성하지 않습니다. ""로 설정하면 슈퍼 글로벌이 설정되지 않습니다.

그러나 다시 말하지만, PHP에서 자신의 전역에서 환경, 가져 오기, 게시, 쿠키 및 서버에 액세스 할 수 있고 공격 벡터가 하나 더 적기 때문에 $ _REQUEST를 아예 사용하지 않는 것도 고려할 수 있습니다. 여전히이 데이터를 삭제해야하지만 걱정할 것이 하나 적습니다.

이제 $ _REQUEST가 왜 존재하고 왜 제거되지 않았는지 궁금 할 것입니다. 이것은 PHP 내부에서도 요청되었습니다. $ _REQUEST가 존재하는 이유 에 대해 Rasmus Lerdorf를 인용 합니다. PHP 내부

이와 같은 항목을 더 많이 제거할수록 사람들이 더 빠르고 더 안전한 새 버전의 PHP로 빠르게 이동하기가 더 어려워집니다. 이는 몇 가지 "추악한"레거시 기능보다 모든 사람에게 더 많은 좌절감을 안겨줍니다. 적절한 기술적 이유, 성능 또는 보안이 있으면 자세히 살펴 봐야합니다. 이 경우 우리가 살펴 봐야 할 것은 $ _REQUEST를 제거해야하는지 여부가 아니라 쿠키 데이터를 제거해야하는지 여부입니다. 내 모든 구성을 포함하여 많은 구성이 이미이를 수행하고 있으며 $ _REQUEST에 쿠키를 포함하지 않는 강력한 유효한 보안 이유가 있습니다. 대부분의 사람들은 $ _REQUEST를 사용하여 GET 또는 POST를 의미합니다. 쿠키도 포함될 수 있다는 사실을 깨닫지 못하고 악의적 인 사용자가 잠재적으로 쿠키 삽입 트릭을 수행하고 순진한 응용 프로그램을 손상시킬 수 있다는 사실을 깨닫지 못합니다.

어쨌든, 빛을 비추 길 바랍니다.

$_REQUEST모든 종류의 요청 (GET, POST 등)을 나타냅니다. 이것은 때때로 유용하지만 일반적으로 정확한 방법 ($ _GET, $ _POST 등)을 지정하는 것이 좋습니다.

$_REQUEST SQL에서 선언하는 대신 응용 프로그램 코드에서 단순-중간-복잡성 데이터 변환이 자주 수행되는 것과 같은 이유로 일반적으로 유해한 것으로 간주됩니다. 일부 프로그래머는 짜증납니다.

따라서 $_REQUEST모든 곳에서 사용하는 경향이있는 경우 POST를 통해 할 수있는 모든 작업을 GET을 통해 수행 할 수 있습니다. 즉, <img>사용자가 전자 상거래 모듈에 로그인하여 제품을 자동으로 구매하도록하는 내 (악성) 사이트에 태그를 설정 하거나 위험한 행동이나 민감한 정보 (아마 나에게)를 노출시키는 링크를 클릭하게 만들 수 있습니다.

그러나 이것은 초보자 또는 최소한 경험이없는 PHP 프로그래머가 간단한 실수를하기 때문입니다. 먼저 어떤 유형의 데이터가 적절한 지 파악하십시오. 예를 들어 URLEncoding, XML 또는 JSON으로 응답을 반환 할 수있는 웹 서비스가 있습니다. 애플리케이션은 HTTP_ACCEPT 헤더를 확인하여 응답의 형식을 지정하는 방법을 결정하지만 format매개 변수 를 전송하여 특정 헤더로 강제 변환 할 수 있습니다 .

format 매개 변수의 내용을 확인할 때 여러 요인에 따라 쿼리 문자열 또는 postdata를 통해 전송할 수 있습니다. 그 중 최소한 호출 응용 프로그램이 요청과 "& format = json"을 혼합하기를 원하는지 여부는 중요하지 않습니다. 이 경우 $_REQUEST다음과 같이 입력 할 필요가 없기 때문에 매우 편리합니다.

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

더 이상 다루지는 않겠지 만, $_REQUEST본질적으로 위험하기 때문에 사용이 설득되지 않는다고 말하면 충분합니다. 그것은 당신이 그 의미를 이해하든 말든, 요청 된 것을 정확히 수행하는 또 다른 도구 일뿐입니다. 이 문제를 일으키는 가난하거나 게으른 또는 경험이없는 프로그래머의 가난하거나 게으른 또는 정보가없는 결정.

$_REQUEST안전하게 사용하는 방법

1. 데이터 파악 : 어떤 종류의 데이터를 받을지 예상해야하므로 적절하게 삭제하세요. 데이터베이스 데이터? addslashes()또는 *_escape_string(). 사용자에게 다시 표시 하시겠습니까? htmlentities()또는 htmlspecialchars(). 수치 데이터가 필요하십니까? is_numeric()또는 ctype_digit(). 사실, filter_input()관련 기능은 데이터를 확인하고 삭제하는 것 외에는 아무것도하지 않도록 설계되었습니다. 항상 이러한 도구를 사용하십시오.
2. 사용자가 제공 한 슈퍼 글로벌 데이터에 직접 액세스하지 마십시오 . 매번 데이터를 삭제하는 습관을 들이고 데이터를 깨끗한 변수로 옮기십시오 $post_clean. 다른 방법으로는 직접 슈퍼 전역 단지 청소 할 수 있지만, 일을 너무 쉽게으로, 코드에서 취약점을 발견 할 수 있기 때문에 별도의 변수를 사용하여 옹호하는 이유는 아무것도 자동 전역과 소독 동등한 고려하지 위험한 오류에 직접 가리키는 .
3. 데이터의 출처를 파악하십시오. 위의 예제를 참조하면 응답 형식 변수가 GET 또는 POST를 통해 전송되도록 허용하는 것이 합리적입니다. 또한 "action"변수가 두 방법 중 하나를 통해 전송되도록 허용합니다. 그러나 작업 자체에는 HTTP 동사가 허용되는 매우 구체적인 요구 사항이 있습니다. 예를 들어 서비스에서 사용하는 데이터를 변경하는 기능은 POST를 통해서만 전송 될 수 있습니다. 특정 유형의 비 또는 낮은 권한 데이터 (예 : 동적으로 생성 된지도 이미지)에 대한 요청은 두 방법 중 하나의 요청에 대한 응답으로 제공 될 수 있습니다.

결론적으로 다음과 같은 간단한 규칙을 기억하십시오.

보안은 여러분이 만드는 것입니다!

편집하다:

나는 강하게 bobince의 충고를 추천 : 당신은 설정할 수있는 경우 request_order"GP"에 php.ini 파일에서 매개 변수를; 즉, 쿠키 구성 요소가 없습니다. 쿠키 데이터는 쿼리 문자열 또는 포스트 데이터와 비교할 수있는 것으로 간주되어서는 안되므로 98 % 이상의 경우에 대해 이에 대한 합리적인 이유가 거의 없습니다.

추신, 일화!

저는 $_REQUEST슈퍼 글로벌 방식으로 액세스 할 수있는 데이터를 간단히 저장할 수있는 장소를 생각한 프로그래머를 알고있었습니다 . 중요한 사용자 이름과 암호, 파일 경로, 이름을 지정하고 $_REQUEST. 그 변수가 어떻게 작동하는지 그에게 말했을 때 그는 약간 놀랐습니다 (비행하게도 우스꽝 스럽지는 않지만). 말할 필요도없이 그 관행은 폐지되었습니다.

GET 요청은 멱등이어야하며 POST 요청은 일반적으로 그렇지 않습니다. 데이터 있음이 수단 $_GET과는 $_POST일반적으로 다른 방법으로 사용되어야한다.

애플리케이션이의 데이터를 사용하는 경우 $_REQUESTGET 및 POST 요청 모두에 대해 동일하게 작동하여 GET의 멱 등성을 위반합니다.

모호합니다. 당신은하지 않습니다 정말 그 후, 얻고, 쿠키 데이터를 전달하기 때문에 데이터가 당신에 도착 방법을 알고있다. 전달 방법을 알거나 제한 할 필요 가 없는 한 이것이 항상 나쁜 것이라고 생각하지는 않습니다 .

나는 실제로 그것을 사용하는 것을 좋아합니다. 대부분의 시간 데이터가 POST되는 검색 양식과 같은 작업에 유용 할 수있는 GET 또는 POST를 사용할 수있는 유연성을 제공하지만 때로는 특정 검색에 대한 링크를 말하고 싶으므로 대신 GET 매개 변수를 사용할 수 있습니다. .

또한 다른 많은 언어 (예 : ASP.NET)를 살펴보면 GET과 POST 변수를 전혀 구분하지 않습니다.

ETA :

COOKIE 값을 얻기 위해 REQUEST를 사용한 적이 없지만 Kyle Butt가 이에 대한이 게시물의 댓글에서 훌륭한 지적을한다고 생각합니다. COOKIE 값을 얻기 위해 REQUEST를 사용하는 것은 좋은 생각이 아닙니다. 나는 그가 그렇게 할 경우 교차 사이트 요청 위조에 대한 실제 잠재력이 있다는 것이 옳다고 믿습니다.

또한 항목이 REQUEST에로드되는 순서는 php.ini (variables_order 및 request_order)의 구성 매개 변수에 의해 제어됩니다. 따라서 POST와 GET을 통해 동일한 변수가 전달 된 경우 실제로 REQUEST에 들어가는 변수는 해당 ini 설정에 따라 다릅니다. 특정 순서에 의존하고 해당 설정이 예상과 다르게 구성된 경우 이식성에 영향을 미칠 수 있습니다.

POST 사용시기, GET 사용시기 및 쿠키 사용시기를 이해하는 것이 중요합니다. $ _REQUEST를 사용하면보고있는 값이 이들 중 하나에서 나올 수 있습니다. POST, GET 또는 COOKIE에서 값을 가져 오려면 코드를 읽는 사람에게 $ _REQUEST 대신 특정 변수를 사용하는 것이 더 유익합니다.

다른 누군가는 또한 모든 POST 또는 쿠키가 GET에 의해 재정의되는 것을 원하지 않는다고 지적했습니다. 예를 들어 $ _REQUEST를 사용하는 동안 ajax 데이터를 반환하는 경우와 같이 모든 POST 또는 쿠키에 대해 서로 다른 교차 사이트 규칙이 있기 때문에 취약합니다. 교차 사이트 스크립트 공격에.

사용하는 유일한 시간 $_REQUEST은 GET을 사용하는 것입니다.

• POST 값을로드하는 데 사용하면 사이트 간 요청이 위조 될 위험이 있습니다.
• 쿠키 값을로드하는 데 사용하면 다시 사이트 간 요청이 위조 될 위험이 있습니다.

그리고 GET을 사용하더라도 $_GET입력하는 것이 더 짧습니다 $_REQUEST.)

현재 URL 또는 호스트 이름을 검색하려는 경우에만 사용할 수 있지만 실제로 & 기호를 사용하는 매개 변수와 같은 해당 URL에서 데이터를 구문 분석하는 데는 좋지 않을 수 있습니다. 일반적으로 수행하려는 작업에 대한 모호한 설명을 사용하고 싶지 않습니다. $ _REQUEST가 나쁜 부분을 구체적으로 지정해야한다면 구체적으로 지정할 필요가 없다면 자유롭게 사용하십시오. 나는 생각할 것이다.

원하는 데이터를 알고 있다면 명시 적으로 요청해야합니다. IMO, GET 및 POST는 서로 다른 두 동물이며 게시 데이터와 쿼리 문자열을 혼합해야하는 이유를 생각할 수 없습니다. 누군가 가지고 있다면 관심이있을 것입니다.

스크립트가 동일한 방식으로 GET 또는 POST에 응답 할 때 $ _REQUEST를 사용하는 것이 편리 할 수 ​​있습니다. 나는 이것이 극히 드문 경우 여야하며, 대부분의 경우 두 개의 개별 개념을 처리하는 두 개의 개별 함수 또는 최소한 방법을 확인하고 올바른 변수를 선택하는 것이 선호된다고 주장합니다. 프로그램 흐름은 일반적으로 변수의 출처를 상호 참조 할 필요가 없을 때 훨씬 쉽게 따라갈 수 있습니다. 6 개월 내에 코드를 유지해야하는 사람에게 친절하게 대하십시오. 당신 일 수도 있습니다.

REQUEST 변수의 쿠키 및 환경 변수로 인한 보안 문제 및 WTF 외에도 (GLOBAL에서 시작하지 마십시오) PHP가 기본적으로 PUT 및 DELETE와 같은 다른 방법을 지원하기 시작하면 향후에 발생할 수있는 일을 고려하십시오. 이것들이 REQUEST 수퍼 글로벌에 병합 될 가능성은 극히 적지 만 variable_order 설정의 옵션으로 포함될 수 있습니다. 따라서 REQUEST가 무엇을 보유하고 있는지, 특히 코드가 타사 서버에 배포 된 경우 우선 순위가 무엇인지 전혀 알 수 없습니다.

POST가 GET보다 안전합니까? 별로. 애플리케이션이 공격을 받았을 때 어떻게 악용되고 있는지 로그에서 확인하기 쉽기 때문에 실용적인 경우 GET을 사용하는 것이 좋습니다. POST는 일반적으로 스파이더가이를 따르지 않기 때문에 도메인 상태에 영향을 미치는 작업에 더 적합하며 예측 가져 오기 메커니즘은 CMS에 로그인 할 때 모든 콘텐츠를 삭제하지 않습니다. 그러나 질문은 GET 대 POST의 장점이 아니라 수신자가 수신 데이터를 처리하는 방법과 병합하는 것이 왜 나쁜지에 관한 것이기 때문에 실제로는 BTW입니다.

에는 문제가 없다고 생각 $_REQUEST하지만 3 가지 소스 (GPC)의 변수 모음이므로 사용시주의해야합니다.

나는 $_REQUEST여전히 오래된 프로그램을 새로운 PHP 버전과 호환되도록 만들 수 있다고 생각 하지만 새 프로젝트 (새 라이브러리 포함)를 시작 $_REQUEST하면 프로그램을 더 명확하게 만들기 위해 더 이상 사용해서는 안된다고 생각합니다 . 우리는 심지어의 용도를 삭제 고려해야 $_REQUEST하기 때문에, 특히 큰 제출 된 텍스트 데이터를 처리 할 때, 프로그램이 밝게 만들 래퍼 함수로 대체 $_REQUEST의 사본을 포함 $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Darren Cook : "php 5.3 이후 기본 php.ini는 GET 및 POST 데이터 만 GET 및 POST 데이터에 넣어 진다고 말합니다$_REQUEST . php.net/request_order를 참조하십시오. 쿠키 데이터가 들어올 것으로 예상하고 $_REQUEST왜 그렇지 않은지 궁금 할 때이 하위 호환성 문제를 발견 했습니다. 작동합니다! "

와우 ... PHP 5.3 업그레이드로 인해 일부 스크립트가 작동을 멈췄습니다 . 같은 일을했습니다 : $_REQUEST변수를 사용할 때 쿠키가 설정된다고 가정 합니다. 업그레이드로 정확히 작동이 중지되었습니다.

이제 쿠키 값을 별도로 호출합니다. $_COOKIE["Cookie_name"] ...를 .

핵심 문제는 다른 사람들이 말했듯이 쿠키가 포함되어 있다는 것입니다.

PHP 7에서는 다음을 수행 할 수 있습니다.

$request = array_merge($_GET ?? [], $_POST ?? []);

이것은 쿠키 문제를 피하고 최악의 경우 빈 배열을 제공하고 기껏해야 $ _GET과 $ _POST를 병합하고 후자가 우선합니다. 쿼리 문자열을 통해 매개 변수의 URL 삽입을 허용하는 데 너무 신경 쓰지 않는다면 매우 편리합니다.

매우 안전하지 않습니다. 또한 POST 또는 GET 또는 다른 요청을 받고 있는지 알지 못하기 때문에 어색합니다. 응용 프로그램을 디자인 할 때 그 차이를 알아야합니다. GET은 URL로 전달되기 때문에 매우 안전하지 않으며 페이지 탐색 외에는 거의 모든 것에 적합하지 않습니다. POST는 그 자체로도 안전하지는 않지만 한 수준의 안전을 제공합니다.