Использует ли extract($_POST) неуверенно? Если да, то что я могу сделать по этому поводу?
Да. Это то же самое, что и register_globals. Это означает, что если кто-то введет значение с именем «my_name», будет существовать переменная «my_name». И если он существует, он может привести к $my_name проблемы с мусором или безопасностью в вашем скрипте, если где-то вы используете переменную $my_name
Из документации php:
Не используйте extract () на ненадежных данных, например, пользовательский ввод (т.е. $ _GET, $ _FILES и т. Д.). Если вы это сделаете, например, если вы хотите временно запустить старый код, который временно использует register_globals, убедитесь, что вы используете одно из значений, не переписывающих extract_type, таких как EXTR_SKIP, и имейте в виду, что вы должны извлекать в том же порядке, который определен в переменных_order внутри php.ini.
Рекомендуемая практика заключается в том, чтобы напрямую использовать $_POST[<varname>] , чтобы пользователи вашего сайта не могли устанавливать переменные, которые должны быть «безопасными»,
Всегда лучше читать значения из $_POST и делать с ними что-то, а не просто подвергать их переменным и рисковать переопределять некоторые из ваших …
Да, это небезопасно. Любой может переопределить локальные переменные (например, $password или $access_level ).
Я рекомендую объявлять и присваивать свои собственные локальные переменные следующим образом:
$var1 = isset($_POST['field_1'])?$_POST['field_1']:null; $var2 = isset($_POST['field_2'])?$_POST['field_2']:null; $var3 = isset($_POST['field_3'])?$_POST['field_3']:null;
Использование extract($_POST) небезопасно, как заявили другие. Вы спросили, что вы можете сделать, чтобы сделать extract($_POST) безопасным, в частности, чтобы избежать постоянной ссылки на массив $_POST .
Вы попросили безопасно использовать extract($_POST) . Это несколько безопасно использовать в качестве первой строки вашего скрипта, до того, как были определены локальные переменные, или с помощью EXTR_PREFIX_ALL и префикса. В обоих случаях, однако, вы делаете рискованную азартную игру, что вы никогда не сможете случайно ввести отверстие безопасности через опечатку в любом месте этой переменной. Глобальный охват чрезвычайно трудно проверить. Поскольку все программисты делают опечатки и неудобства минимальны, большинство программистов настоятельно рекомендуют никогда не extract() ненадежный контент, независимо от ограниченного объема, префиксов и т. Д.
Данные $_POST ed ненадежны и небезопасны. Вы никогда не знаете, что он может содержать, или если он даже будет установлен. Полезно думать, что $_POST это «испорченные» данные, которые должны быть «очищены» перед назначением локальной переменной. В результате вы можете свести к минимуму ввод « $_POST » путем проверки ввода, когда вы назначаете его локальным переменным. PHP 5.2 и выше делают это проще с filter_input() и filter_var() с фильтрами проверки.
В стороне, вы всегда должны проверять свои входы и дезинфицировать ваши результаты. Если вы вместо этого дезинфицируете свои входы, вы можете столкнуться с проблемами, отображающими их в разных контекстах (т. Е. Не-HTML-регистратор, печать на терминал). Если вы не дезинфицируете свои результаты, вы запускаете XSS, SQL Injection и т. Д.
Эмпирическое правило, поощряемое этим мышлением, заключается в том, чтобы обрабатывать все данные, поступающие в вашу систему, от другого, которого вы не контролируете как «испорченного», ненадежного – вы, вероятно, не контролируете систему, выполняющую веб-браузер, если не разрабатываете для локальной сети. Кроме того, «углубленная защита» поощряет рассмотрение даже доверенных систем как компромиссное (это происходит), что делает эту наиболее оптимальную практику для программистов.