Полностью с Вами соглашаемся с утверждением про "две категории: данные и все остальные элементы". Мы же даем в статье обзор имеющихся средств pqxx по защите от SQL инъекций, это может быть полезно, если скажем у Вас есть легаси код, в который нужно встроить защиту от SQL инъекций, но Вы не готовы переписать все запросы с использованием параметров.
По поводу "Многие поколения программистов выросли с убеждением, что экранирование защищает от инъекций. И как результат написали тонны уязвимого кода." нельзя с этим не согласится, спасибо за уточнение. Под символами разрыва строк в статье понимаются одинарные кавычки '
То что quote_name не защищает от инъекции когда атакующий передаст валидное имя поля даже не обсуждается потому что так оно и есть. Для защиты в таких случаях как раз и используется input validation, такие, как белые списки например.
Вы заявляете что "Инъекции надо предотвращать, полностью". Полностью с Вами в этом согласны. Но продукты без ошибок и без уязвимостей это скорее абстрактный идеал к которому все стремятся, но который так и остается недостижимым. В достаточно большом продукте никто не даст Вам 100% гарантию, что продукт не имеет уязвимостей. Скорее даже наоборот: утверждения что какой-то продукт не имеет уязвимостей вообще или что какой-то продукт информационной безопасности выявит у Вас все уязвимости вызывают опасения в компетенции тех кто делает такие заявления. Предотвращение уязвимостей в продукте это по нашему мнению скорее компромисс между новой функциональностью, сроками, затратами на разработку и требованиями по безопасности продукта.
Здравствуйте, Я автор исходной статьи. К сожалению согласно недавнему отчету MITRE SQL инъекции стоят на третьем месте среди 25 самых опасных проблем в программном обеспечении за последние два года. Подробнее можете посмотреть тут https://cwe.mitre.org/top25/
Здравствуйте, Я автор исходной статьи. Спасибо за напоминание, в своем коде мы в основном используем raw запросы, но prepared statement конечно также является средством против SQL инъекций
Здравствуйте,
Я автор исходной статьи.
Мы в своей работе пользуемся принципами безопасной разработки, такими например как Input Validation (https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) и Defence in Depth(https://en.wikipedia.org/wiki/Defense_in_depth_(computing)). Может быть фраза "пользовательские данные" была выбрана неудачно, но принципы безопасной разработки требуют валидировать все данные, чему мы и следуем.
Полностью с Вами соглашаемся с утверждением про "две категории: данные и все остальные элементы". Мы же даем в статье обзор имеющихся средств pqxx по защите от SQL инъекций, это может быть полезно, если скажем у Вас есть легаси код, в который нужно встроить защиту от SQL инъекций, но Вы не готовы переписать все запросы с использованием параметров.
По поводу "Многие поколения программистов выросли с убеждением, что экранирование защищает от инъекций. И как результат написали тонны уязвимого кода." нельзя с этим не согласится, спасибо за уточнение. Под символами разрыва строк в статье понимаются одинарные кавычки '
То что quote_name не защищает от инъекции когда атакующий передаст валидное имя поля даже не обсуждается потому что так оно и есть. Для защиты в таких случаях как раз и используется input validation, такие, как белые списки например.
Вы заявляете что "Инъекции надо предотвращать, полностью". Полностью с Вами в этом согласны. Но продукты без ошибок и без уязвимостей это скорее абстрактный идеал к которому все стремятся, но который так и остается недостижимым. В достаточно большом продукте никто не даст Вам 100% гарантию, что продукт не имеет уязвимостей. Скорее даже наоборот: утверждения что какой-то продукт не имеет уязвимостей вообще или что какой-то продукт информационной безопасности выявит у Вас все уязвимости вызывают опасения в компетенции тех кто делает такие заявления. Предотвращение уязвимостей в продукте это по нашему мнению скорее компромисс между новой функциональностью, сроками, затратами на разработку и требованиями по безопасности продукта.
Здравствуйте,
Я автор исходной статьи.
Если Вы имеете в виду prepared statement то уже ответили выше
Здравствуйте,
Я автор исходной статьи.
К сожалению согласно недавнему отчету MITRE SQL инъекции стоят на третьем месте среди 25 самых опасных проблем в программном обеспечении за последние два года. Подробнее можете посмотреть тут https://cwe.mitre.org/top25/
Здравствуйте,
Я автор исходной статьи.
Полностью с Вами согласны, exec_params конечно отличное решение, спасибо что упомянули его
Здравствуйте,
Я автор исходной статьи.
Спасибо за напоминание, в своем коде мы в основном используем raw запросы, но prepared statement конечно также является средством против SQL инъекций