Джон Виега. 19 смертных грехов, угрожающих безопасности программ

Java

   В языке Java прямые обращения к памяти также запрещены, поэтому он не так опасен, как C/C++. Но проявлять беспечность все же не следует: как и в C/C++, в Java нет никакой защиты от переполнения целых, и легко можно допустить логические ошибки. О том, какие существуют программные решения, см. в разделе «Искупление греха».

Visual Basic и Visual Basic .NET

   Visual Basic ухитрился превратить проблему переполнения целого в проблему отказа от обслуживания – примерно такую же ситуацию мы имеем при использовании ключевого слова checked в С#. Подозрение должны вызывать те места, где программист применяет механизм перехвата для игнорирования ошибок при работе с целыми. Убедитесь, что ошибки обрабатываются правильно. Следующее предложение в программе на Visual Basic (не Visual Basic .NET) свидетельствует о лености программиста, не пожелавшего обрабатывать ошибки, возникающие во время работы программы. Нехорошо это.

   On Error Continue

Perl

   Perl – замечательный язык, но математика чисел с плавающей точкой может преподнести неожиданности. По большей части Perl делает то, чего от него ожидают, но будьте осторожны: это очень многогранный язык. В особенности это относится к случаям, когда вы обращаетесь к модулям, являющимся тонкой оберткой вокруг системных вызовов.

Тестирование

   Если на вход подаются строки символов, попробуйте задать размеры так, чтобы вызвать ошибку. Часто это происходит, если длина строки составляет 64К или 64К – 1 байтов. Также ошибки возможны для длин, равных 127, 128, 255 и 32К плюс–минус единица. Если вам удалось подобрать тест так, что прибавление единицы к числу вызвало изменение знака или обращение в нуль, значит, вы не зря потрудились.
   Если программа допускает прямой ввод числовых данных, например в структурированный документ, попробуйте очень большие числа и обращайте особое внимание на граничные случаи.

Примеры из реальной жизни

   Поиск по запросу «integer overflow» в базе данных уязвимостей на сайте Security Focus дает больше 50 документов, а в базе CVE – 65 документов. Вот лишь несколько из них.

Ошибка в интерпретаторе Windows Script позволяет выполнить произвольный код

   Цитата из бюллетеня CVE (CAN–2003–0010):
 
   Переполнение целого в функции JsArrayFimctionHeapSort, используемой в Windows Script Engine для JScript (JScript.dll), в различных операционных системах Windows позволяет противнику выполнить произвольный код путем подготовки Web–страницы или электронного письма в формате HTML, в котором используется большой индекс массива. При этом возникает переполнение размещенного в куче буфера и открывается возможность для атаки.
 
   Интересная особенность этой ошибки в том, что переполнение возникает в языке сценариев, не допускающем прямого обращения к памяти. Выпущенный по этому поводу бюллетень Microsoft можно найти на странице www.microsoft.com/ technet/security/bulletin/MS03–008.mspx.

Переполнение целого в конструкторе объекта SOAPParameter

   Еще одна ошибка в языке сценариев (документ CAN–2004–0722 в базе CVE) описана на сайте Red Hat Linux (www.redhat.com) следующими словами:
 
   Zen Parse сообщил о некорректном контроле входных данных в конструкторе объекта SOAPParameter, что приводит к переполнению целого с последующей порчей кучи. Можно написать вредоносную программу на языке JavaScript, которая воспользуется этой ошибкой для выполнения произвольного кода.
 
   В том же отчете читаем далее:
 
   Во время аудита исходных текстов Крис Эванс (Chris Evans) обнаружил переполнение буфера и переполнение целого в библиотеке libpng, используемой в браузере Mozilla. Противник может создать специальный PNG–файл, при просмотре которого в этом браузере либо произойдет аварийный останов, либо будет выполнен произвольный код.

Переполнение кучи в HTR–документе, передаваемом поблочно, может скомпрометировать Web–сервер

   Вскоре после того, как об этой ошибке стало известно (в июне 2002 года), последовали многочисленные атаки на уязвимые серверы IIS. Подробности можно найти на странице www.microsoft.com/technet/security/bulletin/MS02–028.mspx, но суть проблемы в том, что обработчик HTR–документов принимал от пользователя данные длиной 64К – 1, прибавлял 1 (нам ведь нужно место для завершающего нуля), после чего запрашивал буфер длиной 0 байтов. Неизвестно, то ли Билл Гейтс сказал, что 64К хватит любому, то ли это интернетовская легенда, но любой хакер сможет уместить в 64К такой shell–код, что мало не покажется!

