Атаките на SQL Injection създават огромни рискове за уеб приложения, които зависят от базата данни на база данни за генериране на динамично съдържание. При този тип атаки хакерите манипулират уеб приложение в опит да внесат свои собствени SQL команди в тези, издадени от базата данни. За пример вижте статията SQL Injection Attacks on Databases. В тази статия разглеждаме няколко начина, по които можете да тествате уеб приложенията си, за да определите дали те са уязвими към SQL Injection атаки.
Автоматизирано сканиране чрез инжектиране на SQL
Една от възможностите е използването на автоматизиран уеб скенер за уязвимост на уеб приложения, като например WebInspect на HP, AppScan на IBM или Гражданска градушка на Cenzic. Всички тези инструменти предлагат лесни, автоматизирани начини за анализ на вашите уеб приложения за потенциални уязвимости на SQL Injection. Те обаче са доста скъпи, достигайки до $ 25,000 на седалка.
Ръчни тестове за инжектиране на SQL
Какво трябва да се направи беден разработчик на приложения? Всъщност можете да изпълните някои основни тестове, за да оцените вашите уеб приложения за уязвимости на SQL Injection, като използвате само уеб браузър. Първо, една дума с повишено внимание: тестовете, които описваме, търсят само основни SQL Injection недостатъци. Те няма да открият усъвършенствани техники и са досадни за употреба. Ако можете да си го позволите, отидете с автоматичен скенер. Ако обаче не можете да се справите с този ценови маркер, ръчното тестване е страхотна първа стъпка.Най-лесният начин да прецените дали дадено приложение е уязвимо е да експериментирате с безвредни инжективни атаки, които всъщност няма да навредят на вашата база данни, ако успеят, но ще ви осигурят доказателства, че трябва да коригирате проблем. Да предположим, например, че имате просто уеб приложение, което търси човек в база данни и като резултат предоставя информация за контакт. Тази страница може да използва следния формат на URL адрес: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike
Можем да предположим, че тази страница извършва търсене в базата данни, като използва заявка, подобна на следната: Изберете телефон
FROM директория
WHERE последно име = "чапли" и име = "mike"
Нека експериментираме с това малко. С нашето предположение по-горе, можем да направим проста промяна в URL адреса, който тества за атаки на SQL инжектиране: http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1
Ако уеб приложението не е правилно защитено срещу SQL инжектиране, то просто вмъква това фалшиво първо име в SQL извлечението, което изпълнява срещу базата данни, което води до: Изберете телефон
FROM директория
WHERE последно име = "чапли" и име = "mike"
И (изберете броя (*) от фалшиви)> 0
ИЛИ '1' = '1'
Ще забележите, че горепосоченият синтаксис е малко по-различен от този в първоначалния URL адрес. Възползвахме се от възможността да конвертираме променливата, кодирана в URL, за техните ASCII еквиваленти, за да улесним примера. Например,% 3d е кодирането на URL за знака "=". Също така добавихме някои прекъсвания на линия за подобни цели. Тестът идва, когато се опитате да заредите уеб страницата с посочения по-горе URL адрес. Ако уеб приложението се държи добре, ще изтрие единичните кавички от входа, преди да премине заявката към базата данни. Това просто ще доведе до странно търсене за някой с първо име, което включва куп SQL. Ще видите съобщение за грешка от приложението, подобно на това по-долу: Грешка: Няма намерен потребител с име mike + AND + (изберете + брой (*) + от + фалшив) +% 3e0 + OR + 1% 3d1
Chapple!
От друга страна, ако приложението е уязвимо за SQL инжекция, то ще предаде изявлението директно към базата данни, което ще доведе до една от двете възможности. Първо, ако в сървъра ви са активирани подробни съобщения за грешка (които не би трябвало), ще видите нещо подобно: Доставчикът на Microsoft OLE DB за ODBC драйвери "80040e37"
Microsoft ODBC SQL Server Driver SQL Server Невалидно име на обект "фалшив".
/directory.asp, ред 13
От друга страна, ако уеб сървърът ви не показва подробни съобщения за грешка, ще получите по-обща грешка, като например: Вътрешна грешка на сървъраСървърът е открил вътрешна грешка или неправилно конфигуриране и не е успял да изпълни заявката ви.
Моля, свържете се със администратора на сървъра, за да съобщите за часа, в който е възникнала грешката, и за всичко, което може да сте направили, което може да е причинило грешката.
Повече информация за тази грешка може да е налична в регистъра за грешки на сървъра.
Ако получите някоя от двете грешки по-горе, вашето приложение е уязвимо за SQL инжекция атака. Някои стъпки, които можете да предприемете, за да защитите приложенията си от атаки срещу SQL Injection включват: Оценка на резултатите
