Может ли это быть эффективным и надежным способом очистки ввода пользователя? - PullRequest
0 голосов
/ 27 апреля 2009

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

in-mynumber
tx-name
ph-phone
em-email

Итак, в верхней части моих скриптов я просто запускаю функцию (например):

function cleanInputs(){
    foreach($_GET AS $taintedKey => $taintedValue){
        $prefix = substr($taintedKey, 0, 2);
        switch($prefix){
            case 'in':
                //I assume this input is an integer
                $cGet[$taintedKey] = intval($taintedValue);
                break;
            case 'tx':
                //i assume this input is a normal text
                //can contains onely letters, numbers and few symbols
                if(preg_match($regExp, $taintedValue)){
                    $cGet[$taintedKey] = $taintedValue;
                }else{
                    $cGet[$taintedKey] = false;
                }
                break;
            case 'em':
                //i assume this input is a valid email
                if(preg_match('/^[a-zA-Z0-9-_.]+@[a-zA-Z0-9-_.]+.[a-zA-Z]{2,4}$/', $taintedValue)){
                    $cGet[$taintedKey] = $taintedValue;
                }else{
                    $cGet[$taintedKey] = false;
                }
                break;
        }
    }
}

.. поэтому я создам 2 других массива, $ cGet и $ cPost с чистыми данными соответственно $ _GET и $ _POST, и в моем скрипте я посмотрю на использование этих массивов, полностью забуду $ _GET / $ _СООБЩЕНИЕ Я даже думаю о добавлении второго префикса, чтобы определить максимальную длину ввода ... например: -25 имя-ТХ ... но я не совсем уверен в этом ... и если я пойду по этому пути, возможно, ООП подход будет лучше.

Что вы думаете об этом? Кажется, хороший способ использования?

Негативная точка, которую я действительно могу видеть (я до сих пор не использовал этот способ, просто чудо этого утра) 1. Префикс и другие процедуры должны быть многочисленными, если я хочу, чтобы мое заявление не было слишком ограничительным; 2. Имена отправленных переменных станут немного длиннее (но мы говорим о 3-6 символах, это не должно быть проблемой)

Любое предложение действительно ценится!

EDIT:

Я не трин, чтобы заново изобрести колесо, мой пост был не о системе дезинфекции ввода, а о процедуре, чтобы сделать это. Я использую htmlpurifier, чтобы очистить, возможно, внедрение xss в html-данные, и, конечно, я использую параметризованные запросы. Мне просто интересно, лучше ли брать входные данные или дезинфицировать их все в начале и считать, что они чисты в остальной части сценария. Метод i thougt не чудодейственный и ничего нового под солнцем, но я думаю, что усечение ввода, если не в формате, который я аспект, может быть полезным ...

Зачем проверять SQL-инъекцию в поле 'name', которое должно содержать только буквы и символ апостроф? Просто удалите все, что не является буквой или апостофом, добавьте косую черту для последнего и выполните параметризованный запрос. Затем, если вы отправляете электронное письмо, просто удалите все, что не является электронным письмом.

Ответы [ 3 ]

2 голосов
/ 27 апреля 2009

Есть много хорошо сделанных проверенных PHP классов , которые уже очищают входные данные. Зачем делать еще один? Кроме того, очистка входных данных - это больше, чем просто проверка типов данных. Это подразумевает проверку на sql-инъекции, xss-атаки и т.д ...

0 голосов
/ 27 апреля 2009

Идея сама по себе прекрасна, однако мне интересно, действительно ли она будет очень полезна.

С одной стороны, SQL-инъекции и HTML-инъекции могут (должны) быть защищены другим способом. Инъекции SQL предотвращаются с помощью параметризованных запросов (обязательный атрибут этого дня и возраста); и HTML-инъекции предотвращаются методом htmlspecialchars(), который должен вызываться непосредственно перед выводом строки пользователю . Не храните закодированные строки в БД или (что еще хуже) - закодируйте их, как только получите их. Работать с ними будет адом позже.

Кроме этих двух инъекционных атак, что будет делать ваш метод? Ну, он может сделать некоторые регулярные выражения для таких вещей, как номера, номера телефонов, электронные письма, имена и даты. Но это все. К сожалению, это только часть всех проверок, которые вам придется сделать. В других распространенных случаях, которые вы не можете проверить, есть перекрестная проверка входных данных (дата начала до даты окончания) и проверка того, что значение находится в списке разрешенных предварительно определенных значений (скажем, для элемента <select>). И есть бесконечное количество пользовательских шагов проверки, которые вы будете иметь в своем приложении. Стоит ли разделять всю валидацию на «валидацию универсального типа» и «валидацию пользовательских правил»? Я не знаю. Может быть. Или, может быть, это только увеличит беспорядок.

0 голосов
/ 27 апреля 2009

Что вы пытаетесь сделать? Если вам нужно очистить ввод для сохранения данных в базе данных, нет ничего лучше параметризованных запросов.

См. this для примера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...