Возможность нового метода ввода формы "ESCAPE" (например, POST и GET), который автоматически экранирует специальные символы

Question

Мои знания невелики, поскольку я изучал только PHP / HTML / MySQL как хобби, поэтому, пожалуйста, будьте осторожны.

ESCAPE призван помочь программистам предотвратить инъекции SQL.Да, программисты должны быть умнее и просто addslashes(), но в свете недавней глупости LulzSec, я думаю, что W3C будет хорошим шагом для реализации нового метода ввода формы, который облегчит программистам реализацию безопасности.

Я знаю только PHP, поэтому я поговорю с этим.По сути, если раньше у нас было

$safeTagSearch = addslashes($_GET["tagSearchRaw"]);

, то теперь у нас будет

$safeTagSearch = $_ESCAPE["tagSearchRaw"]);

Если tagSearchRaw = "cats in hats", оно будет сокращено до ☃"cats in hats☃".(Снежный человек Юникода должен проиллюстрировать, как это будет работать для разных языков с разными escape-последовательностями.)

Код $_ESCAPE распознает ☃ как escape-символ формы и выполняет небольшую обработку передпередача \"cats in hats\" в $safeTagSearch.

Это вообще возможно?

Answer 1

Неосуществимо. Безопасность базы данных сложна и часто зависит от типа базы данных. Простое добавление косой черты помогает избежать кавычек, да, но ничего не делает для атак XSS (межсайтовый скриптинг).

Затем, если вы посмотрите на проблемы XSS, вы поймете, что иногда вы хотите разрешить определенный HTML и запретить другие.

Выход и очистка значений - гораздо более сложная проблема, чем вы думаете.

Answer 2

Я не думаю, что это вообще возможно, потому что для этого требуется, чтобы язык веб-программирования знал конкретный синтаксис SQL, который вы используете. Эта функциональность является доменом поставщика базы данных (например, ODBC, OLEDB, SQL Server Native, Jet и т. Д.), Чтобы иметь возможность преобразовывать все входные данные в специфический для SQL-варианта синтаксис, необходимый для выполнения работы в базе данных без ошибки и отсутствие внедрения SQL.

Лекарство не в том, чтобы дать веб-разработчикам опору за неправильное использование составных операторов SQL, а вместо этого, чтобы веб-разработчики использовали формальные параметры в командах (или, по крайней мере, использовали заполнители параметров, такие как ?, в ad-hoc запросы) вместо того, чтобы просто соединять фрагменты SQL и строки параметров вместе и надеяться, что это работает правильно.

Если вы предложите $_ESCAPE для того, чтобы якобы вылечить людей, которые безмозгло используют $_GET, то вы создадите другие проблемы с помощью безмозглого использования , , например, хранения в базе данных строк, которые были сбежал дважды (упс). Это только запутает проблему.

Еще одна проблема, с которой это связано, заключается в том, что вы не знаете, является ли используемая вами строка безопасной или небезопасной. Решение, которое я бы поддержал, - это создание строго типизированных объектов String, которые указывают, какая это строка (HTMLString, UnsafeString, SQLString и т. Д.).

Тогда, если вы попытаетесь сделать что-то вроде <SQLStringFragment> + <UnescapedString>, вы получите ошибку времени компиляции или выполнения при попытке объединить два разных типа строк без предварительного преобразования их в один и тот же тип.

Библиотека БД может быть расширена, чтобы предлагать утилиты преобразования, такие как SQLStringFromParameterValue, которые будут принимать неэкранированную строку и возвращать экранированную строку на основе свойств текущего соединения.