Що не так із використанням $ _REQUEST []?

Я бачив тут кілька публікацій, в яких говорилося, що не використовувати $_REQUESTзмінну. Я зазвичай ні, але іноді це зручно. Що з цим не так?

Там абсолютно нічого поганого з прийняттям вхід від обох $_GETі $_POSTкомбінованим способом. Насправді це ви завжди завжди хочете зробити:

• для простого ідентифікаційного запиту, який зазвичай надсилається через GET, є можливість, кількість потрібних даних не впишеться в URL-адресу, тому його буде замінено на запит POST, а не як практичне питання.

• для запиту, який має реальний ефект, ви повинні перевірити, чи подано він методом POST. Але спосіб зробити це - це $_SERVER['REQUEST_METHOD']чітко перевірити , а не покладатися на $_POSTте, що GET порожній. І в будь-якому випадку, якщо метод є POST, ви все-таки можете захопити деякі параметри запиту з URL-адреси.

Ні, проблема з цим $_REQUESTне має нічого спільного з плутанням параметрів GET і POST. Це те, що воно також за замовчуванням включає $_COOKIE. І файли cookie насправді зовсім не схожі на параметри подання форми: ви майже ніколи не хочете трактувати їх як одне і те ж.

Якщо ви випадково отримаєте на своєму веб-сайті набір файлів cookie з таким самим ім'ям, як один із параметрів форми, то форми, які покладаються на цей параметр, загадково перестануть працювати належним чином через значення cookie, що перевищують очікувані параметри. Це дуже просто зробити, якщо у вас є кілька додатків на одному веб-сайті, і ви можете налагодити їх дуже важко, коли у вас є лише кілька користувачів із старими файлами cookie, ви більше не використовуєте та не порушуєте форми так, як ні -інший може відтворити.

Ви можете змінити цю поведінку в набагато більш розумний GP(ні C) порядок за допомогою конфігурації request_order у PHP 5.3. Там, де це неможливо, я особисто уникав би, $_REQUESTі, якщо мені знадобиться комбінований масив GET + POST, створити його вручну.

Я переглянув кілька публікацій групи новин на PHP Internals та знайшов цікаву дискусію з цієї теми. Початкова тема була про щось інше, але зауваження Стефана Ессера, експерта з безпеки (якщо не цього ) у світі PHP, перетворило дискусію на наслідки для безпеки використання $ _REQUEST для кількох дописів.

Посилаючись на Стефана Ессера в PHP Internals

$ _REQUEST - одна з найбільших недоліків дизайну в PHP. Кожна програма, що використовує $ _REQUEST, найімовірніше, є вразливою до проблем із підпискою підписки на веб-сайті. (Це в основному означає, якщо наприклад, файл cookie з назвою (вік) існує, він завжди буде перезаписувати вміст GET / POST, і тому будуть виконуватися небажані запити)

і в наступній відповіді на ту саму нитку

Справа не в тому, що хтось може підробляти GET, POST; Змінні COOKIE Йдеться про те, що COOKIE замінять дані GET і POST у запиті.

Тому я міг заразити ваш веб-переглядач файлом cookie, в якому написано, наприклад, action = вихід, і з цього дня ви більше не зможете використовувати програму, оскільки ЗАПИТАННЯ [дія] буде виходити назавжди (поки ви вручну не видалите файл cookie).

А заразити вас COOKIE так просто ...
а) Я можу використовувати XSS vuln у будь-якій програмі піддомену
b) Коли б ви намагалися встановити cookie для * .co.uk або * .co.kr, коли ви володієте Єдиний домен там?
в) Інші міждоменні способи ...

І якщо ви вважаєте, що це не проблема, то я можу вам сказати, що існує проста можливість встановити cookie fe. * .Co.kr, що призводить до того, що кілька версій PHP просто повертають білі сторінки. Уявіть: лише один cookie, щоб знищити всі сторінки PHP у * .co.kr

І встановивши незаконне ідентифікатор сеансу у файлі cookie, дійсному для * .co.kr, у змінній під назвою + PHPSESSID = незаконний, ви все одно можете досипати кожен PHP-додаток у Кореї за допомогою PHP-сеансів ...

