$ _REQUEST []를 사용하는 것이 잘못된 이유는 무엇입니까?

$ _REQUEST []를 사용하는 것이 잘못된 이유는 무엇입니까?

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

해결법

1. ==============================

   1.결합 된 방식으로 $ _GET와 $ _POST 모두에서 입력을받는 것은 전혀 잘못된 것이 아닙니다. 사실 그것이 거의 항상하고 싶은 일입니다.

   결합 된 방식으로 $ _GET와 $ _POST 모두에서 입력을받는 것은 전혀 잘못된 것이 아닙니다. 사실 그것이 거의 항상하고 싶은 일입니다.

   아니요, $ _REQUEST의 문제점은 GET 및 POST 매개 변수를 서로 관련시키는 것과 아무 관련이 없습니다. 기본적으로 $ _COOKIE도 포함되어 있습니다. 그리고 쿠키는 실제로 양식 제출 매개 변수와 전혀 다른 것입니다. 당신은 거의 같은 것을 취급하고 싶지 않습니다.

   실수로 양식 매개 변수 중 하나와 같은 이름으로 사이트에 쿠키 세트를 가져 오면 해당 매개 변수에 의존하는 양식이 예상 매개 변수를 무시하는 쿠키 값으로 인해 올바로 작동하지 않게됩니다. 이것은 동일한 사이트에 여러 개의 앱이있는 경우 매우 쉽게 처리 할 수 ​​있으며 더 이상 사용하지 않는 오래된 쿠키가있는 사용자가 두 명뿐 일 때 디버깅하기가 매우 어려울 수 있습니다. 다른 사람도 재현 할 수 있습니다.

   PHP 5.3에서 request_order 설정으로이 동작을 훨씬 더 합리적인 GP (no C) 순서로 변경할 수 있습니다. 이것이 가능하지 않은 곳에서는 개인적으로 $ _REQUEST를 피할 것이고, GET + POST 배열을 결합해야한다면 수동으로 생성해야합니다.

2. ==============================

   2.필자는 PHP Internals의 뉴스 그룹 게시물을 파헤 치고이 주제에 대한 흥미로운 토론을 발견했습니다. 초기 스레드는 다른 것에 관한 것이었지만 PHP 세계의 보안 전문가 인 Stefan Esser의 말에 따르면 몇 가지 게시물에 대해 $ _REQUEST를 사용하는 보안 의미에 대한 논의가 이루어졌습니다.

   필자는 PHP Internals의 뉴스 그룹 게시물을 파헤 치고이 주제에 대한 흥미로운 토론을 발견했습니다. 초기 스레드는 다른 것에 관한 것이었지만 PHP 세계의 보안 전문가 인 Stefan Esser의 말에 따르면 몇 가지 게시물에 대해 $ _REQUEST를 사용하는 보안 의미에 대한 논의가 이루어졌습니다.

   PHP Internals에서 Stefan Esser를 인용

   나중에 같은 스레드에 대한 응답으로

   토론은 몇 가지 더 많은 게시물에 대해 계속되며 재미있는 읽을 수 있습니다.

   보시다시피, $ _REQUEST의 주된 문제점은 $ _GET 및 $ _POST의 데이터뿐만 아니라 $ _COOKIE의 데이터도 너무 많지 않습니다. 목록에있는 다른 사람들은 $ _REQUEST가 채워진 순서 변경을 제안했습니다. 먼저 $ _COOKIE로 채우지 만, 이는 세션 처리와 같이 다른 많은 잠재적 인 문제를 일으킬 수 있습니다.

   당신은 $ _REQUEST 전역에서 $ _COOKIES를 완전히 생략 할 수 있습니다. 그래서 다른 배열들에 의해 겹쳐 쓰여지지 않습니다 (사실, variable_order ini 설정의 PHP 매뉴얼과 같은 표준 내용의 조합으로 그것을 제한 할 수 있습니다). 우리에게 말해:

   그러나 다시 한번 PHP에서 여러분은 자신의 전역에서 Environment, Get, Post, Cookie 및 Server에 액세스하고 하나의 공격 벡터를 덜 가질 수 있기 때문에 $ _REQUEST를 전혀 사용하지 않을 수도 있습니다. 여전히이 데이터를 위생 처리해야하지만 걱정할 필요가 없습니다.

   이제 $ _REQUEST가 왜 결국 존재하고 왜 제거되지 않는지 궁금해 할 것입니다. 이것은 PHP Internals에서도 묻습니다. Rasmus Lerdorf를 인용하여 $ _REQUEST가 왜 존재합니까? PHP 내부에서

   어쨌든, 약간의 빛을 비추는 희망.