Искупление греха

   По–настоящему избавиться от ошибок переполнения целого можно, только если вы хорошо понимаете суть проблемы. Но все же опишем несколько шагов, которые помогут не допустить такой ошибки. Прежде всего пользуйтесь всюду, где возможно, числами без знака. В стандарте C/C++ описан тип size_t для представления размеров, и разумные программисты им пользуются. Контролировать беззнаковые целые гораздо проще, чем знаковые. Ну нет же смысла применять число со знаком для задания размера выделяемой памяти!
   Избегайте «хитроумного» кода – контроль целых должен быть прост и понятен. Вот пример чересчур заумного кода для контроля переполнения при сложении:

   int a, b, c;
   c = a + b;
   if(a ^ b ^ c < 0)
   return BAD_INPUT;

   В этом фрагменте масса проблем. Многим из нас потребуется несколько минут на то, чтобы понять, что же автор хотел сделать. А кроме того, код дает ложные срабатывания – как позитивные, так и негативные, то есть работает не всегда. Вот другой пример проверки, дающей правильный результат не во всех случаях:

   int a, b, c;
   c = a * b;
   if(c < 0)
   return BAD_INPUT;

   Даже если на входе допустимы только положительные числа, этот код все равно пропускает некоторые переполнения. Возьмем, к примеру, выражение (2 ^А 30 + + 1) * 8, то есть 2 ^А 33 + 8. После отбрасывания битов, вышедших за пределы 32 разрядов, получается 8. Это число положительно, а ошибка тем не менее есть. Безопаснее решить эту задачу, сохранив результат умножения 32–разрядных чисел в 64–разрядном, а затем проверить, равен ли хотя бы один из старших битов единице. Это и будет свидетельством переполнения.
   Когда встречается подобный код:

   unsigned a, b;
   ...
   if (a * b < MAX) {
   ...
   }

   проще ограничить а и b значениями, произведение которых заведомо меньше МАХ. Например:

   #include «limits.h»
   #define MAX_A 10000
   #define MAX_A 250
   assert(UINT_MAX / MAX_A >= MAX_B); // проверим, что MAX_A и MAX_B
                                                         // достаточно малы
   if (a < MAX_A && b < MAX_B) {
   ...
   }

   Если вы хотите надежно защитить свой код от переполнений целого, можете воспользоваться классом Safelnt, который написал Дэвид Лебланк (подробности в разделе «Другие ресурсы»). Но имейте в виду, что, не перехватывая исключения, возбуждаемые этим классом, вы обмениваете возможность выполнения произвольного кода на отказ от обслуживания. Вот пример использования класса Safelnt:

   size_t CalcAllocSize(int HowMany, int Size, int HeaderLen)
   {
   try{
   SafeInt<size_t> tmp(HowMany);
   return tmp * Size + SafeInt<size_t>(HeaderLen);
   }
   catch(SafeIntException)
   {
   return (size_t)~0;
   }
   }

   Целые со знаком используются в этом фрагменте только для иллюстрации; такую функцию следовало бы писать, пользуясь одним лишь типом size_t. Посмотрим, что происходит «под капотом». Прежде всего проверяется, что значение HowMany неотрицательно. Попытка присвоить отрицательное значение беззнаковой переменной типа Safelnt вызовет исключение. Затем Safelnt умножается на переменную Size типа int, при этом проверяется как переполнение, так и попадание в допустимый диапазон. Результат умножения Safelnt * int – это снова Safelnt, поэтому далее выполняется операция контролируемого сложения. Обратите внимание на приведение входного параметра типа int к типу Safelnt – отрицательная длина заголовка с точки зрения математики, может быть, и допустима, но с точки зрения здравого смысла – нет, поэтому размеры лучше представлять числами без знака. Наконец, перед возвратом величина типа Safelnt<size_t> преобразуется обратно в size_t, это пустая операция. Внутри класса Safelnt выполняется много сложных проверок, но ваш код остается простым и понятным.
   Если вы программируете на С#, включайте флаг /checked и применяйте unchecked–блоки только для того, чтобы отключить контроль в отдельных предложениях.

Дополнительные защитные меры

   Если вы работаете с компилятором gcc, то можете задать флаг–ftrapv. В этом случае за счет обращения к различным функциям во время выполнения будут перехватываться переполнения при операциях со знаковыми и только со знаковыми целыми. Неприятность в том, что при обнаружении переполнения вызывается функция abort().
   Компилятор Microsoft Visual С++ 2005 автоматически обнаруживает переполнение при вызове оператора new. Ваша программа должна перехватывать исключения std::bad_alloc, иначе произойдет аварийный останов.

