- Почему? Они и с ними могут быть!
Примерно такой вопрос и ответ на него можно часто услышать на собеседованиях по вебчику, однако, потом после оффера и получения работы мало кто на серьёзке будет проверять SQL-запросы через ORM или Query Builder. Зачастую всё заканчивается одной-двумя провальными попытками эксплуатации SQL-инъекции, после чего делается вывод, что "скулей тут нет". Хотя тут стоило просто сесть, развернуть библиотеку у себя с похожими SQL-запросами и потыкать её с дебагом.
А где могут быть проблемы, умник?
1) Может использоваться метод для выполнения сырых SQL-запросов, и в него напрямую могут попадать пользовательский значения:
db.session.execute(f"SELECT * FROM users WHERE age = {data}")2) Некоторые методы в тех же Query Builder'ах, например
Where(), иногда могут принимать различное кол-во аргументов, в зависимости от того, нужно ли параметризировать какие-либо данные:
.Where("id={data}") -> WHERE id=0
.Where("id=?",data) -> WHERE id=$1
Иногда разработчики могут этого не знать/забыть, и напрямую подставлять ваши нагрузки в SQL-запрос. Помимо этого у одних и тех же SQL-операторов может быть 2 метода: для сырого исполнения и параметризированного. Догадайтесь сами, куда ваши нарузки не должны попадать:
.WhereRaw("id={data}") -> WHERE id=0
.Where("id","=",data) -> WHERE id=$1
Грубо говоря, этот пункт про то, что порой варианты защиты есть, но про них забыли.
3) Во многих ORM и Query Builder есть методы, в которые пользовательские данные не должны попадать(Insecure By Design), например
Select(). По логике туда должны идти только жёстко прописанные столбцы и ничего больше. Однако разработчики могут и туда засунуть ваши значения, чем вы и воспользуетесь:
data = "hello',(SELECT ''||pg_sleep(5)),'1"
Table("Dialogs").Select(data)# SELECT 'hello',(SELECT ''||pg_sleep(5)),'1' FROM Dialogs
4) Может ваши данные попадут в метод по типу
filter() и у вас будет plORMbing(ТЫК и ТЫК)5) Можете найти CVE! Звучит сложно, но по факту разработчики часто могут забыть защитить какой-то метод, либо делают это криво, поэтому возможно обойти ограничения. Помимо этого разработчики очень любят добавлять поддержку большого кол-ва СУБД(так же круче библиотека выглядит), однако, это может привести к ситуации, когда про какую-то СУБД просто забудут во время внедрения защиты, из-за чего только с этой СУБД будет инъекция в конкретном методе. Пруфов пока не будет, они ждут свои cveшки от вендора =)
6) А может уже кто-то нашёл уязу в вашем ORM или Query Builder, и у вас как раз та самая версия - стоит проверить!
Вывод
Рекомендую не забывать про тестирование ORM и Query Builder'ов, так как вы как минимум убедитесь, что всё покрыли, а как максимум найдёте скулю, может даже с выходом в RCE, а может даже получите CVE;)