Фильтрация входных данных пользователя PHP для отправки в базу данных MySQL - рекомендации

0

Я строю класс для фильтрации данных и собираю различные рекомендации.

Это в первую очередь для того, чтобы избежать ошибочных данных из пользовательского ввода в базу данных, а также для дополнительного уровня, который поможет предотвратить еще не задумывавшиеся о типах инъекционных атак и т.д. (ПРИМЕЧАНИЕ: это НЕ заменяет необходимость использовать подготовленные операторы с любыми данными отправлено в базу данных.)

Насколько это возможно, я не хочу возвращать ошибку, я хочу "заставить данные работать". Предполагая, что кто-то случайно набрал; или 'и т.д. в поле ввода, где оно не может быть принято. Или оставить в тысячах разделителей (,) в количестве, где их не должно быть. Так что просто возьми и продолжай.

Я хотел показать это другим, чтобы их критиковали и использовали. Я знаю, что есть другие вопросы об этом типе вещей, но я не видел ни одного с объединенной рекомендацией для различных типов.

Мой вопрос - что бы вы сделали по-другому? Будете ли вы беспокоиться о том, что пользователи вводят число, например "47387.284.02"? Если так, как я мог бы устранить вторую точку (десятичную точку, точку) и все после? (Хотя по-прежнему допускаются такие номера, как ".75" и "10.20")

// Use for numbers - integers, floats
function filterNumbers($data) {
    $data = trim(htmlentities(strip_tags($data)));
    $data = preg_replace('/[^.0-9]/', "", $data); // only numeric values allowed (and decimal point)
    $data = filter_var($data, FILTER_SANITIZE_NUMBER_FLOAT,FILTER_FLAG_ALLOW_FRACTION);
    $data = mysqli_real_escape_string($GLOBALS['con2'], $data);
    return $data;
}

// Use for short strings - alphanumeric only - usernames, varieties, etc.
function filterExtreme($data) {
    $data = trim(htmlentities(strip_tags($data)));
    $data = preg_replace('/[^ ._A-Za-z0-9]/', "", $data);
    $data = mysqli_real_escape_string($GLOBALS['con'], $data);
    return $data;
}

// Use for email addresses
function filterEmail($data) {
    $data = filter_var($data, FILTER_SANITIZE_EMAIL);
    $data = mysqli_real_escape_string($GLOBALS['con'], $data);
    return $data;
}

// Use for comments where some special characters may be desired
function filterComment($data) {
    $data = trim(htmlentities(strip_tags($data)));
    $data = filter_var($data, FILTER_SANITIZE_STRING,FILTER_FLAG_ENCODE_HIGH);
    $data = mysqli_real_escape_string($GLOBALS['con'], $data);
    return $data;
}

Примечание: $ con - это детали подключения к базе данных MySQL.

  • 0
    Честно говоря, я бы не стал пытаться «заставить это работать» в отношении чисел, потому что пользователи всегда будут придумывать новые способы ввода неверных данных, и тогда вам придется объяснить, почему ваша система обрабатывает некоторые типы недействительных данных, но не их последняя попытка неверных данных. Ради бога, не нужно слишком много просить кого-то ввести правильный номер .
  • 0
    Также, если вы используете параметризованные операторы, вы НЕ должны использовать mysqli_real_escape_string() , потому что в итоге вы получите данные, хранящиеся в вашей базе данных, включая буквенные escape-символы обратной косой черты.
Показать ещё 2 комментария
Теги:
filtering

1 ответ

0

Вы правы в том, что вас беспокоит правильность ввода данных, но я согласен с комментариями Билла Карвина выше (я не могу комментировать из-за своего представителя). Не существует способа узнать намерения пользователя, поэтому "заставить его работать" может в конечном итоге ухудшить ситуацию. Если они ввели ';' тогда, возможно, они тоже что-то неправильно поняли.

Предотвращение ввода нежелательных символов должно быть максимально обработано через интерфейс, а ваш внутренний код должен просто проверяться на соответствие. Если это не удастся, верните код ошибки и разрешите клиентскому интерфейсу справиться с этим.

Снятие запятых с чисел или обрезка пробелов, вероятно, не так уж и плохо, но это также то, что я постараюсь использовать по возможности спереди. Вы просто должны иметь дело с этим по мере необходимости.

  • 0
    Я согласен с @Amesh, но мне не нравится просто проверять данные на внешнем интерфейсе. Мне нравится обрабатывать его на внешнем интерфейсе (HTML5 / JavaScript), на уровне PHP и снова с правильно установленными столбцами SQL; так что плохие данные имеют небольшой шанс попасть в базу данных.
  • 0
    Если у вас есть полный контроль над передней и задней частью, то у вас больше свободы для обработки данных, которые вы описываете. В моем случае я ограничиваю ввод данных в интерфейсе любыми допустимыми символами (через регулярное выражение в JavaScript), а в фоновом режиме я проверяю, что это «законно» перед фиксацией. Вы знаете свою аудиторию лучше, чем кто-либо. Мои проекты являются внутренними и частными, поэтому я знаю своих пользователей достаточно хорошо, но если вы общаетесь с публикой, все может быть по-другому, и вы должны делать все, что наиболее целесообразно для вашего проекта. По крайней мере, вы обращаете на это внимание!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню