Атаките на 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 адрес:
Можем да предположим, че тази страница извършва търсене в базата данни, като използва заявка, подобна на следната:
ИЗБЕРИ телефон от директория WHERE последно име = 'chapple' и firstname = 'mike'Нека експериментираме с това малко. С нашето предположение по-горе, можем да направим проста промяна в URL адреса, който тества за атаки на SQL инжектиране:
http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1Ако уеб приложението не е правилно защитено срещу SQL инжектиране, то просто вмъква това фалшиво първо име в SQL извлечението, което изпълнява срещу базата данни, което води до:
SELECT телефон от директорията WHERE име = 'chapple' и име = 'mike' И (изберете броя (*) от фалшиви)> 0 ИЛИ '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 включват:
- Внедрете проверка на параметрите на всички приложения. Ако например поискате от някого да въведете клиентски номер, уверете се, че входът е цифров, преди да изпълните заявката .
- Ограничете разрешенията на акаунта, който изпълнява SQL заявки . Прилага се правилото за най-малката привилегия. Ако профилът, използван за изпълнение на заявката, няма разрешение да я изпълни, няма да успее!
- Използвайте съхранени процедури (или подобни техники), за да предотвратите директното взаимодействие на потребителите с SQL кода.