Предотвращение SQL-инъекций в Hibernate

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

List mothers = session.createQuery(
"select mother from Cat as cat join cat.mother as mother where cat.name = ?")
.setString(0, name)
.list();

Затем он параметризуется и защищается от SQL Injection, или есть что-то еще, что мне нужно сделать...

Была упомянута еще одна вещь: «Всегда избегайте своих данных». Как этого можно достичь??


hibernate hql sql-injection parameterized
person Juzer Arsiwala    schedule 05.01.2011    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Я не знаю насчет setString(), но если это то же самое, что и setParameter(), то да, этого достаточно, чтобы предотвратить внедрение sql.

Обновить

Экранирование данных означает, что вы должны убедиться, что не храните опасные значения в базе данных.

Быстрый пример, например, если вы передаете аргумент

String name = "<script>alert('Hello');</script>";
//insert this name into Mother, and then when you load it from the database, it will be displayed    

List mothers = session.createQuery(
"select mother from Cat as cat join cat.mother as mother where cat.name = ?")
.setString(0, name)
.list();

к вашему запросу, то в следующий раз, когда вы загрузите его из базы данных и отобразите в своем веб-браузере, он запустит скрипт.
Вы должны убедиться, что ваш фреймворк экранирует все недопустимые символы, например: замените < на &lt;, прежде чем вставлять его в базу данных.
Если ваш фреймворк этого не делает, вам придется сделать это вручную. Существует множество библиотек, которые корректно экранируют код за вас. Взгляните, например, на этот вопрос и ответы там.

person Shervin Asgari    schedule 05.01.2011
comment
Я просмотрел ссылку, которую вы предложили. Люди предлагают решения для экранирования html. Требуется ли какой-либо другой тип экранирования? - person Juzer Arsiwala; 05.01.2011
comment
-1. Экранирование входных данных — не лучший подход к предотвращению XSS. Лучший способ - избежать ненадежных данных, когда вы собираетесь вставлять их в опасный контекст (например, на HTML-страницу), принимая во внимание правила этого контекста. См. также памятку OWASP по предотвращению XSS. Также вопрос был о SQL-инъекции, а не о XSS. - person axtavt; 05.01.2011
comment
@axtavt Если вы прочитаете мой ответ и комментарий внутри кода, вы увидите, что я упоминаю, что данные должны быть экранированы при вставке в таблицу Mother. - person Shervin Asgari; 05.01.2011
comment
@axtavt: Axtvt не так уж неправ: Escping требуется при изменении представления метаданных. -- Что я имею в виду: при переходе с Java на SQL (отправка оператора Sql) вы должны позаботиться об экранировании SQL, но не о HTML. При написании HTML-страницы вы должны позаботиться об экранировании HTML, но не о SQL. -- Правило простое: каждый раз, когда ваши данные переходят из одного контекста/стиля в другой, вы должны обращать внимание на побег - person Ralph; 05.01.2011