2013-04-19 4 views
0

Привет всем, я экспериментировал и начал создавать веб-сайт, который собирается внедрить форум. Я начинаю смотреть на проблемы безопасности, которые могут повлиять на веб-сайт. Такие области, как межсайтовый скриптинг и SQL-инъекции.Предотвращение инъекций SQL

Из исследования, снимающего все теги html, будет предотвращен XSS. Будет ли это вместе с удалением специальных символов SQL, достаточных для предотвращения атак с SQL-инъекциями?

<?php 
require "dbconn.php"; 

$mnam = strip_tags($_GET['blogentername']); 
$mcom = strip_tags($_GET['blogmessage']); 
$approve = 'N'; 
$dte = gmdate("d-M-Y H:i:s"); 

$mnam = mysql_real_escape_string($user); 
$mcom = mysql_real_escape_string($mcom); 

$query = "INSERT INTO blogentry VALUES ('".$mnam."','".$dte."','".$mcom."','".$approve."','','')"; 

$results = mysql_query($query) 
      or die(mysql_error()); 

header('Location:messages.php?messagesent=1'); 

?> 

Спасибо не все для вас время Энди

+0

Там нет стриппинг SQL специальных символов в коде. Я бы сказал, что нет такой вещи, как «специальные символы SQL» –

+0

Я рекомендую читать OWASP – Esailija

+0

. Способ предотвращения XSS должен корректно ** кодировать ** текст при создании HTML. – SLaks

ответ

0

Для данного кода - да, это довольно безопасно и непроницаемо.

Однако, ваша идея защиты от SQL-инъекции в общем-то совсем не правильная.

В вашем коде отсутствует «удаление специальных символов SQL». И нет никакого смысла в такой зачистки вообще.
Говоря о SQL строки, они довольно безопасны, если правильно отформатирован. Но для всех других литералов SQL то, что вы называете «зачисткой», фактически ничего не потеряет.

+0

Спасибо за совет – user2141414

0

Вы должны никогда раздеться теги. Сохраните их в базе данных raw, затем используйте htmlspecialchars при выводе их в браузер.

+0

спасибо за ваш совет – user2141414

+0

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

0

Как наилучшая практика, никогда не используйте конкатенацию строк для создания ваших SQL-команд.

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

Более подробная информация с примерами здесь: How can I prevent SQL injection in PHP?

+0

К сожалению, мы не можем избежать конкатенации. Итак, лучше знать правила. –

+0

Выполнение одного и того же типа операций несколько раз в типичном веб-приложении. Запах плохого дизайна. –

+0

Это часто делается при выполнении INSERT или UPDATE при циклическом перемещении по набору данных. Оператор SQL подготовлен один раз, а затем значения просто передаются ему каждый раз через цикл и быстро выполняются, потому что ему не нужно переоценивать весь оператор SQL. См. Http://stackoverflow.com/questions/1318023/performance-of-parameterized-queries-for-different-dbs и http://stackoverflow.com/questions/1851834/why-is-using-a-parameterized-query -to-insert-data-in-table-fast-than-appen для получения дополнительной информации. – diamondsea