Не обращайтесь к суперглобальному массиву $_REQUEST напрямую

До сих пор я обращался к $_REQUEST в моем PHP следующим образом:

//JS
xmlhttp.open("GET", "logic.php?q=" + itemOne  + "&w=" + itemTwo, true);

//PHP
$q = $_REQUEST['q'];
$w = $_REQUEST['w'];

Отправляемые элементы используются для запросов сервера MSSQL (SQLSRV).

Мой вопрос заключается в том, как лучше всего сделать вышеперечисленное по-другому/правильно? Я где-то читал, что это нехорошо с точки зрения уязвимости к атакам с внедрением SQL и т. д.


netbeans php sqlsrv superglobals
person BernardV    schedule 18.07.2016    source источник
comment
это совершенно нормально с использованием $_REQUEST. вы должны быть осторожны с запросами. просто используйте запрос ajax get/post для него.   -  person Bhavin    schedule 18.07.2016
comment
По этому коду невозможно сказать, уязвим он или нет для sql-инъекций. Но взгляните на Как я могу предотвратить SQL-инъекцию в PHP?< /а>   -  person FirstOne    schedule 18.07.2016
comment
Дополнительное примечание заключается в том, чтобы использовать «правильный» глобальный в соответствии с запросом. Если вы seding post, доступ к переменным из $_POST, если get, то $_GET. Взгляните на Что не так с использованием $_REQUEST[]?   -  person FirstOne    schedule 18.07.2016

Ответы (1)


arrow_upward
1
arrow_downward

Мой вопрос в том, каковы были бы наилучшие методы для выполнения вышеизложенного по-другому/правильно?

В приведенном вами примере JavaScript используется запрос GET. "Правильный" способ доступа к параметрам - через PHP-массив $_GET. Использование $_REQUEST — плохая привычка, потому что вы теряете контроль над тем, как поступают данные. Я приведу простой пример:

Веб-сайты, использующие аутентификацию на базе токенов, часто требуют, чтобы вы отправляли токен в виде POST данных. Если считается небезопасным обмениваться личной информацией через параметр URL, PHP-скрипт, который получает данные от $_REQUEST, не может узнать, как данные поступили, и по ошибке примет плохо отправленный токен. Лучший сценарий будет искать токен в $_POST. Если его нет, то нет и токена; даже если пользователь пытался отправить его в URL-адресе.

Я где-то читал, что это нехорошо с точки зрения уязвимости к атакам SQL-инъекций и т. Д.

Внедрение SQL не имеет отношения конкретно к $_REQUEST. Это может произойти всякий раз, когда вы вставляете данные, отправленные пользователем, непосредственно в свои SQL-запросы, независимо от того, были ли данные получены из $_REQUEST, $_GET, файла... Этот ужасный дизайн кода позволяет злоумышленнику получить контроль над вашим SQL и поручить вашей БД выполнить любую команду он или она желает (например: эксфильтровать или удалить ваши данные). Чтобы защитить себя от этого, узнайте о подготовленных операторах и параметризованных запросах.

person BeetleJuice    schedule 18.07.2016
comment
Спасибо за ответ! Я посмотрю на правильное использование массива $_GET. Хорошо, я думаю, к счастью, с точки зрения SQL-инъекции, тогда со мной все должно быть в порядке, поскольку я: параметры c) пользователь MSSQL, с которым я вхожу в систему, может только читать данные из БД. - person BernardV; 18.07.2016
comment
Если мое решение ответило на ваш вопрос, выберите его! :-) Вы должны думать о проверке интерфейса как об удобной услуге для пользователя, а не о функции безопасности для сервера. Это связано с тем, что очень легко отправлять http-запросы на ваш сервер, используя неверные параметры, даже не используя ваш интерфейсный сайт. - person BeetleJuice; 18.07.2016
comment
Спасибо! Я сделаю так! Только с точки зрения правильного использования $_GET ниже выглядит лучше? $_GET["q"] = $q; $_GET["w"] = $w; - person BernardV; 18.07.2016
comment
Обычно бывает наоборот. Не $_GET["q"]=$q, а $q=$_GET['q'], потому что вы пытаетесь прочитать значения, которые PHP поместил в $_GET, когда браузер отправил данные на сервер, и сохранить эти значения в локальных переменных (например: $q) - person BeetleJuice; 18.07.2016
comment
Когда я это делаю, Netbeans говорит: Do not Access Superglobal $_GET Array Directly. Use some filtering functions instead (e.g. filter_input(), conditions with is_*() functions, etc.). - person BernardV; 18.07.2016
comment
Это не сообщение от PHP. Это ваш редактор кода пытается выработать у вас хорошие привычки. Это хорошее напоминание о том, что вы должны рассматривать входящие данные как ненадежные. - person BeetleJuice; 18.07.2016
comment
Давайте продолжим обсуждение в чате. - person BernardV; 18.07.2016