Како ИТ тимовите можат да ги заштитат медиумите од SQL напади

09.09.2021. / 09:02

Дигиталните напади се реалност. А таа реалност често се препознава преку нападите на новинарите/ките или активистите/ките. Поради специфичноста на својот професионален и активистички ангажман, влегувајќи во сферите на корупција, различни политички афери, непотизам и неправда, тие дополнително се изложени на потенцијални дигитални, а многу често и на физички, напади.

Сѐ почестите напади на новинарите/ките доаѓаат преку вметнување на кодови. Нападите со вметнување на код се меѓу најстарите и најопасните напади. Често со себе носат кражба и губење на податоците, компромитирање на интегритетот на информациите, ограничување на услугите на интернет, како и целосна контрола на системот. Голем проблем со ваквите напади е фактот дека е тешко да се препознаат, бидејќи корисникот/ката не ја препознава разликата помеѓу поврзувањето на интернет преку регуларна или лажна мрежа.

Најчестите напади со вметнување на код доаѓаат преку SQL injection нападите. SQL injection е напад во кој злонамерниот код се уфрлува во SQL серверот за да изврши определена наредба. Најчестиот резултат на ваквите напади се неавторизирани пристапи до доверливите податоци или уништување на важните податоци.

Веб ранливоста е огромен проблем кој не ги погодува само поединците, туку и големите компании. Земајќи го тоа во предвид, медиумските редакции стануваат многу изложени и прашањето да се има силен ИТ тим, и програмери/ки кои сериозно ќе се занимаваат со креирање на заштита станува круцијално.

Brian Vermeer, застапник за програмери во Snyk наведува некои од важните начини кои програмерите/ките можат да ги следат за да ги спречат SQL нападите. Овие совети највеќе се однесуваат на ИТ тимовите во самите редакции, но многу можат да им ја олеснат секојдневната работа на новинарите/ките, кои со добра почетна заштита полесно можат да се фокусираат на својата работа, а не константно да се грижат за потенцијалните дигитални напади. Се разбира, индивидуалната (дигиталната) заштита и понатаму е важна и секој новинар/ка мора дополнително да обрне внимание на неа.

Пристап со нулта доверба

Тој пред сѐ наведува дека програмерите/ките треба да се обезбедат дека проверката на внесувањето на страната на клиентот/ката не е единствена линија на одбраната. Оваа потврда е извонредна алатка за подобрено корисничко искуство, но не работи како безбедносен механизам. Програмерите/ките сѐ она што ќе испрати клиентот/ката треба да го третираат како потенцијално штетно и затоа треба да бидат валидни на страницата на серверот, идеално што поблиску до изворот.

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

Од друга страна, важно е да се има повеќе од еден корисник/ка на базата на податоци, затоа што создавањето на повеќе корисници/ки на базата на податоци и нивното поврзување со определени улоги на апликацијата го спречува напаѓачот брзо да ја преземе целата база на податоци.

Параметрите се најдобра одбрана

Многу јазици доаѓаат со вградени карактеристики што спречуваат вбризгување на SQL, па при пишувањето на SQL барање може да користите подготвена изјава за составување на параметри.

Подготвените изрази ги ограничуваат SQL изразите кои можат да се внесат: програмерот создава основно барање со резервирани места, а потоа зададените параметри на корисникот можат безбедно да се поврзат со тие резервирани места.

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

Повеќеслојна безбедност и строга проверка

Со параметризацијата и проверката на внесот, програмерите/ките треба да размислат за користење на слојот за објектно – релациско мапирање (ORM) за заштита од вбризгување. Со претворање на базите на податоци во објекти и обратно, се намалуваат експлицитните SQL напади. Сепак, ранливостите потенцијално се присутни и понатаму, ако се користат погрешни или застарени верзии на Sequelize или Hibernate, па затоа програмерите мораат да бидат внимателни.

На крајот, без оглед на тоа какви безбедносни стратегии се користат, важно е да постои строг систем за прегледување на кодовите и препознавање на ранливостите. За највисоките нивоа на безбедност, програмерите/ките треба да побараат специјално дизајнирани алатки за скенирање за автоматски да проверат дали има некаква ранливост од вбризгувањето на SQL и да ги предупредат на сите слабости во кодот.

Ова се многу важни чекори што секој ИТ тим во самите редакции може да ги преземе за заштитниот ѕид од многу сериозни SQL напади да биде што поцврст. Живееме во дигитален свет во кој секојдневно растат дигиталните напади и поради тоа е уште поважно редакциите да ги зајакнат ИТ тимовите, за заштитата на новинарите/ките, изворите на информации, но и на медиумите да биде на што повисоко ниво.

Ocijenite kvalitet članka