2014-10-22 2 views
1

Я действительно смущен PDO Подготовлено заявление. Я сделал все, как говорится в документации php.net. Когда я вставил JavaScript в базу данных, а затем запросил базу данных и вывел результаты на странице, это дало мне предупреждение JavaScript, которое было в базе данных.PDO Подготовленное заявление разрешает выполнение javascript

<?php 
    try { 
     $db = new PDO('mysql:host=localhost;dbname=test', "root", ""); 
    } catch (PDOException $e) { 
     print "Error!: " . $e->getMessage() . "<br/>"; 
     die(); 
    } 

    $query = $db->query('SELECT * from users'); 
    if($query->rowCount()){ 
     $rows = $query->fetchAll(PDO::FETCH_OBJ); 
     foreach($rows as $row){ 
      echo $row->user_name; 
      echo "<br/>"; 
     } 
    } else { 
     echo "No results found"; 
    } 

    $user_name = "<script type=\"text/javascript\">alert(\"Works\");</script>"; 
    $user_email = "[email protected]"; 
    $user_password = "password"; 
    $user_status = "1"; 

    $data = array(
     ":user_name" => $user_name, 
     ":user_email" => $user_email, 
     ":user_password" => $user_password, 
     ":user_status" => $user_status 
    ); 
    $sql = "INSERT INTO users (user_name, user_email, user_password, user_status) VALUES(:user_name, :user_email, :user_password, :user_status)"; 
    $prepare = $db->prepare($sql); 
    $exec = $prepare->execute($data); 
?> 
+5

PDO не дезинфицирует ничего. Если вы используете подготовленные операторы, они предоставляют метод поместить данные в базу данных SQL, которая не подвержена атакам __SQL__-инъекций. Все другие уязвимости - ваша ответственность за защиту. Вы должны использовать 'htmlspecialchars()' или какой-либо его вариант для кодирования ваших данных для вывода. –

+2

Выходное экранирование должно выполняться контекстно-зависимым (здесь 'htmlspecialchars()' перед любым выражением 'echo'), и это не относится к интерфейсу интерфейса базы данных. – mario

ответ

3

При использовании подготовленных операторов и параметризации SQL, PDO защищает от атак SQL-инъекций.

Но вы описываете что-то, называемое Cross-Site Scripting (XSS). Это совершенно другая проблема с безопасностью. Он не зависит от содержимого SQL или базы данных. Вы можете создать уязвимость XSS с любыми данными приложения, не ограничиваясь данными, полученными из базы данных. XSS, как и SQL-инъекция, важна для всех программистов.

Вы, наверное, видели высоко оценил сообщение о том, как защититься от инъекции SQL в PHP:

Но вот несколько хороших сообщений о XSS обороны:

SQL инъекции и Cross-Site Scripting последовательно в двух верхних ошибках безопасности, которые предоставляют данные в Интернете. См. Список важнейших рисков безопасности OWASP Top Ten: https://www.owasp.org/index.php/OWASP_Top_Ten_Project

Получите себя на этом сайте OWASP. Здесь есть много ресурсов, чтобы узнать о рисках безопасности и о том, как их решить. И это бесплатно!

+0

Хороший отчет Билл. –

+0

Мне также нравится эта статья в википедии ~ http://en.wikipedia.org/wiki/Secure_input_and_output_handling. И это более специфично для PHP - http://lukeplant.me.uk/blog/posts/why-escape-on-input-is-a-bad-idea/ – Phil

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