Някои неща не се променят и си остават вечно актуални. Например SQL – релационните бази данни надживяват всички технологии, които бързат да обявят края им. А същото важи и за най-разпространената атака върху киберсигурността, която използва невнимание именно в тяхната имплементация.
SQL Injection, или инжектирането на вредоносни и неочаквани заявки, е винаги актуална опасност, за която си струва да имаме едно наум. Съвременните технологии за бекенд програмиране знаят как да ни помогнат да се предпазваме, но пък и няма как да се справят сам-самички, ако ние не сме достатъчно предпазливи за рисковете в тази област. Ето какво е важно да знаем.
Старо, но златно
SQL Injection е най-старата сред всички популярни технологии за посегателство онлайн. Разбира се, зад това название се крият много различни конкретни техники, уязвимости и детайли. Но това, което ги обединява, е фактът, че се използва допусната от програмистите уязвимост при защитата на SQL, на различните релационни бази данни, която позволява те да бъдат атакувани с неочаквана заявка. Да бъдат принудени да споделят защитена информация, да блокират заради неправилно обработена грешка, за променят, изтрият определен запис от таблиците си и какво ли още не.
MySQL, Oracle, SQL Server – безброй са различните технологични решения, които се базират върху един и същи принцип за организираме на данните на сървъра. Работят с някой от много сходните езици, с чиято помощ клиентът се свързва с тях, за да запише, промени, изтрие или получи определена информация.
Езиците, които се ползват за целта, са доста семпли в сравнение с другите „говори“ от света на програмирането, ясни и конкретни. Или поне така изглеждат. От своя страна ги „говорят“ с тях популярните езици и фреймуърци, на които се пише бекенд в днешно време. Тяхна е ролята за това да приемат същинската заявка на потребителя и да я превърнат във връзка с базата данни, така че приложението да сработи.
И именно това ги прави уязвимо звено, особено тогава, когато бекенд програмистите не знаят за какво да внимават и допуснат заявката да стигне от зложелателния потребител директно до базата данни.
Страх от инжекции
Ролята на фронтенда е да осигурява удобство на потребителя. А на бекенда – да му дава данните, докато, обаче, ги пази достатъчно сигурно. И именно грешка на специалистите, които се грижат за него, може да доведе до успешна SQL Injection атака.
И всичко е толкова просто, само не бива да допускаме заявките да отидат в директен, необработен вид до базата? Единствено звучи така, защото понякога тези заявки могат да бъдат скрити и почти неразпознаваеми за бекенд кода. Защото могат да изглеждат като нормални заявки. Защото понякога пък се получават пропуски в библиотеките, които ползвате и проблемът може да дойде дори без самите програмисти на проекта да имат каквато и да било вина.
Колко страшно може да е всичко? Не искаме да ви плашим, но… с недобре защитен бекенд, е напълно възможно SQL Injections атаката да завърши с това хакерът да се сдобие с цялата база потребителски имена и пароли на даден сайт. И тогава, пази боже, ако не са били хеширани, каквито случаи, за съжаление, все още съществуват. И това не е всичко – някои типове уязвимости позволяват хакерът да получи достъп и да се сдобие с цялата база данни на сървъра. Даже не е необходимо да споменаваме колко опасно може да бъде това.
Ако пък достъпът за получаване на данни е добре защитен, нападателят би могъл да добавя данни, което е не по-малка опасност. Или просто да изтрие всичко и дано имате сигурен бекъп…
WHERE Vulnerable=’true’
Примерите, които ще дадем, са много прости и, разбира се, далеч не отразяват въображението, което могат да имат хакерите. И все пак, ето как изглежда като псевдокод една SQL заявка, която при незащитена база данни ще върне на зложелателя особено важна информация:
SELECT id
FROM users
WHERE username=“” + name +
AND password=“” + pass + “”
На пръв поглед изглежда като съвсем нормална заявка, с която се подават потребителското име и хешираната (надяваме се!) парола, само че… накрая има един допълнителен празен низ (както се казват стринговете на български, макар да не си го припомняме често). В резултат, някои от по-старите сървъри могат да интерпретират края на заявката като:
password’ OR 1=1
По този начин цялата заявка се превръща в:
SELECT id FROM users WHERE username=’username’ AND password=’password’ OR 1=1
Обаче… 1 винаги е равно на 1. Така заявката връща първия запис в списъка по подразбиране, а това… обикновено е администраторът. Атакуващият получава администраторски права и може да продължи да прави пакостите, които намери за добре.
Същото, като например:
SELECT ItemName, ItemDescription
FROM Item
WHERE ItemNumber = ItemNumber
Съединението прави…
Друг често използван за атаки оператор е UNION. Обикновено той се използва, за да комбинира резултатите от две или повече SELECT заявки в един.
Например, имаме заявката:
GET http://test.com/artists.php?artist=1
Тя е напълно нормална. Рискът се крие в допълнителният параметър, с който искаме първия от изпълнителите в таблицата. Единият от вариантите е заявката да бъде подведена с невъзможен параметър, например отрицателен и после да се добави допълнителна заявка с UNION:
GET http://test.com/artists.php?artist=-1 UNION SELECT 1, 2, 3
По този начин невалидната заявка може да се използва, за да се вземе информация от колони в друга, защитена таблица. Например, отново парола:
GET http://test.com/artists.php?artist=-1 UNION SELECT 1 FROM users WHERE name=’admin’
Код кодувам
Но стига псевдокод, той беше само за илюстрация, курсове по програмиране онлайн има под път и над път.
Единственият сигурен начин да се предотврати атаката, е като се прави валидация на въведените данни на заявките с параметри, като всеки от параметрите се валидира поотделно.
Както споменахме, всички днешни фреймуърци обещават, че правят това вместо нас, и все пак… статистиката продължава да показва, че атаките с SQL Injection съвсем не са изчезнали, а напротив – представляват доста сериозен процент от пробивите в сигурността.
Затова важно е да обновявате софтуера си и, по възможност, да проверявате сами как стоят нещата, влизайки в ролята на „бели хакери“. Можете да намерите онлайн немалък списък с куерита, които да използвате за целта, а съвсем не е толкова трудно да направите скрипт или сървиз, който да го прави вместо вас.
Има и приложения, които вече са създадени и готови за употреба. Например ето този продукт, който прави именно същата проверка – „пуска“ през сайта ви най-често уязвимите заявки и ви сигнализира, ако нещо не е както трябва. Подобни на него има немалко, можете да експериментирате и да намерите най-добрия за своите нужди.
Грешка и прошка
Важно е също грешките от базата данни да бъдат прихванати и достатъчно добре „маскирани“ от бекенда на сайта ви, защото по тях атакуващите могат да разберат много за софтуера и хардуера, които ползвате, и да съобразят атаките си с неговите слабости. Особено, ако става дума за по-стари решения с добре известни уязвимости.
Много от уязвимостите пък са специфични за различните бекенд технологии, така че не е лоша идея да си освежите информацията за конкретните рискове, като потърсите повече информация по темата специално за езика или платформата, която ползвате.
Извън това – основното правило си остава едно и също. Никога не се доверявайте на данните, които един потребител може да изпрати към сървъра ви. Независимо дали става дума за параметри по заявката, или попълнени форми. Не се опитвайте да използвате blacklist като подход за филтриране на въведеното. Списъкът с ограничения какво е забранено винаги може да позволи нещо, което да не се досетите, но да хрумне на изобретателния хакер. По-скоро използвайте обратния подход – да „пускате“ само информация такава, каквато би трябвало да бъде подадена.
Както и при всички останали теми, свързани със сигурността, на първо място е бдителността. Както може би знаете, на на това направление сме отделили специално място в блога на ZETTAHOST.bg.
До този момент ви разказахме за „човешките“ страни на темата, като представихме опасността от социалното инженерство и работата на „белите хакери“. Разгледахме технологии като нужния на всички ни днес VPN и възхода на направлението IoT – „интернет на нещата“ и рисковете, които идват с тях. Описахме и чисто технологичните страни на най-честите атаки – вече стана дума за DoS и DDoS, преди сега да се спрем на SQL Injection.
Ще се радваме да сме ви полезни и да ви помогнем да останете сигурни в динамичния свят онлайн. Знаем доста за сигурността, а още повече за хостинга, с който се занимаваме вече 17 години. Доверете ни се, започнете напълно безплатно тук!