3. ==============================

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

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

4. ==============================

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

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

   따라서 어디서나 $ _REQUEST를 사용하는 경향이 있다면 POST를 통해 할 수있는 모든 것을 GET을 통해 할 수 있습니다. 즉, 전자 상거래 모듈에 로그인 한 사용자가 구매하도록하는 (악의적 인) 사이트에 태그를 설정하는 것을 의미합니다 제품을 자동으로 설치하거나 위험한 행동이나 민감한 정보의 노출로 이어질 수있는 링크를 클릭하게 할 수 있습니다.

   그러나 이것은 초보자 또는 최소한 경험이 부족한 PHP 프로그래머가 실수를 저질렀 기 때문에 발생합니다. 우선, 어떤 유형의 데이터가 적절한 지 알 수 있습니다. 예를 들어 URLEncoding, XML 또는 JSON으로 응답을 반환 할 수있는 웹 서비스가 있습니다. 응용 프로그램은 HTTP_ACCEPT 헤더를 검사하여 응답의 형식을 지정하는 방법을 결정하지만 특히 format 매개 변수를 전송하여 강제로 지정할 수 있습니다.

   format 매개 변수의 내용을 검사 할 때 호출하는 응용 프로그램이 요청과 함께 "& format = json"을 원하는지 여부와 상관없이 많은 요인에 따라 querystring 또는 postdata를 통해 전송할 수 있습니다. 이 경우, $ _REQUEST는 다음과 같이 타이핑 할 필요가 없기 때문에 매우 편리합니다 :

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

   나는 더 멀리 나아갈 생각은 없지만, $ _REQUEST 사용은 본질적으로 위험하기 때문에 설득력을 잃지 않는다고 말하면됩니다. 그것은 그 의미를 이해하든 그렇지 않든간에 정확하게 묻히는 것을 수행하는 또 다른 도구 일뿐입니다. 이 문제를 일으키는 가난하고, 게으르고, 경험이없는 프로그래머의 가난하고, 게으르고, 알지 못하는 결정입니다.

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

   나는 bobince의 충고를 강력히 추천한다. 가능한 경우 php.ini의 request_order 매개 변수를 "GP"로 설정한다. 즉, 쿠키 구성 요소가 없습니다. 쿠키 데이터는 거의 쿼리 문자열이나 postdata와 비교할 수 없어야하기 때문에 98 % 이상의 경우에는 합리적인 근거가 거의 없습니다.

   추신, 일화!

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

5. ==============================

   5.GET 요청은 멱등원이어야하며 POST 요청은 일반적으로 필요하지 않습니다. 즉, $ _GET 및 $ _POST의 데이터는 일반적으로 다른 방식으로 사용해야합니다.

   GET 요청은 멱등원이어야하며 POST 요청은 일반적으로 필요하지 않습니다. 즉, $ _GET 및 $ _POST의 데이터는 일반적으로 다른 방식으로 사용해야합니다.

   응용 프로그램이 $ _REQUEST의 데이터를 사용하는 경우 GET 및 POST 요청에 대해 동일한 동작을 수행하므로 GET의 멱등 원 (Idempotence)을 위반하게됩니다.

6. ==============================

   6.그것은 막연합니다. 게시, 가져 오기 및 쿠키 데이터를 가지고 있기 때문에 데이터가 실제로 어떻게 전달되었는지 알지 못합니다. 나는 당신이 배달 방법을 알거나 제한 할 필요가 없다면, 항상 나쁜 것이라고 생각하지 않습니다.

   그것은 막연합니다. 게시, 가져 오기 및 쿠키 데이터를 가지고 있기 때문에 데이터가 실제로 어떻게 전달되었는지 알지 못합니다. 나는 당신이 배달 방법을 알거나 제한 할 필요가 없다면, 항상 나쁜 것이라고 생각하지 않습니다.

