2014-01-16 5 views
1

Это может быть отмечено как дубликат, но в моей защите я искал какое-то время, и много информации, которую я нахожу, относится к mysql или mysqli в лучшем случае, или является неполным. Я хочу получить подробный, актуальный ответ, который влияет на использование PDO и подготовленных операторов.Правильный способ обработки потока данных через приложение

Что является надлежащим образом способ обработки данных при его перемещении по приложению.

Является ли следующий теоретический поток данных адекватным, а если нет, то какие улучшения вы бы порекомендовали?

  1. Собственная форма проверки на стороне клиента.
  2. Использование $_POST, а не $_GET
  3. В PHP, используя $variable = htmlentities($_POST['variable']); непосредственно перед введением базы данных.
  4. с использованием PDO и подготовленных заявлений: bindValue(':variable', $variable);
  5. На выходе, используя echo htmlspecialchars($variable); для предотвращения атак XSS.

Две смежные вопросы:

  • позволяет сказать, что вы используете htmlentities() данных перед введением базы данных. Как вы можете удалить все мусор, который был вставлен, если введенный пользователь сказал <p>my input value</p>. Это пишет: &lt;tr&gt;&lt;p&gt;my input value&lt;/p&gt;&l в базу данных.
  • Если ваш php возвращает массив JSON, обработанный AJAX, как вы обрабатываете вывод в этом сценарии? Это не работает в PHP: htmlspecialchars($JSON_Array)

Заранее благодарю вас за помощь.

+1

Шаг 3 не нужен и вводит в заблуждение. На шаге 5 «htmlspecialchars» применим только к выходу HTML - его можно было бы обобщить на «кодирование вывода способом, подходящим для выходного контекста», «htmlspecialchars» для HTML, «json_encode» для JSON, XML Document methods for XML , и т.д.". – DCoder

+0

Шаг 2, возможно, сомнительный (разница семантическая, а не техническая), но 3 совершенно неправильно. – Jon

+0

@Dcoder 36 - что было бы подходящим способом обработки шага 3, или, я думаю, я должен сказать, что должен делать шаг 3? – hyphen

ответ

3

Вообще говоря ваш поток будет похож на это:

  1. стороне клиента данные «Validate» - вы не хотите доверять эту проверку, так как вы никогда не должны все, исходящее от клиента доверять, это чтобы сделать пользователя лучше.

  2. Проверка на сервере - убедитесь, что данные, данные вам, действительны. Примерами могут быть: validate type (int, string и т. Д.), Проверить значение (пользователи не могут заказать отрицательную величину элемента) и т. Д. Если вы используете какую-то структуру MVC-ish, это делается в Модельный слой.

  3. Храните данные в базе данных - вы будете использовать подготовленные операторы, чтобы защитить себя от SQL-инъекций, но вы не хотите каким-либо образом манипулировать данными (нет htmlentities или тому подобное).

  4. Всякий раз, когда вы принимаете данные из базы данных, когда вы решите, если вам нужно конвертировать HTML объекты или выполнять другую обработку на основании того, что вы вывода HTML, JSON, XML и т.д.

Если вам нужно использовать htmlspecialchars или что-то подобное на данных в массиве JSON, выполните это, прежде чем вы поместите данные в массив JSON.

+0

Что касается №3. Каков наиболее подходящий способ помешать кому-либо хранить несоответствующие данные в моей базе данных? Я удалил htmlentities глупость, но в этой конфигурации он все равно позволит кому-то хранить теги html, если они этого захотят, и я бы предпочел не позволять им это делать. Я могу настроить клиентскую часть regex, но, предположив, что вы сказали выше, я не хочу доверять данным на стороне клиента, как бы удалить их в php? – hyphen

+0

is strip_tags() лучший способ сделать это? – hyphen

+0

@hyphen Для фильтрации HTML мне нравится [HTML Purifier] (http://htmlpurifier.org/). Для других типов проверки вы также можете использовать регулярное выражение в PHP на стороне сервера, посмотрите [preg_match] (http://us3.php.net/preg_match) и связанные с ним функции. –

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