SQL инжекцията е прост вектор за атака, който все още е много разпространен и днес. Причината за това не е никоя друга освен липсата на пач за глупост. Защо казвате това, нека вземем JAVA за пример, за да илюстрираме:
Да предположим, че такава таблица съществува в базата данни:
След това използвайте таблицата за действия на JDBC:
Горният код често се използва от някои разработчици. Представете си ситуация, в която входящият параметър userId е "3; потребител на таблица за изпускане; SQL операторът, който се изпълнява, е както следва:
След като базата данни бъде компилирана и изпълнена, потребителската таблица се изтрива. Вуала, просто атака с SQL инжекции влиза в сила! Това е така, защото горният код не отговаря на програмните спецификации.
Когато програмираме според спецификацията, SQL инжекцията не съществува. Това също е такаПървият начин да се избегне SQL инжекция: предварително компилирани оператори, кодът е следният:
Защо в горния код няма SQL инжекция? Тъй като се използва предварително компилираното изявление, предварително компилираното изявление задава "select name from user, където id=?" Операторът се компилира предварително, така че да трябва да бъде заменен с входящите параметри само при изпълнение? Временните места са добре. В първия несъвместим случай програмата ще напише SQL оператор и след това ще го компилира със съдържанието, предоставено от потребителя, което е точно проблемът.
Освен използването на предварително компилирани оператори, има и втора опцияНачини за избягване на атаки с SQL инжекции: Съхранени процедури。 Съхранената процедура е набор от SQL оператори, които изпълняват конкретна функция, компилирани и съхранени в база данни, и потребителят може да я изпълни, като извика съхранена процедура и даде параметър (ако съхранената процедура има параметри), което също така може да избегне атаки с SQL инжекции
Съответната процедура за съхранение в горния код е следната:
Разбира се, потребителите могат да правят проверка на символи и на фронтенда, което също е начин да се избегне SQL инжекция: например, за параметъра userId по-горе, потребителят ще провери за точка и запетая и ще се появи грешка.
Въпреки това, най-основната причина е, че съществуват SQL инжекционни атаки, защото приложенията не използват най-малко привилегии при достъп до бази данни. Изглежда, че всички използват root акаунта, за да достъпят базата данни.
Как MyBatis избягва атаки с SQL инжекции? Или вземете горния потребител на таблицата като пример:
Да кажем, че mapper файлът е:
Съответните java файлове са:
Можете да видите, че входният параметър е userId от тип String, когато подадем userId="34; потребител на таблица за изпускане; След това отпечатаното изявление гласи:
Независимо от въведения userID, неговото SQL изявление е следното. Това се дължи на факта, че mybatis използва предварително компилирани оператори в основната имплементация. Когато базата данни изпълни това твърдение, тя директно използва предварително компилирания оператор и след това заменя заместителя с преминаващия userId? Просто отиди да тичаш. Първо да сменя заместващите? Процесът на компилация се извършва, така че няма място за оцеляване на SQL инжекция.
Как MyBatis извършва SQL предварителна компилация? Всъщност класът PreparedStatement се използва в долната част на рамката. Класът PreparedStaement не само избягва SQL инжекциите, но и спестява (N-1) време за компилация, когато едно и също SQL изявление се изпълнява N пъти, като по този начин подобрява ефективността.
Ако промените горното твърдение на:
Когато въведем userId="34; потребител на таблица за изпускане; След това отпечатаното изявление гласи:
В момента mybatis не използва предварително компилирани оператори, а първо зашива низове, а след това извършва компилация, което е точно начинът, по който действа SQL инжекцията.
Затова, когато пишете оператори за mybatis mapping, опитайте да използвате формата "#{xxx}". Ако трябва да използвате параметри като "${xxx}", трябва ръчно да ги филтрирате, за да предотвратите атаки с SQL инжекции.
|
Публикувано в 16.08.2018 г. 10:57:34 ч.
|
|
|