Другие ресурсы

   □ «Integer Handling with the С++ Safelnt Class», David LeBlanc, msdn.microsoft.com/library/default.asp?url=/library/en–us/dncode/html/ secure01142004.asp
   □ «Another Look at the Safelnt Class», David LeBlanc, http://msdn.microsoft.com/ library/default.asp?url=/library/en–us/dncode/html/secure05052005.asp
   □ «Reviewing Code for Integer Manipulation Vulnerabilities*, Michael Howard, http://msdn. microsoft, com/library/default.asp?url=/library/en–us/dncode/ html/ secure04102003.asp
   □ «An Overlooked Construct and an Integer Overflow Redux», Michael Howard, http://msdn. microsoft, com/library/default.asp?url=/library/en–us/dncode/ html/ secure09112003.asp
   □ «Expert Tips for Finding Security Defects in Your Code», Michael Howard, http://msdn.microsoft.eom/msdnmag/issues/03/l 1/SecurityCodeReview/ default.aspx
   □ «Integer overflows – the next big threat», Ravind Ramesh, central.com/tech/story.asp?file=/2004/10/26/itfeature/9170256&sec=itfeature
   □ DOS against Java JNDI/DNS, http://archives.neophasis.com/archives/ bugtraq/2004–11 / 0092.html

Резюме

   Рекомендуется
   □ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяется размер выделяемой памяти.
   □ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяются индексы массивов.
   □ Пользуйтесь целыми без знака для хранения смещений от начала массива и размеров блоков выделяемой памяти.
   Не рекомендуется
   □ Не думайте, что ни в каких языках, кроме C/C++, переполнение целого невозможно.

Грех 4.
Внедрение SQL–команд

В чем состоит грех

   Уязвимость для внедрения SQL–команд (или просто «внедрение SQL») – это широко распространенный дефект, который может привести к компрометации машины и раскрытию секретных данных. А печальнее всего то, что от этой ошибки часто страдают приложения электронной коммерции и программы, обрабатывающие конфиденциальные данные и персональную информацию. Опыт авторов показывает, что многие приложения, работающие с базами данных, которые создавались для внутреннего использования или обмена информацией с партнерами по бизнесу, подвержены внедрению SQL.
   Никогда не интересовались, как хакеры воруют номера кредитных карточек с Web–сайтов? Одним из двух способов: либо внедряя SQL, либо заходя через парадный вход, который вы распахиваете перед ними, открывая порт сервера базы данных (ТСР/1433 для Microsoft SQL Server, TCP/1521 для Oracle, TCP/523 для IBM/DB2 и TCP/3306 для MySQL) для доступа из Интернет и оставляя без изменения принимаемый по умолчанию пароль администратора базы данных.
   Быть может, самая серьезная опасность, связанная с внедрением SQL, – это получение противником персональных или секретных данных. В некоторых странах, штатах и отраслях промышленности вас за это могут привлечь к суду. Например, в штате Калифорния можно сесть в тюрьму по закону о защите тайны личной жизни в сети, если из управляемой вами базы данных была похищена конфиденциальная или персональная информация. В Германии §9 DBSG (Федеральный закон о защите данных) требует, чтобы были предприняты должные организационные и технические меры для защиты систем, в которых хранится персональная информация. Не забывайте также о действующем в США Акте Сарбанеса–Оксли от 2002 года, и прежде всего о параграфе 404, который обязывает защищать данные, на основе которых формируется финансовая отчетность компании. Система, уязвимая для атак с внедрением SQL, очевидно, имеет неэффективные средства контроля доступа, а значит, не соответствует всем этим установлениям.
   Напомним, что ущерб не ограничивается данными, хранящимися в базе. Внедрение SQL может скомпрометировать сам сервер, а не исключено, что и сеть целиком. Для противника скомпрометированный сервер базы данных – это лишь ступень к новым великим свершениям.

Подверженные греху языки

   Все языки программирования, применяемые для организации интерфейса с базой данных, уязвимы! Но прежде всего это относится к таким языкам высокого уровня, как Perl, Python, Java, технологии «серверных страниц» (ASP, ASP.NET, JSP и PHP), С# и VB.NET. Иногда оказываются скомпрометированными также и языки низкого уровня, например библиотеки функций или классов, написанные на С или С++ (к примеру, библиотека c–tree компании FairCom или Microsoft Foundation Classes). Наконец, не свободен от греха и сам язык SQL.

