лучше избегать/кодировать пользовательский ввод, прежде чем хранить его в базе данных или хранить его так, как он есть в базе данных, и избежать его при извлечении?

Я использую функцию htmlspecialchars() для предотвращения атак XSS. У меня есть сомнения относительно того, что является лучшим способом хранения данных в базе данных из следующего.лучше избегать/кодировать пользовательский ввод, прежде чем хранить его в базе данных или хранить его так, как он есть в базе данных, и избежать его при извлечении?

Способ 1: Сохраните введенные пользователем значения после применения функции htmlspecialchars(). Используя это, пользовательский ввод "<script>" станет «& lt; script & gt; ,

Способ 2: Храните входной сигнал пользователя как есть и применяйте метод htmlspecialchars() при извлечении данных и их отображении на странице.

Причина, по которой я сомневаюсь, заключается в том, что, используя метод 1, в базе данных будут накладные расходы, а при использовании данных метода 2 необходимо снова и снова преобразовывать по запросу через php. Поэтому я не уверен, какой из них лучше.

Для получения дополнительной информации, я использую htmlspecialchars($val, ENT_QUOTES, "UTF-8") так, что будет конвертировать "и", а также.

Пожалуйста, помогите мне очистить мои сомнения. Кроме того, предоставить объяснение, если это возможно.

спасибо.

источник

2012-03-01 Vivek Vaghela

An даже лучше Причина в том, что при усечении, чтобы соответствовать определенному пространству, вы будете застревать с такими мерзостями, как "&quo...". Сопротивляйтесь соблазну возиться с вашими данными больше необходимого минимума. Если вы беспокоитесь о переработке данных, кеш это

источник

2012-03-01 08:30:54

Как и атаки XSS, разве вас также не беспокоят атаки SQL-инъекций, если вы вводите пользовательский ввод в базу данных? В этом случае вы захотите избежать ввода пользователя, прежде чем поместить его в базу данных.

источник

2012-03-01 08:32:57

'htmlspecialchars()' не остановит атаки SQL-инъекций. И, кроме того, все должны использовать параметризованные запросы в любом случае. –

Почему вы ожидаете, что вы всегда будете использовать данные в контексте HTML? "I < 3 вы" и "I & lt; 3 вы" не то же самое данные. Поэтому сохраните данные так, как это предусмотрено в базе данных. Нет никаких оснований для его спасения.
HTML, избегающий данных тогда и только тогда, когда это необходимо, дает вам уверенность в том, что вы знаете. Это:
```
echo htmlspecialchars($data); 
```
намного лучше, чем:
```
echo $data; // The data should already come escaped from the database. 
      // I hope. 
```

источник

2012-03-01 08:33:51 deceze

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

@Erlend, конечно, но это не имеет никакого отношения к этому делу в частности.Если записаны ошибочные данные, вам придется отремонтировать контент, когда узнаете. Это верно везде, где вы пишете в базу данных (или в любой документ). –

@ Mr Lister: Это очень актуально для заданного вопроса. Если вы храните данные uenescaped escape на дисплее, вам не нужно прикасаться к базе данных, когда обнаружена ошибочная логика экранирования. Только измените логику экранирования. В большинстве случаев это проще, чем исправлять данные в базе данных. – Erlend

Моя рекомендация состоит в том, чтобы хранить данные в базе данных в чистом виде. Единственная причина, по которой вы хотите преобразовать ее в <script>, - это то, что вам нужно будет отобразить ее в документе HTML позже. Но сама база данных не нуждается в том, чтобы знать, что вы делаете с данными после ее получения.

источник

2012-03-01 08:36:13

лучше избегать/кодировать пользовательский ввод, прежде чем хранить его в базе данных или хранить его так, как он есть в базе данных, и избежать его при извлечении?

ответ

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