https://www.opennet.ru/openforum/vsluhforumID3/68030.html Ден Каминский (Dan Kaminsky (http://en.wikipedia.org/wiki/Dan_Kaminsky)), получивший известность обнаружением фундаментальной уязвимости в DNS, представил (http://recursion.com/interpolique.html) универсальную технику защиты от "SQL Injection" (подстановка SQL-запросов) и XSS (межсайтовый скриптинг) атак. Суть техники защиты от подстановки SQL-запросов в том, что при работе с пользовательскими данными в запросе к СУБД фигурируют не открытые данные, а строка в base64-представлении, в которой изначально отсутствуют спецсимволы. В отличие от традиционной практики анализа вводимых пользователем данных и экранирования опасных символов перед формированием запроса, метод Каминского по своей сути исключает человеческий фактор и возможность недосмотра при проверке. <br><br><br>Для наглядности рассмотрим пример. Допустим в программе имеется строка<br><br>&lt;font color="#461b7e"&gt; $conn-&gt;query("select * from table where fname=$fname;");&lt;/font&gt;<br><br><br><br>в случае отсутствия должных проверок в переменной $fname мо...<br><br>URL: http://www.dar https://www.opennet.ru/openforum/vsluhforumID3/68030.html#105 Fri, 30 Jul 2010 08:48:01 GMT base64() ничем не лучше встроенных в БД методов квотирования, а минусы есть -- декодирование для БД не родное. Здесь Дэн облажался.<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#104 Tue, 22 Jun 2010 15:49:37 GMT В то время, как такие, как Вы, орут об убогости пхп на форумах, нормальные разработчики зарабатывают деньги на написанных на пхп проектах :-)<br><br>"Ах, Моська, знать, она сильна, что лает на слона..."<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#103 Mon, 21 Jun 2010 18:13:55 GMT &gt;4. Выше было замечено, что даже друпал и жумла пишутся "спустя рукава". Ну а что можно написать на пхп не спустя рукава? Какой нормальный программист будет использовать эту поделку, в которой какие-то переменные конфига меняют всю суть "языка", синтаксис понадёрган из 30 разных языков и то возможности, которые были изначально в других давно существующих языках, появляются только в версии 5.3, а ещё (при программистской лени) нужно зачем-то везде ставить эти $, -&gt;, array() и прочие идиотские излишества. Код на пхп убог по сути пхп. И единственное универсальное средство против sql-injection для пхп - это отказ от пхп.<br><br>А что бы вместо пхп предпочли вы?<br><br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#102 Mon, 21 Jun 2010 05:34:40 GMT В PHP достаточно юзать PDO и bindColumn()-методы для достижения того же самого результата. Сделано для людей (с) Вы.<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#100 Sat, 19 Jun 2010 20:15:44 GMT Теперь просек. Действительно хороший выход для тех, кто без врапперов пишет.<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#99 Fri, 18 Jun 2010 17:27:36 GMT Проблема в том, что base64 - по природе своей костыль. Если подумать, "экранировка", в общем-то, тоже. Надо копать в какую-то другую сторону, imho, отделять мух от котлет более радикально.<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#98 Fri, 18 Jun 2010 17:26:41 GMT &gt; Зачем это?<br>&gt; А внешних кавычек ($conn-&gt;query("select * from table where fname=\"$fname\";");) и <br>&gt; isset($fname) недостаточно?<br><br>PHP-программисты такие програссимты...<br><br>ясное дело что подставление ковычек -- НЕ запускает процесс экранирования :-D !<br><br>в Python DB-API-2.0 -- всё сделано для людей:<br><br>c.execute('SELECT * FROM stocks WHERE symbol=?', (symbol,))<br><br>вот вам и решение проблемы с безопасностью от инъекций<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#97 Fri, 18 Jun 2010 15:34:44 GMT &gt;Вот - вот, семь раз RTFM - один раз ... :)<br><br>Семь раз RTFM, один раз rm -rf :D<br> https://www.opennet.ru/openforum/vsluhforumID3/68030.html#96 Fri, 18 Jun 2010 12:02:20 GMT На счет костыльного решения - 100%. Что моё, что Камински.<br>Я не приветствую решения, которые замедляют (читай увеличивают нагрузку на CPU) работу отдельных функций СУБД. Вот если создать работу со специндексами в самой СУБД (например, для полнотекстового поиска в кодировке base64 или подобной), которые будут работать не медленнее существующих - это уже будет не костыль, а фича!<br> <br><br>