Обговорення триває ще кілька публікацій і цікаве для читання.

Як бачите, головна проблема з $ _REQUEST полягає не стільки в тому, що він має дані з $ _GET і $ _POST, а також з $ _COOKIE. Деякі інші хлопці зі списку запропонували змінити порядок заповнення $ _REQUEST, наприклад, спочатку заповнити його $ _COOKIE, але це може призвести до численних інших потенційних проблем, наприклад, при роботі з сеансом .

Ви можете повністю опустити $ _COOKIES з глобального $ _REQUEST, щоб він не був перезаписаний жодним з інших масивів (насправді ви можете обмежити його будь-якою комбінацією стандартного вмісту, як, наприклад, керівництво PHP про налаштування змінної порядку ini говорить нам:

varia_order Встановлює порядок розбору змінної EGPCS (Середовище, Get, Post, Cookie та Server). Наприклад, якщо для змінних_порядок встановлено значення "SP", PHP створить суперглобали $ _SERVER і $ _POST, але не створить $ _ENV, $ _GET і $ _COOKIE. Якщо встановити "", значить, суперглобали не будуть встановлені.

Але знову ж таки, ви також можете не використовувати $ _REQUEST взагалі, просто тому, що в PHP ви можете отримати доступ до середовища, Get, Post, Cookie та Server у власних глобальних мережах і мати на один вектор нападу менше. Вам все одно доведеться санітувати ці дані, але це турбується про одну меншу річ.

Тепер ви можете задатися питанням, чому все-таки існує $ _REQUEST і чому він не видаляється. Про це запитували і в PHP Internals. Посилаючись на Расмуса Лердорфа про те, чому існує $ _REQUEST? на внутрішній PHP

Чим більше таких матеріалів ми видаляємо, тим важче стає людям швидше переходити на новіші, швидші та безпечніші версії PHP. Це спричиняє більше розчарування для всіх, ніж кілька "потворних" спадкових функцій. Якщо є гідні технічні причини, продуктивність чи безпека, то нам потрібно уважно поставитися до цього. У цьому випадку ми повинні дивитись, чи не слід видаляти $ _REQUEST, а чи слід видаляти з нього дані cookie. Багато конфігурацій вже роблять це, включаючи всі мої власні, і є вагома вагома причина безпеки для невключення файлів cookie у $ _REQUEST. Більшість людей використовують $ _REQUEST, щоб позначати GET або POST, не розуміючи, що він також може містити файли cookie, і тому такі погані хлопці потенційно можуть робити певні трюки з ін'єкцією файлів cookie та порушувати наївні програми.

У будь-якому випадку, сподіваємось, що пролити трохи світла.

$_REQUESTстосується всіляких запитів (GET, POST тощо). Іноді це корисно, але зазвичай краще вказати точний метод ($ _GET, $ _POST тощо).

$_REQUEST як правило, вважається шкідливим з тієї ж причини, що перетворення даних простої до середньої складності часто виконується в коді програми, а не декларується в SQL: деякі програмісти висмоктуються.

Таким чином, якщо хтось прагне користуватися $_REQUESTскрізь, я можу зробити все, що я можу зробити через POST, що означає налаштування <img>тегів на моєму (зловмисному) сайті, що призводить до того, що користувачі, що увійшли до вашого модуля електронної комерції, купували продукти безшумно, або я може змусити їх натискати на посилання, що призведе до небезпечних дій або розкриття конфіденційної інформації (напевно, для мене).

Однак це відбувається через те, що новачок або, принаймні, недосвідчений, програміст PHP робить прості помилки. По-перше, дізнайтеся, коли дані відповідного типу підходять. Наприклад, у мене є веб-служба, яка може повертати відповіді в URLEncoding, XML або JSON. Додаток вирішує, як відформатувати відповідь, перевіривши заголовок HTTP_ACCEPT, але його можна примусити до одного, пересилаючи formatпараметр.

Під час перевірки вмісту параметра формату він може бути надісланий за допомогою запиту рядків або поштових даних, залежно від безлічі факторів, не менш важливим з яких є те, чи хоче виклик додатків "& 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 Verb . Наприклад, функції, які вносять зміни до даних, використовуваних службою, можуть надсилатися лише через POST. Запити щодо певних типів даних, що не належать до низьких чи низьких привілеїв (наприклад, динамічно генеровані зображення карти), можуть подаватися у відповідь на запити будь-якого методу.

На закінчення згадайте це просте правило:

БЕЗОПАСНІСТЬ, ЩО ВИ ЗДОРОВИТИ, ЛЮДИ!

Редагувати:

Я настійно рекомендую поради bobince: якщо ви можете, встановіть request_orderпараметр у php.ini на "GP"; тобто немає компонентів cookie. Раціональних міркувань для цього майже не існує в 98% + випадків, оскільки дані cookie майже ніколи не повинні вважатися порівнянними з рядком запитів або з даними.

PS, анекдот!

Я знав програміста, який придумав $_REQUESTмісце для простого зберігання даних, доступних у суперглобальний спосіб. Важливі імена користувачів та паролі, шляхи до файлів, ви їх називаєте і вони зберігалися $_REQUEST. Він трохи здивувався (хоча, на жаль, не так, на жаль), коли я розповів йому, як поводиться ця змінна. Зайве говорити, що ця практика була скинута.

GET-запити мають бути ідентичними, а POST-запити, як правило, ні. Це означає, що дані в $_GETта, $_POSTяк правило, повинні використовуватися по-різному.

Якщо ваша програма використовує дані з $_REQUEST, вона поводитиметься однаково як для запитів GET, так і для POST, що порушує ідентифікацію GET.

Це невиразно. Ви дійсно не знаєте, як отримані вами дані, оскільки вони містять дані про публікацію, отримання та файли cookie. Я не обов'язково думаю, що це завжди погано, якщо вам не потрібно знати або обмежувати спосіб доставки.

Мені справді подобається його використовувати. Це дає вам можливість використовувати GET або POST, що може стати в нагоді для таких речей, як форми пошуку, де більшість часу дані надсилаються, але іноді ви хочете сказати посилання на певний пошук, тому ви можете використовувати параметри GET .

Крім того, якщо ви подивитесь на багато інших мов (наприклад, ASP.NET), вони взагалі не роблять різниці між змінними GET та POST.

ETA :

Я ніколи не використовував ЗАПИТАННЯ, щоб отримати значення COOKIE, але я думаю, що Кайл Батт має велике значення в коментарях до цього поста про це. НЕ БЕЗПЕЧНО використовувати ЗАПИТУВАННЯ для отримання значень COOKIE. Я вважаю, що він правий, що існує певний потенціал для підроблення заявки на веб-сайт, якщо ви це зробите.

Крім того, порядок завантаження матеріалів у REQUEST контролюється параметрами конфігурації в php.ini (variables_order та request_order). Отже, якщо у вас одна і та ж змінна, передана через POST та GET, яка фактично потрапляє в ЗАПИТУВАННЯ, залежить від цих параметрів ini. Це може вплинути на портативність, якщо ви залежите від конкретного замовлення, і ці налаштування налаштовані інакше, ніж ви очікуєте.

Важливо зрозуміти, коли використовувати POST, коли використовувати GET і коли використовувати cookie. Завдяки $ _REQUEST значення, на яке ви дивитесь, могло походити з будь-якого з них. Якщо ви розраховуєте отримати значення від POST або GET або від COOKIE, тому, хто читає ваш код, більш інформативним буде використовувати конкретну змінну замість $ _REQUEST.

Хтось ще зазначив, що ви не хочете, щоб всі POST-файли та файли cookie перекривались GET, оскільки для них існують різні правила міжміського сайту, наприклад, якщо ви повертаєте дані ajax під час використання $ _REQUEST, ви вразливі на міжсайтовий напад сценарію.

Єдиний час використання $_REQUESTне поганої ідеї - це GET.

• Якщо ви використовуєте його для завантаження значень POST, ви ризикуєте підробляти запити на різних веб-сайтах
• Якщо ви використовуєте його для завантаження значень файлів cookie, ви знову ризикуєте підробляти запити на веб-сайті

І навіть з GET, $_GETвін коротший, ніж $_REQUEST;)

