Кардинальная защита от SQL-injection

бред какой то

аффтор подсчитал какой объем информации в base64 придется гонять например для inplace editor или даже простого поля для редактирования в какой нить wiki или системе документооборота?

use Django, Luke

бредятина. ОРМ в руки + 1 умная книга и вперед. Борьба со следствием, а не с первопричиной есть признак слабоумия или отсутствия здравого хода мысли.

Да вы что, совсем охренели?

Зачем бейс64? Есть же функции которые ескейпят, что нужно.

И такой интерфейс (c ^^) — кривость.

почему бы и нет - http://www.postgresql.org/docs/9.0/static/functions-string.html, но аргументы все равно нужно проверять, может должно быть введено число, а предается черте что

> может должно быть введено число, а предается черте что

можно исключения ловить

> Борьба со следствием

Я тоже так думаю, но метод показался интересным, в том числе потому, что предложен не анонимусом с ЛОРа, а уважаемым человеком

> Зачем бейс64? Есть же функции которые ескейпят, что нужно.И такой интерфейс (c ^^) — кривость.

Насколько я понял, в наборе инструментов есть тулза, которая запрос 1 автоматом превращает в запрос 2, хотя я мог неправильно понять.

> аффтор подсчитал какой объем информации в base64 придется гонять например для inplace editor

Автор не заставляет разработчиков inplace editor'а пользоваться его изобретением.

Кардинальная защита от SQL-injection - не использовать SQL.

А вообще, пусть лучше Каминский дальше «развенчивает мифы» и расставляет точки над DNS, так хоть лулзы словить можно.

А про cursors, prepared statements и bind-переменные php-шники-велосипедостроители видимо никогда и не слышали ?

^^ня

Уже не помню, когда последний раз делал прямые SQL-вызовы. А экранированием данных занимался ещё раньше последний раз. И это не смотря на то, что MySQL - это мой основной бэкенд, с которым я работаю каждый день.

ORM рулит.

Он не осилил экранирование кавычек, как я понимаю?

> ORM рулит.

быдлокодерам от этого безопаснее не становится. Я вообще не сразу понял, как можно написать код, подверженным sql-инъекциям, а когда понял — удивился тому, как можно писать такой быдлокод. Но проблема тем не менее стоит, стоит остро, вот и товарищ придумал простые инструменты, позволяющие избавить уязвимое приложение от уязвимостей, сохранив заработок для php-кодеров.

> А про cursors, prepared statements и bind-переменные php-шники-велосипедостроители видимо никогда и не слышали ?

php-шники, предположительно, не слышали. Каминский, предположительно слышал, но решил, что проще сделать вот такой костыль, чем объяснить php-шникам про prepared statements и курсоры

Похоже на толстый вброс, base64 ничем не лучше ескейпа слешами, или это его расширение MySql не принимает данные, не закодированные в base64?

Похожая техника предлагается для защиты от XSS-атак: введённые пользователем данные передаются в коде страницы в виде base64-строки, а специальная JS-функция превращает эту строку в обычный текст, который отображается в браузере без html-разбора.

А потом думать, почему сайта нету в индексе поисковых систем

А вообще, что думают аналитики насчет этого Дена Камински? У меня создалось впечатление, что это элитный тонкий тролль

man EJB3

Кардинальная защита от SQL-injection - это использование только хранимых процедур и запрет всяких SELECT'ов, INSERT'ов и прочих UPDATE'ов.

а сабж, описанный ТСом, очень сильно смахивает на бред.

> Кардинальная защита от SQL-injection - это использование только хранимых процедур и запрет всяких SELECT'ов, INSERT'ов и прочих UPDATE'ов.

Тут речь идёт про кардинальную защиту уже написанного уязвимого приложения, а твой вариант нужно внедрять на стадии проектирования.