Достаточно ли безопасен мой PDO INSERT INTO?

Мне бы хотелось ваше мнение о моем коде. Это достаточно безопасно против любых инъекций.
Спасибо за ваши ответы.

class Product extends DB {

public function __construct() {
$db = $this->DB();

if(isset($_POST['productName'])) {
foreach ($_POST as $key => $value) {
if (ini_get('magic_quotes_gpc'))
$_POST[$key] = stripslashes($_POST[$key]);
$_POST[$key] = htmlspecialchars(strip_tags($_POST[$key]));
}
$this->AddProduct();
}
}

public function AddProduct() {
$sSQL = "INSERT INTO ".PREFIX."product (productName, productPrice)
VALUES (:productName,:productPrice)";
$query = $this->db->prepare($sSQL);
$query->execute(array(
":productName" => $_POST['productName'],
":productPrice" => $_POST['productPrice']
));
}
}

0

Решение

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

Код, который вызывает htmlspecialchars и strip_tags, не имеет отношения к внедрению SQL. Это может быть вызвано для предотвращения уязвимостей межсайтового скриптинга, но это отдельная проблема. Я не рекомендую делать эти шаги, когда вы вставляете данные в базу данных. Просто отфильтруйте уязвимости XSS при выводе в HTML. В противном случае вы получите буквальный & последовательности хранятся в вашей базе данных, и это преждевременно. Вы не обязательно будете использовать данные для отображения в HTML каждый раз. Просто кодируйте его, когда вы выводите, а не когда вы вводите.

Я никогда не беспокоюсь о компенсации возможного magic_quotes_gpc. Проверьте это при развертывании приложения и прервите развертывание. Это не действительно для любой Экземпляр PHP для установки magic_quotes_gpc в 2014 году.

3

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]