Я можу бути використаний лише в тому випадку, якщо ви хочете отримати поточний URL або ім'я хоста, але для фактичного розбору даних з такої URL-адреси, як парметри за допомогою символу &, це, мабуть, не дуже гарна ідея. Загалом, ви не хочете використовувати розпливчасте опис того, що ви намагаєтеся зробити. Якщо вам потрібно бути конкретним, саме там $ _REQUEST поганий, якщо вам не потрібно бути конкретним, тоді не соромтеся використовувати його. Я б подумав.

Якщо ви знаєте, які дані ви хочете, ви повинні прямо запитати їх. IMO, GET та POST - це дві різні тварини, і я не можу придумати вагому причину, чому вам коли-небудь знадобиться змішувати публікації даних та рядки запитів. Якщо у кого є, я був би зацікавлений.

Користуватися $ _REQUEST може бути зручно, коли ваші сценарії можуть відповідати GET або POST однаково. Хоча я заперечую, що це має бути надзвичайно рідкісним випадком, і в більшості випадків кращою є дві окремі функції для обробки двох окремих понять або, принаймні, для перевірки методу та вибору правильних змінних. За потоком програми, як правило, набагато простіше прослідкувати, коли не потрібно перетинати посилання, звідки можуть надходити змінні. Будьте ласкаві до людини, яка має підтримувати ваш код протягом 6 місяців. Це може бути ти.

