2016-04-09 4 views
1

Я знаю, что вы всегда должны использовать подготовленные инструкции (или дезинфицировать) для данных, вводимых пользователем. Мы это делаем. Мой вопрос заключается в том, что после ввода данных с использованием подготовленных операторов и сидения в моей базе данных мне нужно снова использовать подготовленные заявления, если я беру данные из базы данных, сам ими управляю (т. Е. Без участия пользователя), а затем возвращаю их обратно база данных?Нужно ли мне санировать данные из базы данных?

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

Итак, подведем итоги, данные пользователя -> использовать подготовленный оператор -> в базу данных. Но нужно ли делать следующее при работе с данными, представленными пользователем, но подготовленными данными перед хранением: данные из базы данных -> использовать подготовленный оператор -> в базу данных?

Спасибо!

+1

Не может повредить, хотя я не думаю, что это необходимо, в строгом смысле этого слова. – hd1

+0

Если данные могут быть введены пользователями, то дезинфекция - хорошая идея. Если данные являются программными, тогда это не обязательно. –

+2

Я бы это сделал. Кто скажет, что кто-то не запускал сценарий для обновления данных таким образом, чтобы впоследствии возникать проблемы. Или позже, кто-то не дезинфицирует данные, и он попадает, хотя импортер или слияние. Лучше быть в безопасности, чем потом сожалеть! Хотя, я не большой поклонник изменения данных без одобрения пользователей ... – xQbert

ответ

4

Если он пришел от пользователя в любой момент, да, вы должны использовать подготовленные заявления, когда вы вставляете его снова.

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

+0

+10 лучше и более сжато представлен, чем мой ответ. по сути, те же идеи, которые я пытался передать. (Я думаю, что Гордон и Фред не заметили, что ОП использовал термин «санизировать» в качестве ссылки на шаблон подготовки-> привязка->.) – spencer7593

+0

Спасибо, @ spencer7593. Я действительно думал, что ваш ответ тоже очень хорош (у вас есть голос от меня). Просто хотел немного покрутить его. –

+0

Эд, я думаю, что этот ответ (ваш ответ) имеет лучший «поворот», чем мой. – spencer7593

3

Да, вам необходимо следовать одному и тому же образцу.

У вас есть столбец varchar, в который вы вставили значения. Для примера, назовем его last_name.

Возможно, кто-то вставил в эту колонку значение 'O'Reilly'.

Если это было сделано по образцу

подготовки -> привязывать -> выполнить

Значение, сохраненное в столбце в базе данных будет O'Reilly, содержащий эту одиночную кавычку.

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

Если вы хотите использовать это значение в другом выражении SQL, вы столкнулись с такой же проблемой , когда пользователь впервые ввел значение.

Таким образом, вы либо должны следовать той же схеме prepare -> bind -> execute (или значение строки должны быть надлежащим образом спасся, если она включена в текст SQL заявления.)


Если вы только ссылки имя столбца, содержащего небезопасное значение, тогда вы можете безопасно использовать это в SQL-заявлении, например

CREATE TEMPORARY TABLE _tmp_last_names 
    AS 
    SELECT t.last_name FROM mytable t 
    ; 

Узор с помощью подготовленных инструкций с связывания заполнителей не «Sanitize» данные. Это всего лишь механизм, который позволяет избежать некоторых потенциальных проблем с некоторыми значениями данных.

«Антисанитарное» значение, предоставленное для заполнителя связывания, будет храниться в базе данных. Это будет то же самое «антисанитарное» значение, а не какая-то «санированная» версия значения.

Но если вы выполнили какую-либо другую логику (помимо шаблона execute -> bind -> execute), чтобы «дезинфицировать» все значения, хранящиеся в базе данных, тогда было бы не обязательно повторно выполнять это та же логика. Предполагая, что ни один другой процесс впоследствии не заменит санитарную ценность в базе данных антисанитарным значением.

3

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

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

DB()->updateColumn('table', $data)->where('id', $uid); 

Это только предположение, но кажется, что подход вы принимаете не подумайте, где возможно повторное использование кода.

0

Я хотел добавить, что со всеми этими разговорами о дезинфекции (и в моем собственном поиске) нет никаких объяснений о том, как фактически дезинфицировать данные MySQL, прежде чем он будет возвращен в PHP? (Psst: У меня нет 50 представителей, которые могли бы дать комментарий кому-либо, но я действительно хочу сказать об этом, потому что в данный момент я это ищу.)

Смежные вопросы