Как происходит грехопадение

   Самый распространенный вариант греха совсем прост – атакующий подсовывает приложению специально подготовленные данные, которые тот использует для построения SQL–предложения путем конкатенации строк. Это позволяет противнику изменить семантику запроса. Разработчики продолжают использовать конкатенацию, потому что не знают о существовании других, более безопасных методов. А если и знают, то не применяют их, так как, говоря откровенно, конкатенация – это так просто, а для вызова других функций еще подумать надо. Мы могли бы назвать таких программистов лентяями, но не станем.
   Реже встречается другой вариант атаки, заключающийся в использовании хранимой процедуры, имя которой передается извне. А иногда приложение принимает параметр, конкатенирует его с именем процедуры и исполняет получившуюся строку.

Греховность С#

   Вот классический пример внедрения SQL:

   using System.Data;
   using System.Data.SqlClient;
   ...
   string ccnum = "None";
   try {
   SqlConnection sql = new SqlConnection(
   @"data source=localhost;" +
   "user id=sa;password=pAs$w0rd;");
   sql.Open();
   string sqlstring="SELECT ccnum" +
   " FROM cust WHERE id=" + Id;
   SqlCommand cmd = new SqlCommand(sqlstring,sql);
   try {
   ccnum = (string)cmd.ExecuteScalar();
   } catch (SqlException se) {
   Status = sqlstring + " failed\n\r";
   foreach (SqlError e in se.Errors) {
   Status += e.Message + "\n\r";
   }
   } catch (SqlException e) {
   // Ой!
   }

   Ниже приведен по существу такой же код, но SQL–предложение строится с помощью замены подстроки, а не конкатенации. Это тоже ошибка.

   using System.Data;
   using System.Data.SqlClient;
   ...
   string ccnum = "None";
   try {
   SqlConnection sql = new SqlConnection(
   @"data source=localhost;" +
   "user id=sa;password=pAs$w0rd;");
   sql.Open();
   string sqlstring="SELECT ccnum" +
   " FROM cust WHERE id=%ID%";
   String sqlstring2 = sqlstring.Replace("%ID", id);
   SqlCommand cmd = new SqlCommand(sqlstring2,sql);
   try {
   ccnum = (string)cmd.ExecuteScalar();
   } catch (SqlException se) {
   Status = sqlstring + " failed\n\r";
   foreach (SqlError e in se.Errors) {
   Status += e.Message + "\n\r";
   }
   } catch (SqlException e) {
   // Ой!
   }

Греховность PHP

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

   <?php
   $db = mysql_connect("localhost","root","$$sshhh...!");
   mysql_select_db("Shipping",$db);
   $id = $HTTP_GET_VARS["id"];
   $qry = "SELECT ccnum FROM cust WHERE id = %$id%";
   $result = mysql_query($qry,$db);
   if ($result) {
   echo mysql_result($result,0,"ccnum");
   } else {
   echo "No result! " . mysql_error();
   }
   ?>

Греховность Perl/CGI

   И снова тот же дефект, но на этот раз в программе на достопочтенном Perl:

   #!/usr/bin/perl
   use DBI;
   use CGI;
   print CGI::header();
   $cgi = new CGI;
   $id = $cgi->param('id');
   $dbh = DBI->connect('DBI:mysql:Shipping:localhost',
   'root',
   '$3cre+')
   or print "Ошибка connect : $DBI::errstr";
   $sql = "SELECT ccnum FROM cust WHERE id = " . $id;
   $sth = $dbh->prepare($sql)
   or print "Ошибка prepare : $DBI::errstr";
   $sth->execute()
   or print "Ошибка execute : $DBI::errstr";
   # Вывести данные
   while (@row = $sth->fetchrow_array ) {
   print "@row<br>";
   }
 
   $dbh->disconnect;
   print "</body></html>";
 
   exit;

Греховность Java

   Еще один распространенный язык, Java. Подвержен внедрению SQL по той же схеме.

   import java.*;
   import java.sql.*;
   ...
   public static boolean doQuery(String Id) {
   Connection con = null;
   try
   {
   Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");
   con = DriverManager.getConnection("jdbc:microsoft:sqlserver: " +
                                              "//localhost:1433", "sa", "$3cre+");
   Statement st = con.createStatement();
   ResultSet rs = st.executeQuery("SELECT ccnum FROM cust WHERE id=" +
                                      Id);
   while (rx.next()) {
   // Полюбоваться на результаты запроса
   }
 
   rs.close();
   st.close();
   }
   catch (SQLException e)
   {
   // Ой!
   return false;
   }
   catch (ClassNotFoundException e)
   {
   // Не найден класс
   return false;
   }
   finally
   {
   try
   {
   con.close();
   } catch(SQLException e) {}
   }
   return true;
   }

Греховность SQL

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

   CREATE PROCEDURE dbo.doQuery(@query nchar(128))
   AS
   exec(@query)
   RETURN

   А вот следующий код распространен куда шире и не менее опасен:

   CREATE PROCEDURE dbo.doQuery(@id nchar(128))
   AS
   DECLARE @query nchar(256)
   SELECT @query = 'select ccnum from cust where id = ''' + @id + ''''
   EXEC @query
   RETURN

   Здесь опасная конкатенация строк выполняется внутри процедуры. То есть вы по–прежнему совершаете постыдный грех, даже если процедура вызвана из корректного кода на языке высокого уровня.
   Стоит поискать и другие операторы конкатенации, имеющиеся в SQL, а именно «+» и «||», а также функции CONCAT() и CONCATENATE().
   Во всех этих примерах противник контролирует переменную Id. Важно всегда представлять себе, что именно контролирует атакующий, это поможет понять, есть реальная ошибка или нет. В данном случае противник может задать любое значение переменной Id, участвующей в запросе, и тем самым управлять видом строки запроса. Последствия могут оказаться катастрофическими.
   Классическая атака состоит в том, чтобы видоизменить SQL–запрос, добавив лишние части и закомментарив «ненужные». Например, если противник контролирует переменную Id, то может задать в качестве ее значения строку 1 or 2>1 – – , тогда запрос примет такой вид:

   SELECT ccnum FROM cust WHERE id=1 or 2>1 – –

   Условие 2>1 истинно для всех строк таблицы, поэтому запрос возвращает все строки из таблицы cust, другими словами, номера всех кредитных карточек. Можно было бы воспользоваться классической атакой «1 = 1», но сетевые администраторы часто включают поиск такой строки в системы обнаружения вторжений (IDS), поэтому мы применили условие «2>1», которое столь же эффективно, но «проходит под лучом радара».
   Оператор комментария – – убирает из поля зрения сервера все последующие символы запроса, которые могла бы добавить программа. В одних базах данных для комментирования применяются символы —, в других – #. Проверьте, что воспринимает в качестве комментария ваша база.
   Различных вариантов атак слишком много, чтобы перечислять их здесь, дополнительный материал вы найдете в разделе «Другие ресурсы».

Родственные грехи

   Во всех приведенных выше примерах демонстрируются и другие грехи:
   □ соединение от имени учетной записи с высоким уровнем доступа;
   □ включение пароля в текст программы;
   □ сообщение противнику излишне подробной информации в случае ошибки.
   Рассмотрим их по порядку. Везде соединение устанавливается от имени административного или высокопривилегированного пользователя, хотя достаточно было бы пользователя, имеющего доступ только к одной базе данных. Это означает, что противник потенциально сможет манипулировать и другой информацией, а то и всем сервером. Короче говоря, соединение с базой данных от имени пользователя с высоким уровнем доступа – скорее всего, ошибка и нарушение принципа наименьших привилегий.
   «Зашивание» паролей в код – почти всегда порочная идея. Подробнее см. грех 11 и 12 и предлагаемые там «лекарства».
   Наконец, в случае ошибки противник получает слишком много информации. Воспользовавшись ей, он сможет получить представление о структуре запроса и, быть может, даже узнать имена объектов базы. Более подробную информацию и рекомендации см. в грехе 6.

Где искать ошибку

   Любое приложение, обладающее перечисленными ниже характеристиками, подвержено риску внедрения SQL:
   □ принимает данные от пользователя;
   □ не проверяет корректность входных данных;
   □ использует введенные пользователем данные для запроса к базе;
   □ применяет конкатенацию или замену подстроки для построения SQL–запроса либо пользуется командой SQL exec (или ей подобной).

Выявление ошибки на этапе анализа кода

   Во время анализа кода на предмет возможности внедрения SQL прежде всего ищите места, где выполняются запросы к базе данных. Ясно, что программам, не обращающимся к базе данных, эта напасть не угрожает. Мы обычно ищем следующие конструкции:

 
   Выяснив, что в программе есть обращения к базе данных^[1], нужно определить, где выполняются запросы и насколько можно доверять данным, участвующим в запросе. Самое простое – найти все места, где выполняются предложения SQL, и посмотреть, производится ли конкатенация или подстановка небезопасных данных, взятых, например, из строки Web–запроса, из Web–формы или аргумента SOAP. Вообще, любых поступающих от пользователя данных!

Тестирование

   Надо признать, что реальной альтернативы добросовестному анализу кода на предмет внедрения SQL не существует. Но иногда у вас может не быть доступа к коду, или вы просто не имеет опыта чтения чужих программ. Тогда дополните анализ кода тестированием.
   Прежде всего определите все точки входа в приложение, где формируются SQL–запросы. Затем создайте тестовую программу–клиент, которая будет посылать в эти точки частично некорректные данные. Например, если тестируется Web–приложение, которое строит запрос на основе одного или нескольких полей формы, попробуйте вставить в них произвольные ключевые слова языка SQL. Следующий пример на Perl показывает, как это можно сделать.

   #!/usr/bin/perl
   use strict;
   use HTTP::Request::Common qw(POST GET);
   use HTTP::Headers;
   use LWP::UserAgent;
   srand time;
   # Приостановить исполнение, если найдена ошибка
   my $pause = 1;
   # Тестируемый URL
   my $url = 'http://mywebserver.xyzzy123.com/cgi-bin/post.cgi';
   # Максимально допустимый размер HTTP-ответа
   my $max_response = 1000;
 
   # Допустимые города
   my @cities = qw(Auckland Seattle London Portland Manchester Redmond
   Brisbane Ndola);
 
   while (1) {
   my $city = randomSQL($cities[rand @cities]);
   my $zip = randomSQL(10000 + int(rand 89999));
 
   print «Пробую [$city] и [zip]\n»;
   my $ua = LWP::UserAgent->new();
   my $req = POST $url,
   [ City => $city,
   ZipCode => $zip,
   ];
   # Послать запрос, получить ответ и поискать в нем признаки ошибки
   my $res = $ua->request($req);
   $_ = $res->as_string;
   die "Хост недостижим\n" if /bad hostname/ig;
   if ($res->status_line != 200
   || /error/ig
   || length($_) > $max_response) {
   print "\nПотенциальная возможность внедрения SQL\n";
   print;
   getc if $pause;
   }
   }
 
   # Выбрать случайное ключевое слово SQL, в 50% случаев перевести
   # его в верхний регистр
   sub randomSQL() {
   $_ = shift;
 
   return $_ if ($rand > .75);
 
   my @sqlchars = qw(1=1 2>1 «fred=»fre" + "d" or and select union
                            drop update insert into dbo < > = ( ) ' .. – #);
 
   my $sql = $sqlchars[rand @sqlchars];
   $sql = uc($sql) id rand > .5;
 
   return $_ . ' ' . $sql if rand > .9;
   return $sql . ' ' . $_ if rand > .9;
   return $sql;
   }

   Этот код обнаружит возможность внедрения SQL только в случае, когда приложение возвращает сообщение об ошибке. Как мы уже сказали, нет ничего лучше тщательного анализа кода. Другой способ тестирования заключается в том, чтобы воспользоваться приведенной выше Perl–программой, заранее выяснить, как выглядит нормальный ответ, а затем анализировать, на какие запросы получен ответ, отличающийся от правильного, или вообще нет никакого ответа.
   Имеются также инструменты третьих фирм, например AppScan компании Sanctum (теперь Watchfire) (www.watchfire.com), Weblnspect компании SPI Dynamics (www.spidynamics.com) и ScanDo компании Kavado (www.kavado.com).
   Для оценки инструмента рекомендуем создать небольшое тестовое приложение с известными ошибками, допускающими внедрение SQL, и посмотреть, какие ошибки этот инструмент сумеет найти.

Примеры из реальной жизни

   Следующие примеры внедрения SQL–команд взяты из базы данных CVE (http://cve.mitre.org).

CAN–2004–0348

   Цитата из бюллетеня CVE: «Уязвимость, связанная с внедрением SQL в сценарии viewCart.asp из программного обеспечения корзины для покупок компании SpiderSales, позволяет удаленному противнику выполнить произвольный SQL–запрос, воспользовавшись параметром userld».
   Многие сценарии в программах SpiderSales не проверяют параметр userld, и этим можно воспользоваться для проведения атаки с внедрением SQL. Успешная атака позволяет противнику получить доступ к интерфейсу администратора SpiderSales и прочитать любую информацию из базы данных электронного магазина.