Si mund t'i mbrojnë mediat ekipet e IT-së nga sulmet SQL

09.09.2021. / 08:56

Sulmet digjitale janë realitet. E ky realitet shpesh shihet përmes sulmeve ndaj gazetarëve apo aktivistëve.  Për shkak të veçantisë së angazhimit profesional e aktivist, duke u futur në sferat siç është korrupsioni, aferat e ndryshme politike, nepotizmi e padrejtësia, ata i ekspozohen edhe më shumë sulmeve digjitale, e shpesh edhe atyre fizike. 

Sulmet gjithnjë e më të shpeshta ndaj gazetarëve ndodhin përmes injektimit së kodeve. Sulmet përmes injektimit të kodeve janë ndër sulmet më të vjetra dhe më të rrezikshme. Ato me vete shpesh bartin vjedhjen dhe humbjen e të dhënave, komprometimin e integritetit të informatave, mohimin e shërbimeve në internet, si dhe kontrollin e plotë të sistemit. Problemi i madh i sulmeve të këtilla është edhe fakti se ato vështirë dallohen, meqë përdoruesi nuk e sheh dallimin e lidhjes në internet mes rrjetit të zakonshëm dhe atij të rremë.

Sulmet më të shpeshta përmes injektimit të kodit vijnë nga sulmet SQL injection. SQL injection është sulmi ku kodi malicioz injektohet në serverin SQL për të realizuar komandën e caktuar. Rezultati më i shpeshtë i sulmeve të këtilla është qasja e paautorizuar në të dhënat konfidenciale apo zhdukja e të dhënave të rëndësishme.

Cënueshmëria e webit është problem i madh i cili nuk prek vetëm individët por edhe kompanitë e mëdha. Duke u nisur nga kjo, redaksitë e mediave bëhen shumë të ekspozuara dhe çështja e pranisë së një ekipi të fuqishëm të IT-së, gjegjësisht programerëve që do të merren seriozisht me krijimin e mbrojtjes është qenësore.

Brian Vermeer, avokues i zhvillimit në Snyk përmend disa nga mënyrat e rëndësishme që mund t'i ndjekin programerët për të parandaluar sulmet SQL. Këto këshilla më së shumti kanë të bëjnë me ekipet e IT-së brenda redaksive, por edhe mund të lehtësojnë punën e përditshme të gazetarëve që, me një mbrojtje të mirë fillestare, mund të fokusohen më mirë te puna e tyre e jo të brengosen vazhdimisht për sulmet e mundshme digjitale. Natyrisht, mbrojtja individuale (digjitale) vazhdon të jetë e rëndësishme dhe çdo gazetar/e duhet t'i kushtojë vëmendje të shtuar.

Qasja e besimit zero

Ai para së gjithash thotë se programerët duhet të sigurojnë që verifikimi i hyrjeve nga klientët nuk është vija e vetme e mbrojtjes. Ky konfirmim është vegël e shkëlqyer për përvojën më të mirë të përdoruesit, por nuk funksionon si mekanizëm sigurie. Programerët do të duhej të trajtonin gjithçka që dërgon klienti si potencialisht të rrezikshme dhe duhet të jenë në anën e ofruesit, idealisht sa më afër burimit.

Tutje, është e rëndësishme të mendohet për privilegjet e përdoruesve të databazave. Të gjitha sulmet me injektim të SQL-së janë të dëmshme, por disa janë më të dëmshme se të tjerat: qasja në informata të përdoruesve është një gjë, ndryshimi dhe fshirja diçka tjetër. Prandaj, qasja strategjike ndaj privilegjeve të qasjes në databaza është tejet e rëndësishme.

Nga ana tjetër, është e rëndësishme të kemi më shumë se një përdorues të databazave, ngase krijimi i më shumë përdoruesve të databazave dhe lidhja e tyre me rolet e caktuara të aplikacionit pengon sulmuesin të rrëmbejë shpejt databazën.

Parametrat janë mbrojtja më e mirë

Shumë gjuhë vijnë me karakteristika të integruara që parandalojnë injektimin e SQL-së, dhe gjatë shkrimit të pyetjes SQL mund të përdorni deklaratën e përgatitur për vendosjen e parametrave.

Shprehjet e përgatitura kufizojnë shprehjet SQL të cilat mund të futen: programeri krijon pyetjen bazë me vendet e rezervuara, e pastaj parametrat e vendosura nga përdoruesit mund t'i bashkohen në mënyrë të sigurtë atyre vendeve të rezervuara.

Parameterizimi është gjithashtu më i rëndësishmi kur punoni me procedura të ruajtura, sepse edhe procedura e ruajtur mund të jetë cak. Programerët do të duhej të parametrojnë pyetjet në procedurën e tyre të ruajtur, e jo të bashkojnë parametra për t'u mbrojtur nga injektimi. Por, problemi që shfaqet te parametërizimi shpesh janë gjuhët e ndryshme që nuk mbështesin shprehjet e përgatitura apo databazat më të vjetra nuk u lejojnë programuesve të futin inputet e përdoruesit si parametra. Në raste të tilla, alternativa më e mirë është të kontrolloni inputet. Kontrollimi i inputeve duhet të jetë i kujdesshëm dhe të mbështetet në një listë të lejuar, duke përdorur një bibliotekë të mirëmbajtur ose duke krijuar një rregull që përshkruan të gjitha format e lejuara, për shembull, me një shprehje të zakonshme. Natyrisht, edhe nëse deklaratat e përgatitura janë në dispozicion, verifikimi i inputeve është i domosdoshëm.

Siguria shumështresore dhe verifikimi i rreptë

Përveç parametërizimit dhe kontrollimit të inputit, programerët duhet të marrin në konsideratë përdorimin e një shtrese të hartëzimit objekto-relacional (ORM) për t'u mbrojtur kundër injektimit. Duke konvertuar databazat në objekte dhe anasjelltas, sulmet eksplicite SQL zvogëlohen. Megjithatë, rreziku është ende aty nëse përdoren versionet e gabuara ose të vjetruara të Sequelize ose Hibernate, andaj programerët duhet të jenë të kujdesshëm.

Në fund, pavarësisht strategjive të sigurisë që aplikohen, është e rëndësishme të ekzistojë një sistem i rreptë i kontrollit të kodeve dhe njohjes së rrezikut.  Për nivelet më të larta të sigurisë, programerët duhet të kërkojnë mjete skanimi të dizajnuara posaçërisht për të kontrolluar automatikisht rreziqet nga injektimi i SQL-së dhe t'i paralajmërojnë ata për çdo dobësi në kod.

Këto janë hapa shumë të rëndësishëm që çdo ekip i IT-së brenda redaksive mund të ndërmarrë për ta bërë murin mbrojtës kundër sulmeve shumë serioze SQL sa më të fortë. Po jetojmë në një botë digjitale ku sulmet digjitale po rriten çdo ditë dhe kjo është arsyeja pse është edhe më e rëndësishme që redaksitë të forcojnë ekipet e IT-së në mënyrë që mbrojtja e gazetarëve, burimeve të informatave dhe mediave të jetë në nivelin më të lartë të mundshëm.

Ocijenite kvalitet članka