часть кода php для предотвращает взламывание
У меня есть php файл на моем сайте, и я соединяюсь с дб, получаю некоторые записи и перечисляю их в том же файле.
mysql_connect("localhost", "blabla", "blabla") or die(mysql_error());
mysql_select_db("blabla") or die(mysql_error());
$blabla1 = mysql_query("SELECT * FROM gallery WHERE id_cat=1");
$blabla2 = mysql_query("SELECT * FROM gallery WHERE id_cat=2");
$blabla3 = mysql_query("SELECT * FROM gallery WHERE id_cat=3");
Так, есть ли что-нибудь, что я должен сделать для безопасности? Как внедрение SQL или что-либо еще. нет ничего идущего в URL. Это справедливо www.blabla.com/gallery.php.
6 ответов
Этот фрагмент абсолютно безопасен, поскольку в строку запроса не помещаются переменные.
Для безопасной работы в случае, если однажды вам придется иметь дело с переменными - будь они напрямую поступают от пользователя или из другого источника данных - вы можете переключиться на библиотеку mySQL, которая поддерживает параметризованные запросы, например PDO . Они полностью исключают опасность инъекций, потому что автоматически избегают входящих данных.
Если вы используете функции mysql _ * , убедитесь, что вы экранировали все входящие любые данные, используя mysql_real_escape_string () и , убедитесь, что они вставлены в одинарных кавычках.
Пока ваши запросы не используют параметры, внедрение SQL не представляет опасности. Внедрение SQL может происходить только тогда, когда пользователи (или другие источники) могут влиять на все, что отправляется в базу данных в SQL, например поисковые слова
Здесь нет проблем с безопасностью. SQL-инъекция может происходить там, где вы получаете ввод от пользователя и используете его в своих запросах.
Единственное, что вы при условии, что код соединения находится в доступном через Интернет сценарии PHP, можно либо:
переместить соединение MySQL из сценария в файл за пределами корень документа сайта
или используйте переменные из внешнего источника (т. е. из другого файла вне корня документа) для имени пользователя и пароля вместо { {1}} жестко запрограммированные детали в скрипте
Таким образом, если по какой-либо причине сервер отображает код вместо рендеринга PHP, то детали останутся в безопасности из представления
Этот фрагмент безопасен, так как в запросах нет вводимых пользователем данных.
если у вас есть пользовательский ввод, например, получив категорию, которая должна отображаться из URL-адреса или из POST, вы должны использовать подготовленные операторы. это может быть безопасно даже при вводе пользователем. Это намного безопаснее, чем чистое экранирование, потому что sql анализируется, а затем вставляются параметры. Это лучше для производительности, и пользовательский ввод не может изменить структуру запроса sql.
Если таблица галереи содержит некоторый пользовательский ввод, то может быть проведена некоторая XSS-атака. Чтобы предотвратить это, весь ввод данных ненадежным пользователем должен быть подготовлен с помощью функции htmlspecialchars () перед печатью в браузере.