Недостатки пространств обрезки из _Request, _Post и _Get?
У меня проблема с довольно большой платформой, где пользователи могут вводить данные, которые содержат пробелы в начале и в конце ввода. Это вызывает проблемы. Я знаю, что могу изменить проверку JavaScript, но на этом сайте огромное количество страниц и форм. Поиск и изменение каждого события было бы кошмаром.
Поскольку все формы и страницы совместно используют index.php, я подумал об идее перехвата переменных request / get / post до того, как платформа обработает любой контроллер / обработку маршрутизации.
Примечание: я знаю, что это очень дешевый способ сделать это. Но действия должны быть предприняты немедленно, пока я, по крайней мере, не смогу сделать это правильно. Это прекрасно работает, как есть. У меня просто пара проблем.
$_REQUEST = array_map('trim',$_REQUEST);
$_GET = array_map('trim',$_GET);
$_POST = array_map('trim',$_POST);
-
Существуют ли какие-либо действительные законные сценарии, в которых этот код будет содержать ошибку?
-
Есть ли значительный удар по производительности?
-
Есть ли недостатки безопасности?
-
Существуют ли риски нарушения целостности данных с помощью trim ()?
Решение
- Я не могу думать ни о чем. Обрезка будет просто обрезать начальные и конечные пробелы строки. Тем не менее, он не будет работать на вложенных массивах.
- Это, конечно, влияет на производительность, но это не главное. Однако обратите внимание, что это выполняется при каждом отдельном вызове index.php, даже если не было данных поста.
- Отделка не вызовет недостатков безопасности. Если вы проверяете и дезинфицируете пользовательский ввод на последних страницах, где вы форматируете данные, то их не должно быть.
- Я не могу ответить на этот вопрос без дальнейшего знания.
Если это только временный обходной путь, то он сделает эту работу. Но я не буду продолжать делать это вечно, и я предлагаю вам исправить это поле за полем, когда вы можете.
Другие решения
Ну это ОПАСНАЯ и я бы НЕ рекомендую это.
Вот почему:
Если на какой-либо из страниц есть формы, и они содержат пароль-поля тогда пользователи могут выбрать пароли, которые начинаются или заканчиваются пробелами! (да, пробелы в пароле абсолютно нормальны, потому что вы все равно собираетесь шифровать пароль).
Итак, проблема в том, что:
Если после этого вы удалите все начальные и конечные пробелы, то пользователь, уже вошедший в систему с таким паролем, больше не сможет войти в систему (потому что каждый раз, когда он пытается ввести свой действительный пароль (который начинается или заканчивается пробелами) Ваш подход собирается УДАЛИТЬ эти пробелы. Хотя ему нужны эти пробелы, чтобы войти).
Кроме того, новый пользователь, который пытается создать новую учетную запись с паролем, который начинается или заканчивается пробелами, никогда не сможет войти в систему когда-либо. Потому что он даже не ЗНАЕТ, что его пароль был урезан.
Так что честно: будьте осторожны с такими вещами!