Считается, данные числового типа полностью защищают от атаки типа SQL инъекции. Давайте рассмотрим простой пример: PHP: $action = $_GET['do']; $r=$db->query("select role".((int)$action)." from users where id=".((int)$_SESSION['user_id'])); if($row=$r->fetchArray()){ if((int)$row[0]!==1){ die('permission denied'); }else{ doAction($action); } } Приведенный код выглядит вполне безопасным, но это не так. Не стоит забывать о двух важных вещах: Существуеи SQL оператор минус. Число может быть отрицательным. Теперь рассмотрим логику SQL в данном случае (без инъекций): PHP: select role0 from users where id=0 И атаку типа SQL Injection: PHP: select role-1 from users where id=0 Таким образом злоумышленник может обойти авторизацию. В этих примерах требуется наличие таблиц role и role0 в базе данных. Автор: Vladimir // перевод VY_CMa Дата: 13 мая 2013 г. http://lab.onsec.ru/2013/05/when-integer-cannot-protect-you-from.html
Слишком натянуто как-то. Если action передается через переменную, то подразумевается, что это так заложено в логике приложения, чтоб шло обращение к колонкам role[0-65536]. Это не инъекция, а сознательный допуск девелопера ко всем колонкам из этого диапазона role[0-65536]. Внедрения хакером своих операторов не происходит, все в точности в тех пределах, задуманных создателем этого приложения.
Пример явно синтетический. В нормальных движках и фреймворках информация о привилегиях подгружается в сессию на стадии авторизации, а ID действия вообще недоступен для изменения пользователем, т.к. задается функцией, выполняющей запрос. Далее, зачем заводить отдельную колонку под каждый тип действия? Если это, например, права на редактирование текста статьи, то у многих там будут стоять нули - а это бессмысленный расход дискового пространства. Лучше сделать Many-To-Many связь. И тогда эта проблема отпадет - action_id будет передаваться в предложении WHERE. Таких искусственных уязвимостей можно придумать очень много. Вопрос в том, насколько часто они встречаются.