1. Përshëndetje dhe mirësevini në forumin e Itshqip.com
    Nëse akoma nuk jeni pjesë e IT komunitetit më të madhë Shqiptarë nga fusha e Teknologjisë Informative, ju ftojmë që të bëheni pjesë e këtij komuniteti që tani duke u regjistruar këtu - procedura është shumë e thjeshtë dhe e lehtë. Gjithashtu ju mund të regjistroheni edhe përmes rrjetit social Facebook, Twitter, Google+.

[Mësim] SQL Injection - sulmet dhe mbrojtja

Tema tek 'Siguria në Ueb' e hapur nga dr_iton, 11 Shkurt 2014.

  1. dr_iton

    dr_iton MSc. Inxhinier i Softuerit Staff Member IT Staff

    Postimet:
    1,351
    Pëlqimet:
    376
    Pikë nga trofetë:
    228
    Shumë nga ne kemi njohuri me termin se çka është injektimi SQL (ang. Structured Query Language injection – shq. injektimi i gjuhës së strukturuar të pyetësorëve), por krejt çka dimë është nga fakti i dëgjimit apo përvojës së këtij termi nga shembuj të parëndësishëm. Injektimi SQL është njëra nga dobësitë shkatërruese për ta sulmuar një kompani apo biznes, e cila mund të na dërgoj tek ekspozimi i të dhënave të ndjeshme të cilat janë të ruajtura në një bazë të të dhënave të një aplikacioni, përfshirë këtu informatat e dobishme si emrat e përdoruesve, fjalëkalimet, emrat, adresat, numrat e telefonit dhe të dhënat e kartelave kreditore.

    Injektim SQL është një teknikë sulmuese duke shfrytëzuar kodin për të ndryshuar SQL deklarimet e fundme nëpërmjet manipulimit të hyrjeve.

    Injektimi SQL nuk është një dobësi që kryesisht i afekton ueb aplikacionet, çdo kod i cili pranon të dhëna hyrëse nga burime jo të besueshme dhe pastaj i shfrytëzon ato të dhëna për të krijuar SQL formulime dinamike do të mund të ishte dobësi.

    Me fjalë të tjera mund të themi se injektimi SQL është i njohur si një vektor sulmues (malware) për ueb sajtet por mund të shfrytëzohet për të sulmuar çdo lloj të SQL bazave të të dhënave.



    Edhe pse disa prej deklarimeve SQL janë më të mbrojtura ndaj sulmeve SQL, asnjëherë nuk mund të themi se jemi të siguruar 100% kundrejt injektimit SQL, mirëpo mund të themi se çdo i treti ueb sajt që është e lidhur me një bazë të të dhënave ka pika të dobëta (ang. Vulnerable).

    HYRJE

    Po shtjellojmë një temë duke u nisur nga thënia: çka kanë të përbashkët Microsoft, Yahoo, LinkedIn, CIA etj.?

    Të gjitha nga këto organizata të lartpërmendura, ueb faqet e tyre kanë qenë të shkelura me sukses me thyerjen e tyre përmes armës së fortë të hakerëve të quajtur teknika SQL injection.

    Në zhvillimin modern të internetit, këto baza të dhënash shpesh përdoren në back-endin e aplikacioneve dhe në sistemet për menaxhimin e përmbajtjes që do të thotë se përmbajtja dhe sjellja e shumë ueb sajteve është ndërtuar nga të dhënat dhe serveri i bazës së të dhënave. Sulmi i suksesshëm i cili një hakeri i jep mundësin e ndryshimit të përmbajtjes së ueb sajtit që quhet shtrembërim (ang. defacing) me qëllim të marrjes së informacioneve të ndjeshme.



    RREZIKU NGA TË DHËNAT HYRËSE TË PA PASTRUARA

    E thënë gjerësisht, injektimi SQL dërgon komanda keqdashëse (ang. malicious commands) në bazën e të dhënave me qëllim të “nuhatjes” së të dhënave nëpër kanale të paautorizuara.

    Si funksionon kjo?

    Marrim në shqyrtim një ueb formë e cila posedon panelin për kyçje në sistem. Dobësia e ueb formës fillon pasi që nuk janë pastruar të dhënat, hakeri në panelin për kyçje vendosë të dhënat e përdoruesit ‘maketi’ (ang. dummy) (brenda thonjëzave njëshe). Nëse ueb sajti kthen ndonjë gabim SQL, me vetëm vendosjen e emrit të përdoruesit, atëherë hakeri ka gjetur një dobësi, krejt kjo për shkak të kodimit të dobët të sajtit. Ai pasi të ketë qasje në këto të dhëna do të mund edhe të ndryshonte përmbajtjen e tyre.

    Një metodë tjetër shumë e shpeshtë e sulmit është edhe plotësimi i fushës tek kërkohet emri i përdoruesit me urdhrin vijues:

    Code:
    user’ or ‘1’=’1
    kjo verifikon përdoruesit të cilëve iu është ndarë roli, dhe kërkohen përdoruesit të cilin e kanë rolin 1, nëse nuk gjendet asnjë përdorues, atëherë numri 1 pas shenjës së barazimit rritet (ang. increment) për 1 deri sa të arrihet qëllimi.

    ose
    [​IMG]


    Pra, kjo ‘OR 1=1;-- shenjat minus tregojnë se nuk përfillet se çka ka në string pas numrit 1.

    Një ueb sajt i koduar mirë do t’i largonte këto thonjëza njëshe dhe nuk do të pranonte shenja të panevojshme në fushat për futje të të dhënave, p.sh. ndonjë fushë numerike nuk do të dërgonte asnjë simbol tjetër përpos numrave para se të fillonte SQL deklarimi.

    SQL është një gjuhë komplekse dhe nuk është detyrë e lehtë që të krijohen kode dhe të injektohen në query me qëllim të komprometimit të suksesshëm të një baze të dhënash, prandaj edhe përdoren vegla të ndryshme për qëllime sulmimi siç mund të jetë Havij.


    Havij – NUK KËRKOHET NJOHURI PROFESIONALE E SQL-SË

    Havij është një vegël shërbyese e cila përdoret për të bërë sulme të injektimit SQL dhe nuk kërkon njohuri profesionale për SQL deklarime. Pra funksionon si një aplikacion i rëndomtë dhe është krijuar nga grupi “Iranian Security Professionals”. Se si funksionon dhe si duket kjo vegël shihet në figurat vijuese:

    [​IMG]

    [​IMG]

    Hajvij gjithashtu skanon për të gjetur ueb sajtin se me cilin lloj të SQL-së është e krijuar baza e të dhënave. Duke përdorur këtë karakteristikë pastaj krijon query të ndryshëm që do të mund të krijoheshin vetëm nga ekspertët, të cilat tani do të parashtroheshin nga çdo haker fillestar të ashtuquajtur “n00b” i cili është i motivuar për të provuar sulmin me qëllim përpjekjeje të karakteristikave të bazës. Duhet cekur se Havij, nuk është i suksesshëm tek faqet të cilat janë siguruar mirë kundrejt injektimit SQL.


    MBROJTJA KUNDREJT SULMEVE ME INJEKTIM SQL

    Lajmi i mirë është se shumica e poseduesve të ueb sajteve kanë njohuri se si të mbrohen kundrejt sulmeve me injektim SQL. Mirëpo, në sigurinë e rrjetave, asnjëherë nuk ekziston termi i mbrojtjes 100% kundrejt këtyre sulmeve.

    Ekzistojnë disa mjeshtri mbrojtëse, mirëpo ne po përmendim katër nga më të rëndësishmet:

    · Pastrimi i përgjithshëm i të dhënave,

    · Përdorimi i firewall-it të ueb aplikacionit,

    · Limitimi i privilegjeve të bazës së të dhënave për nga konteksti

    · Shmangia e krijimit të SQL query-ve nga ana e shfrytëzuesit.

    - Pastrimi i përgjithshëm i të dhënaveueb sajtet duhet që të filtrojnë të gjitha të dhënat hyrëse që vendosë shfrytëzuesi për nga konteksti. P.sh. të dhënat hyrëse për numra nuk duhet të pranojnë edhe karaktere tjera përpos numrave, e-mail nuk duhet të pranoj karaktere tjera përpos ato që parashihen t’i ketë një e-mail duke përdorur edhe regular expression për t’u plotësuar në formatin e duhur e pse jo edhe limitimi i numrit të karaktereve brenda një fushe të caktuar.

    - Përdorimi i firewall-it të ueb aplikacionit – shembulli më i popullarizuar është moduli pa pagesë i ModSecurity , tani gjendet versioni ModSecurity 2.7.7 dhe mund të shkarkohet nga lidhja vijuese:
    Code:
    http://www.modsecurity.org/download/
    dhe pasi që këtu mësohet kryesisht për SQL Server, në lidhjen vijuese gjendet edhe dokumentimi se si instalohet firewall në një Microsoft IIS Server.
    Code:
     https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Installation_for_Microsoft_IIS
    Firewall do të duhej deklaruar si në vijim:

    Code:
    <@modules>
      <remove name="ModSecurityIIS" />
    </modules>

    Gjithashtu edhe fajllit web.config do të duhej t’i shtohet edhe pjesa vijuese e kodit:

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
      <system.webServer>
      <ModSecurity enabled="true" configFile="c:\inetpub\wwwroot\xss.conf" />
      </system.webserver>
    </configuration>
    - Limitimi i privilegjeve të bazës së të dhënave për nga konteksti – krijimi i shumëllojshmërisë së përdoruesve të bazës së të dhënave me privilegje minimale të përdorimit të hapësirës, p.sh. kodi pas panelit për kyçje do të duhej ta dërgonte përdoruesin vetëm tek faqet ku ai ka të drejta për lexim/shkrim të të dhënave kështu që ai nuk do të kishte mundësi që të komprometonte bazën e të dhënave, ose thënë thjesht çdo përdorues duhet validuar me drejta të caktuara.

    - Shmangia e krijimit të SQL query-ve nga ana e shfrytëzuesit – edhe nëse pastrimi i të dhënave do të mund të ishte me të meta, përgatitja e SQL lidhjeve përmes deklarimeve variabile Stored Procedures dhe Transactions është shumë më e sigurtë sesa deklarimi i query-ve të plotë.


    Aplikimi i secilës nga këto katër teknikave mbrojtëse të sipërpërmendura do të ishte një reduktim i konsiderueshëm i mundësisë së të qenit të injektuar me SQL. Aplikimi i të gjitha këtyre teknikave së bashku do të ofronte një shkallë shumë të lartë sigurie. Prandaj, përdorimi i gjerë i ueb sajtit tuaj, nuk do të duhej të ishte viktima e ardhme e një injektimi SQL.


    Njëra prej skripteve që mund të përdoret për t’u mbrojtur nga injektimi SQL në C#.NET përmes deklarimeve të parapërgatitura është edhe kjo në vijim:

    Code:
    String query =
      "SELECT bilanci_llogaria FROM perdoruesi WHERE emri_perdoruesit = ?";
    try {
      OleDbCommand cmd = new OleDbCommand(query, conn);
      cmd.Parameters.Add(new OleDbParameter("emriKonsumatorit", EmriKonsumatorit Emri.Text));
      OleDbDataReader reader = cmd.ExecuteReader();
      // …
    } catch (OleDbException se) {
      // Trajtimi i gabimit
    } 

    Pas një hulumtimi për qëllime edukimi, mendoj se njerëzit hezitojnë të flasin për tema të tilla, sepse një teknikë siç është SQL injection është teknikë keqdashëse dhe njerëzit paragjykojnë se hulumtime të tilla bëhen për qëllime keqdashëse dhe jo edukuese.

    Përshëndetje.
     
    Last edited: 11 Shkurt 2014
    Blerim R., WhiteLine, boom3rang dhe 5 anëtarë tjerë pëlqejnë postimin.
  2. networkcoder

    networkcoder Anëtar i Njohur

    Postimet:
    561
    Pëlqimet:
    132
    Pikë nga trofetë:
    63
    Me te vertet tutorial i mire , i ke spjeguar bukur dhe thjesht

    e kam nje pyetje :
    Ky SQL injektimi a perdoret kur deshiron te qasesh p.sh ne panelin e kontrollit cPanel : emriifaqes:2086 ose emriifaqes:cpanel ?

    Met mira
     
  3. MarioH

    MarioH Anëtar

    Postimet:
    33
    Pëlqimet:
    2
    Pikë nga trofetë:
    8
    Më pëlqeu vërtet tutoriali ! Punë mjaft e mirë !

    Nëse e ke fjalën për pjesën e
    Code:
    'or' 1=1
    , atëherë jo, sepse cPanel është nje sistem menaxhimi ndër më të sigurtët.
    Ajo shërben për depërtimin nëpër faqe të koduara mjaft dobët.
     
  4. FIAT

    FIAT Anëtar Aktiv

    Postimet:
    156
    Pëlqimet:
    7
    Pikë nga trofetë:
    18
    jane fshire foto , uploado perseri...!
     
  5. Shpend Kastrati

    Shpend Kastrati Anëtar

    Postimet:
    2
    Pëlqimet:
    0
    Pikë nga trofetë:
    1
    Pershendetje i nderuar @dr_iton um pelqyn pamase te gjitha qe i ke paraqite, edhe une kam ber nje punim per SQL Injection (mbrojtja dhe validimi i web kontrollave nga Sql Injection), por me natyre pak tjeter mirpo menyra se si ke paraqitur ti met vertet um ka pelqyer, pune te mbare.
     
  6. Eduart96

    Eduart96 Anëtar

    Postimet:
    6
    Pëlqimet:
    0
    Pikë nga trofetë:
    1
    Do te preferoja dhe rekomandoja Havij m teper pasi esht teper i thjesht per tu perdorur nga te gjithe!
    Faleminderit per tutorialin :)
     
  7. dr_iton

    dr_iton MSc. Inxhinier i Softuerit Staff Member IT Staff

    Postimet:
    1,351
    Pëlqimet:
    376
    Pikë nga trofetë:
    228
    Unë as nuk do ti preferoja skujt dhe as do ti sugjeroja anjë nga veglat që përdoren për Injektim SQL sepse qëllimi i tyre është për ti bërë keq dikujt. Krejt çda do ju sugjeroja do ishte fakti i mënyrës dhe teknikave mbrojtëse kundrejt SQL Injektimeve.

    Përshëndetje.
     
  8. Eduart96

    Eduart96 Anëtar

    Postimet:
    6
    Pëlqimet:
    0
    Pikë nga trofetë:
    1
    Përderisa ju keni bër një tutorial në lidhje me sulmet e SQL Injection thjesht dhash një mendim që Havij është i thjesht për tu përdorur nga të gjithë.
     
  9. Bahtir

    Bahtir Anëtar

    Postimet:
    15
    Pëlqimet:
    0
    Pikë nga trofetë:
    3
    Disa webfaqe e kan mod security te instaluar qe nese tenton me injektu ateher te del kodi 406 not acceptable.Por edhe kjo siguri ka arritur te thyhet nga hackeret prandaj eshte me mire qe mos te bejme gabime gjat programimit dhe ta lejme ndonje vrim te hapur e te na dalin errorat si "mysql_num_rows()" ,mysql_fetch_array() , error in your SQL syntax.E di se problemin me Sql Injection e kan edhe wordpress edhe joomla po duhet me bo qmos qe me evitu ket problem.Sa i perket siguris prej SQL Injection kjo modsecurity moti osht e thyme veq jo me havij po ka programe tjera te shkruara ne python siq eshte psh sqlmap i cili osht shume me i fort se Havij.Komandat per thyerjen e kesaj sigurie:

    sqlmap.py -u http://www.expample.com/news.php?id=341 --dbs --tamper modsecurityzeroversioned.py,space2hash.py
     
  10. dr_iton

    dr_iton MSc. Inxhinier i Softuerit Staff Member IT Staff

    Postimet:
    1,351
    Pëlqimet:
    376
    Pikë nga trofetë:
    228
    Asnjëherë i nderuar @Bahtir nuk guxojmë që të themi se jemi i sigurtë 100%, mirëpo siç e ceke edhe vetë duhet marrë disa masa sigurie që edhe në qoftë se tenton t'i marri pala e tretë të dhënat, të mos ketë mundësi së paku që t'i deshifroj ato të dhëna. P.sh. njb masë mbrojtëse do të ishte edhe ndonjë HASH funksion që aty gjinden 6 hapa për të qenë një HASH funksion i sigurtë.
    Kur themi se është një HASH funksion i sigurtë?
    Atëherë kur koha e deshifrimit është më e gjatë se kohëzgjatja ose koha valide (ang. Duration) e mesazhit.
    Thjeshtë mund të themi se duhet të kemi njohuri edhe me termet vijuese:
    Kriptografia + Kriptoanaliza = Kriptologjia
    (kriptografia) = 1/(kriptoanaliza)

    P.S. Kjo temë kryesisht ka të bëjeë me këto dy termet e fundit që konkretisht një sulëm SQL injection ka për qëllim kriptoanalizën.
    Pershendetje.
     
    WhiteLine pëlqen postimin.
  11. Bahtir

    Bahtir Anëtar

    Postimet:
    15
    Pëlqimet:
    0
    Pikë nga trofetë:
    3
    Po eshte edhe kjo nje mase mbrojtse si e ka pershembull wordpress edhe joomla qe kane hashat shum te fort qe nuk mund te dekryptohen po kjo automatikisht nuk i bon ata te sigurt sepse edhe kjo gje mund te behet bypass shum leht.Nese ne e kemi databazen e te dhenave psh per wordpress ne e din qe nuk mundemi ta dekryptojme passwordin por kemi mundesi qe ta nderojme ate password.Si behet ndrimi i passwordit ne wordpress nese kemi acces ne databazen e te dhenave:

    1.Shkojm te wp_users
    2.I marem te dhenat rreth emailit te adminit
    3.Shkojme ne /wp-login.php dhe klikojme se e kemi harruar fjalkalimin
    4.Faqja ne vazhdim na kerkon emailin e adminit, dhe ne tash e kemi ate.
    5.Pas ksaj procedure ne email dergohet nje kod aktivizimi
    6.Ne databazen e te dhenave gjendet ky kod aktivizimi
    7.I shtojme ket link faqes wordpress /wp-login.php?action=rp&key={ketu kodi i aktizimit }&login={emri i perdoruesit}
    8.Nese i kemi percjell procedurat si duhet atehere nese klikojme enter , kalojme ne faqen per venien e nje passwordi te ri.
    9.Edhe kshtu automatikisht ne e kemi nderu passwordin e adminit dhe kemi qasje ne Admin Panel edhe pse passwordi ka qen mire i kriptuar.
     
  12. dr_iton

    dr_iton MSc. Inxhinier i Softuerit Staff Member IT Staff

    Postimet:
    1,351
    Pëlqimet:
    376
    Pikë nga trofetë:
    228
    Po krejt procedura e ruajtjes nga nje SQL injection eshte qe mos te kene mundesi pala e tretë qe t'i marr te dhenat e adminit.
    Pse kjo?
    Dihet se te dhenat e ndjeshme te nje web site-i i ka admini dhe po i more te dhenat e tij atehere behesh edhe pronar i atij sajti apo me mire te them web aplikacioni.
    Ne baze te asaj çka kam lexuar kam kuptuar qe te gjithe sulmuesit deshirojne te marrin te dhenat e userit me rankun admin.

    Pershendetje.
     
  13. boom3rang

    boom3rang Ninja Staff Member Administrator

    Postimet:
    4,481
    Pëlqimet:
    2,073
    Pikë nga trofetë:
    448
    Nuk pajtohem me kete fjalin e fundit, nuk eshte e vertet qe te gjith sulmuesit deshirojne te marrin te dhenat e adminit, sepse ka edhe prej atyre qe me shum ju kryejn pune te dhenat e perdoruesve se sa te adminit. Gjithmon varet se cfar faqe sulmon. Po marim nje shembull.

    Forumi itshqip eshte komunitet i madh, dhe ne bazen e te dhenave te ketij forumi ka edhe kredit karta te anetareve ketu, ku jane kryer pagesa te shumta per sherbime te ndryshme, dhe kete fakt sulmuesi e din, dhe eshte normale qe ai te sulmoje per kete qellim, pra ne kete rast viktima jane anetaret e ktij forumit, ne rast te thyerjes se sigurise, atij nuk i nevojiten aspak te dhenat e adminit ne kete rast te dhenat e mia.

    Pra gjithmon varet nga ajo cfar faqe ka si cak sulmuesi dhe ne kete drejtim targetohen viktimat.

    Zakonisht te dhenat e adminit kerkohen nga ato qe jane te interesuar per ndonje deface, apo ndonje faqe ne te cilen ska baze te dhenave me perdorues te shumt. Dhe zgjidhja e ketij problemi gjithmon qendron ne ate te sigurimit te faqes se administrimin me ndonje shtojce, ose .htaccess.
     
    Last edited: 10 Nëntor 2014
    WhiteLine, z3r0 dhe Fannol Gashi pëlqejnë postimin.

Shpërndaje faqen

Loading...