На додаток до проблем із безпекою та WTF, спричинених файлами cookie та змінними середовища у змінній REQUEST (не запускайте мене з роботи на GLOBAL), подумайте, що може статися в майбутньому, якщо PHP почав підтримувати інші методи, такі як PUT та DELETE. Хоча вкрай малоймовірно, що вони були б об'єднані у суперГлобальний ЗАПИТАННЯ, можливо, вони можуть бути включені як параметр у налаштування змінної_порядку. Таким чином, ви дійсно не маєте уявлення про те, що має ЗАПИТ, і що має перевагу, особливо якщо ваш код розгорнуто на сторонній сервер.

POST безпечніше GET? Не зовсім. Краще використовувати GET там, де це практично, тому що у ваших журналах простіше бачити, як ваша програма експлуатується під час нападу. POST краще для операцій, які впливають на стан домену, оскільки павуки, як правило, не дотримуються їх, а механізми прогнозування вилучення не видалять весь ваш вміст, коли ви входите у свою CMS. Однак питання полягало не в достоїнствах GET проти POST, а в тому, як приймач повинен ставитись до вхідних даних і чому погано їх об’єднувати, тож це справді лише BTW.

Я думаю, що з цим немає проблем $_REQUEST, але ми повинні бути обережними при використанні, оскільки це сукупність змінних із трьох джерел (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; 
    } 
  }
}

Даррен Кук: "Оскільки в php 5.3 за умовчанням php.ini йдеться лише про отримання даних GET і POST $_REQUEST. Дивіться php.net/request_order, я просто натрапив на цю перерву сумісності, коли очікував, що дані cookie будуть введені, $_REQUESTі цікаво, чому це не було" т працює! "

Нічого ... просто деякі мої сценарії перестали працювати через оновлення до PHP 5.3 . Зробив те саме: припустимо, що cookie буде встановлено при використанні $_REQUESTзмінної. З оновленням саме воно перестало працювати.

Тепер я називаю значення файлів cookie окремо за допомогою $_COOKIE["Cookie_name"]...

Центральною проблемою є те, що воно містить файли cookie, як говорили інші.

У PHP 7 ви можете зробити це:

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

Це дозволяє уникнути проблеми з файлами cookie і дає вам у кращому випадку порожній масив, а в кращому випадку - злиття $ _GET і $ _POST, при цьому останні мають перевагу. Якщо ви не надто переймаєтеся можливістю введення URL-адреси параметрів через рядок запиту, це досить зручно.

Це дуже небезпечно. Крім того, це незручно, оскільки ви не знаєте, чи отримуєте ви пошту або отримання, чи інший запит. Ви дійсно повинні знати різницю між ними під час проектування своїх додатків. GET дуже небезпечний, оскільки передається в URL-адресі і не підходить для майже нічого, крім навігації по сторінках. POST, хоча сам по собі не є безпечним, забезпечує один рівень безпеки.