7. ==============================

   7.나는 그것을 실제로 사용하는 것을 좋아한다. 그것은 GET이나 POST를 사용할 수있는 유연성을 제공합니다. 대부분의 시간 데이터가 POST 된 검색 양식과 같이 유용 할 수 있습니다. 그러나 때로는 특정 검색에 대한 링크를 말하기를 원하기 때문에 대신 GET 매개 변수를 사용할 수 있습니다 .

   나는 그것을 실제로 사용하는 것을 좋아한다. 그것은 GET이나 POST를 사용할 수있는 유연성을 제공합니다. 대부분의 시간 데이터가 POST 된 검색 양식과 같이 유용 할 수 있습니다. 그러나 때로는 특정 검색에 대한 링크를 말하기를 원하기 때문에 대신 GET 매개 변수를 사용할 수 있습니다 .

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

   도착 예정 시간 :

   나는 COOKIE 값을 얻기 위해 요청한 적이 없지만 카일 엉덩이가이 게시물에 대한 의견에 큰 비중을 둔다고 생각합니다. COOKIE 값을 얻기 위해 REQUEST를 사용하는 것은 좋지 않습니다. 나는 당신이 그렇게한다면 크로스 사이트 요청 위조에 대한 실질적인 잠재력이 있음이 옳다고 믿습니다.

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

8. ==============================

   8.POST를 사용할시기, GET을 사용하는시기 및 쿠키를 사용하는시기를 이해하는 것이 중요합니다. $ _REQUEST를 사용하면 원하는 값을 얻을 수 있습니다. POST 또는 GET 또는 COOKIE에서 값을 얻으려는 경우 코드를 읽는 사람에게 $ _REQUEST 대신 특정 변수를 사용하는 것이 더 유익합니다.

   POST를 사용할시기, GET을 사용하는시기 및 쿠키를 사용하는시기를 이해하는 것이 중요합니다. $ _REQUEST를 사용하면 원하는 값을 얻을 수 있습니다. POST 또는 GET 또는 COOKIE에서 값을 얻으려는 경우 코드를 읽는 사람에게 $ _REQUEST 대신 특정 변수를 사용하는 것이 더 유익합니다.

   다른 사람들은 POST에 대한 모든 크로스 사이트 규칙이 있기 때문에 모든 POST 또는 쿠키가 GET에 의해 무시되기를 원하지 않는다고 지적했습니다. 예를 들어, $ _REQUEST를 사용하는 동안 ajax 데이터를 반환하면 취약합니다 크로스 사이트 스크립트 공격.

9. ==============================

   9.$ _REQUEST를 사용하는 유일한 방법은 GET을 사용하는 것이 좋습니다.

   $ _REQUEST를 사용하는 유일한 방법은 GET을 사용하는 것이 좋습니다.

   그리고 GET을 사용하더라도 $ _GET은 $ _REQUEST보다 더 짧습니다;)

10. ==============================

    10.현재 URL 또는 호스트 이름을 검색하려는 경우에만 사용할 수 있지만 실제로 &를 사용하여 매개 변수와 같은 해당 URL의 데이터를 구문 분석하는 것은 좋은 생각이 아닙니다. 일반적으로, 당신은 당신이하려고하는 것에 대한 모호한 설명을 사용하고 싶지 않습니다. 구체적으로 $ _REQUEST가 나쁘다면 특별히 필요하지 않다면 자유롭게 사용하십시오. 나는 생각할 것이다.

    현재 URL 또는 호스트 이름을 검색하려는 경우에만 사용할 수 있지만 실제로 &를 사용하여 매개 변수와 같은 해당 URL의 데이터를 구문 분석하는 것은 좋은 생각이 아닙니다. 일반적으로, 당신은 당신이하려고하는 것에 대한 모호한 설명을 사용하고 싶지 않습니다. 구체적으로 $ _REQUEST가 나쁘다면 특별히 필요하지 않다면 자유롭게 사용하십시오. 나는 생각할 것이다.

