Тестирање за слаби страни на SQL инјекција

SQL Injection напади претставуваат огромни ризици за веб-апликации кои зависат од позадината на базата на податоци за да генерираат динамична содржина. Во овој тип на напад, хакерите манипулираат со веб-апликација, во обид да ги инјектираат своите сопствени SQL-команди во оние издадени од базата на податоци. На пример, видете го написот SQL Injection Attacks на бази на податоци. Во оваа статија, ги разгледуваме неколку начини на кои можете да ги тестирате вашите веб-апликации за да утврдите дали се ранливи на SQL Injection напади.

Автоматизирана SQL инјекција скенирање

Една од можностите е користење на автоматска скенер за ранливост на веб апликациите, како што се HP WebInspect, AppScan на IBM или Henshaw на Cenzic. Овие алатки нудат лесни, автоматски начини да ги анализираат вашите веб апликации за потенцијалните SQL Injection пропусти. Сепак, тие се прилично скапи, трчајќи до 25.000 долари по седиште.

Рачни SQL инјекција тестови

Што е лош развивач на апликации? Вие всушност може да извршите некои основни тестови за да ги оцените вашите веб апликации за ранливоста на SQL Injection користејќи ништо повеќе од веб прелистувач. Прво, еден збор на претпазливост: тестовите што ги опишувам само бараат основни SQL Injection пропусти. Тие нема да откријат напредни техники и се малку досадни за употреба. Ако можете да си го дозволите тоа, одете со автоматски скенер. Меѓутоа, ако не можете да се справите со таа цена, рачното тестирање е одличен прв чекор.

Најлесен начин да се процени дали апликацијата е ранлива е да експериментирате со едноставни инјекциски напади кои, всушност, нема да им наштетат на вашата база на податоци, ако успеат, но ќе ви обезбедат докази дека треба да исправите проблем. На пример, да претпоставиме дека сте имале едноставна веб апликација која гледа на поединец во база на податоци и како резултат добива информации за контакт. Оваа страница може да го користи следниов URL-формат:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Можеме да претпоставиме дека оваа страница врши пребарување на базата на податоци, користејќи пребарување слично на следново:

Избери телефон од директориумот КАДЕ lastname = 'chapple' и firstname = 'mike'

Ајде да експериментираме со ова малку. Со нашата претпоставка погоре, можеме да направиме едноставна промена на УРЛ дека тестовите за напади на SQL инјектирање:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count (*)+from+fake)+%3e0+OR+'1'%3d'1

Ако веб апликацијата не е соодветно заштитена од SQL инјекција, таа едноставно го приклучува ова лажно име во изјавата SQL што ја извршува против базата на податоци, што резултира со:

Избери телефон од директориумот КАДЕ lastname = 'chapple' и firstname = 'mike' И (изберете брои (*) од лажни)> 0 ИЛИ '1' = '1'

Ќе забележите дека горенаведената синтакса е малку поинаква од онаа во оригиналната URL. Ја зедов слободата на конвертирање на URL-кодираната променлива за нивните ASCII еквиваленти за да може полесно да го следат примерот. На пример,% 3d е URL-кодирање за знакот '='. Исто така додадов некои паузи за слични цели.

Оценување на резултатите

Тестот доаѓа кога се обидувате да ја вчитате веб-страницата со URL-то наведени погоре. Ако веб апликацијата е добро однесување, таа ќе ги отстрани единствените цитати од влезот пред да го предаде барањето во базата на податоци. Ова едноставно ќе резултира со чуден збор за некој со име што вклучува еден куп на SQL! Ќе видите порака за грешка од апликацијата слична на онаа подолу:

Грешка: Не е пронајден корисник со име mike + AND + (изберете + count (*) + од + лажни) +% 3e0 + OR + 1% 3d1 Chapple!

Од друга страна, ако апликацијата е подложна на SQL инјекција, таа ќе ја пренесе изјавата директно во базата на податоци, што ќе резултира со една од двете можности. Прво, ако вашиот сервер има детални пораки за грешки овозможени (што не треба!), Ќе видите нешто како ова:

Microsoft OLE DB провајдер за ODBC Drivers грешка '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Неважечко име на објектот 'лажни'. /directory.asp, линија 13

Од друга страна, ако вашиот веб-сервер не прикажува детални пораки за грешки, ќе добиете повеќе генеричка грешка, како што се:

Внатрешна грешка на серверот Серверот наиде на внатрешна грешка или неправилна конфигурација и не можеше да го заврши вашето барање. Ве молиме контактирајте го администраторот на серверот за да го известите за време на грешката и за нешто што можеби сте го направиле, што може да предизвикало грешка. Повеќе информации за оваа грешка може да бидат достапни во дневникот за грешки на серверот.

Ако добиете или една од двете грешки погоре, вашата апликација е подложна на напад на SQL инјекција! Некои чекори што можете да ги преземете за да ги заштитите вашите апликации против нападите на SQL Injection вклучуваат:

• Спроведете проверка на параметри за сите апликации. На пример, ако барате некој да внесе број на купувач, осигурајте се дека влезот е нумерички пред да го изврши барањето .
• Ограничете ги дозволите на сметката што ги извршува SQL-запросите . Се применува правилото за најмала привилегија. Ако сметката што се користи за извршување на барањето нема дозвола да го изврши, тоа нема да успее!
• Користете складирани процедури (или слични техники) за да спречите корисниците директно да комуницираат со SQL-кодот.