11. ==============================

    11.원하는 데이터를 알고 있다면 명시 적으로 요청해야합니다. IMO, GET 및 POST는 두 개의 다른 동물이며 게시 데이터와 검색어 문자열을 혼합해야하는 이유에 대해 생각할 수 없습니다. 누군가가 있다면, 나는 흥미가있을거야.

    원하는 데이터를 알고 있다면 명시 적으로 요청해야합니다. IMO, GET 및 POST는 두 개의 다른 동물이며 게시 데이터와 검색어 문자열을 혼합해야하는 이유에 대해 생각할 수 없습니다. 누군가가 있다면, 나는 흥미가있을거야.

    스크립트가 GET 또는 POST에 동일한 방식으로 응답 할 때 $ _REQUEST를 사용하는 것이 편리 할 수 ​​있습니다. 나는 이것이 극히 드물기는하지만, 대부분의 경우 두 개의 분리 된 개념을 다루는 두 개의 분리 된 함수가 있거나 최소한 메소드를 점검하고 올바른 변수를 선택하는 것이 바람직하다고 주장 할 것이다. 프로그램 흐름은 일반적으로 변수가 오는 곳을 참조 할 필요가 없을 때 따를 것이 훨씬 쉽습니다. 6 개월 내에 코드를 유지해야하는 사람에게 친절하십시오. 너일지도 몰라.

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

    POST는 GET보다 안전합니까? 그렇지 않아. 실용적인 경우 GET을 사용하는 것이 좋습니다. 왜냐하면 공격을 당했을 때 응용 프로그램이 어떻게 악용되고 있는지 로그에서 쉽게 볼 수 있기 때문입니다. POST는 도메인 상태에 영향을주는 작업에 더 좋으며 일반적으로 스파이더는이를 따르지 않으므로 예측 가져 오기 메커니즘은 CMS에 로그인 할 때 모든 콘텐츠를 삭제하지 않습니다. 그러나 문제는 GET 대 POST의 장점에 관한 것이 아니라 수신자가 수신 데이터를 처리해야하는 이유와 병합하는 것이 나쁜 이유였습니다. 따라서 이것이 실제로 BTW입니다.

12. ==============================

    12.나는 $ _REQUEST에 아무런 문제가 없다고 생각하지만, 3 개의 소스 (GPC)에서 나온 변수의 모음이기 때문에 사용할 때주의해야한다.

    나는 $ _REQUEST에 아무런 문제가 없다고 생각하지만, 3 개의 소스 (GPC)에서 나온 변수의 모음이기 때문에 사용할 때주의해야한다.

    나는 $ _REQUEST가 새로운 PHP 버전과 호환되는 오래된 프로그램을 만들 수 있다고 생각하지만 새 프로젝트 (새 라이브러리 포함)를 시작하면 프로그램을보다 명확하게하기 위해 $ _REQUEST를 더 이상 사용하지 않아야한다고 생각합니다. $ _REQUEST가 $ _POST의 복사본을 포함하고 있기 때문에, 특히 $ _REQUEST의 사용을 삭제하고 래퍼 함수로 바꾸어 프로그램을 가볍게 만드는 것을 고려해야합니다.

    // 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; 
        } 
      }
    }
    

13. ==============================

    13.와우 ... 방금 PHP 5.3으로 업그레이드하여 일부 스크립트가 작동을 멈췄습니다. 같은 일을 했습니까? $ _REQUEST 변수를 사용할 때 쿠키가 설정된다고 가정하십시오. 업그레이 드와 정확히 그 일을 멈췄다.

    와우 ... 방금 PHP 5.3으로 업그레이드하여 일부 스크립트가 작동을 멈췄습니다. 같은 일을 했습니까? $ _REQUEST 변수를 사용할 때 쿠키가 설정된다고 가정하십시오. 업그레이 드와 정확히 그 일을 멈췄다.

    $ _COOKIE [ "Cookie_name"]을 사용하여 쿠키 값을 별도로 호출합니다 ...

14. ==============================

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

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

from https://stackoverflow.com/questions/2142497/whats-wrong-with-using-request by cc-by-sa and MIT license