ProHoster > Blog > Administrim > Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

Afërsisht një vit më parë, ne në DataLine lansuam shërbimin për kërkimin dhe analizimin e dobësive në aplikacionet IT. Baza e shërbimit është zgjidhja cloud Qualys, për punën e së cilës ne kemi folur. Në vitin e kaluar të punës me zgjidhjen, kemi kryer 291 skanime për faqe të ndryshme dhe kemi grumbulluar statistika mbi dobësitë e zakonshme në aplikacionet web. 

Në artikullin më poshtë do të tregoj se cilat vrima në sigurinë e faqeve fshihen pas niveleve të ndryshme të rrezikshmërisë. Le të shohim cilat dobësi skaneri i gjente veçanërisht shpesh, pse ato mund të ndodhin dhe si të mbrohemi. 

Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

Të gjitha dobësitë e aplikacioneve web Qualys i ndan në tri nivele rrezikshmërie: të ulët, të mesëm dhe të lartë. Nëse shikojmë shpërndarjen sipas "seriozitetit", duket se gjithçka nuk është aq keq. Ka pak dobësi me nivel të lartë rrezikshmërie, kryesisht të gjitha janë jo kritike: 

Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

Por jo kritike – nuk do tĂ« thotĂ« pa rrezik. Ato gjithashtu mund tĂ« shkaktojnĂ« dĂ«me tĂ« rĂ«nda. 

Top "dobësive jo kritike"

  1. Dobësi të lidhura me përmbajtje të përzier.

    Standardi i sigurisë së faqeve është transmetimi i të dhënave midis klientit dhe serverit sipas protokollit HTTPS, i cili mbështet enkripcioni dhe mbron informacionin nga kapja. 

    Disa faqe pĂ«rdorin pĂ«rmbajtje tĂ« pĂ«rzier: transmetojnĂ« njĂ« pjesĂ« tĂ« tĂ« dhĂ«nave pĂ«rmes protokollit tĂ« pasigurt HTTP. Shpesh kĂ«shtu transmetohen pĂ«rmbajtje pasive – informacioni qĂ« ndikon vetĂ«m nĂ« shfaqjen e faqes: imazhe, stilset css. Por ndonjĂ«herĂ« kĂ«shtu transmetohet edhe pĂ«rmbajtje aktive: skriptet qĂ« menaxhojnĂ« sjelljen e faqes. NĂ« kĂ«tĂ« rast, me anĂ« tĂ« njĂ« programi tĂ« veçantĂ« mund tĂ« analizosh informacionin qĂ« vjen nga serveri me pĂ«rmbajtje aktive, tĂ« modifikosh pĂ«rgjigjet nĂ« mĂ«nyrĂ« tĂ« menjĂ«hershme dhe tĂ« bĂ«sh qĂ« makina tĂ« veprojĂ« ndryshe nga sa Ă«shtĂ« menduar nga krijuesit e saj. 

    Shfletuesit e versioneve të reja paralajmërojnë përdoruesit se faqet me përmbajtje të përzier nuk janë të sigurta dhe bllokojnë përmbajtjen. Zhvilluesit e faqeve gjithashtu marrin paralajmërime nga shfletuesi në konsolë. Për shembull, kështu duket në Firefox: 

    Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

    ÇfarĂ« rreziku ka: KibernetikĂ«t pĂ«rdorin protokollin e papĂ«rmirĂ«suar pĂ«r tĂ« kapur informacionin e pĂ«rdoruesve, pĂ«r tĂ« zĂ«vendĂ«suar skriptet dhe pĂ«r tĂ« dĂ«rguar kĂ«rkesa nĂ« faqen e internetit nĂ« emrin e tij. Edhe nĂ«se vizitori i faqes nuk ka futur tĂ« dhĂ«na, kjo nuk e mbron atĂ« nga peshkimi – nxjerrja e informacionit tĂ« ndjeshĂ«m nĂ« mĂ«nyrĂ« mashtruese. PĂ«r shembull, me anĂ« tĂ« njĂ« skripti mund tĂ« ridrejtohet pĂ«rdoruesi nĂ« njĂ« faqe tĂ« pasigurt, e cila maskohet si ajo e njohur pĂ«r pĂ«rdoruesin. NĂ« raste tĂ« caktuara, faqja e keqe duket madje mĂ« mirĂ« se origjinali, dhe pĂ«rdoruesi mund ta plotĂ«sojĂ« formĂ«n dhe t'i dĂ«rgojĂ« tĂ« dhĂ«nat e ndjeshme. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Edhe nĂ«se administratori i faqes ka instaluar dhe konfigurua certifikatĂ«n SSL/TLS, njĂ« dobĂ«si mund tĂ« ndodhĂ« pĂ«r shkak tĂ« faktorĂ«ve njerĂ«zorĂ«. PĂ«r shembull, nĂ«se nĂ« ndonjĂ« nga faqet Ă«shtĂ« vendosur njĂ« lidhje absolute me http, e jo nĂ« mĂ«nyrĂ« relative, dhe pĂ«r mĂ« tepĂ«r nuk janĂ« konfiguruar ridrejtime nga http nĂ« https. 

    Për të zbuluar përmbajtjen e përzier në faqen e internetit, mund të përdorni shfletuesin: kërkoni në kodin burimor të faqes, lexoni njoftimet në konsolën e zhvilluesit. Sidoqoftë, zhvilluesit do t'u kërkohet të kalojnë gjatë në kod. Procesin mund ta përshpejtoni me mjete automatike analize, për shembull: Kontrolli SSL, softueri i lirë Lighthouse ose softueri me pagesë Screaming Frog SEO Spider.

    Gjithashtu, njĂ« dobĂ«si mund tĂ« ndodhĂ« pĂ«r shkak tĂ« problemeve me kodin e vjetĂ«r – kodin qĂ« Ă«shtĂ« trashĂ«guar. PĂ«r shembull, nĂ«se disa faqe gjenerohen sipas njĂ« model tĂ« vjetĂ«r, ku nuk merret parasysh kalimi i faqeve nĂ« https.    

  2. Cookie pa flamujt ‘HTTPOnly’ dhe ‘secure’.

    Atributi ‘HTTPOnly’ mbron skedarĂ«t e cookie nga pĂ«rpunimi nga skriptet qĂ« kibernetikĂ«t i pĂ«rdorin pĂ«r tĂ« vjedhur tĂ« dhĂ«nat e pĂ«rdoruesve. Flamuri ‘secure’ nuk lejon transferimin e cookie-ve nĂ« mĂ«nyrĂ« tĂ« hapur. ShkĂ«mbimi i tĂ« dhĂ«nave do tĂ« lejohet vetĂ«m nĂ«se pĂ«r dĂ«rgimin e cookie-ve pĂ«rdoret protokolli i sigurt HTTPS. 

    Të dy atributet duhet të përshkruhen në pronësitë e cookie-ve:

    Set-Cookie: Secure; HttpOnly

    ÇfarĂ« rreziku ka: NĂ«se zhvilluesi i faqes nuk ka specifikuar kĂ«to atribute, kibernetiku mund tĂ« kapĂ« informacionin e pĂ«rdoruesit nga cookie dhe ta pĂ«rdorĂ« atĂ«. NĂ«se cookie-t pĂ«rdoren pĂ«r autentifikim dhe autorizim, ai do tĂ« jetĂ« nĂ« gjendje tĂ« vjedhĂ« seancĂ«n e pĂ«rdoruesit dhe tĂ« kryejĂ« veprime nĂ« faqen nĂ« emrin e tij. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: NĂ« rregull, nĂ« framework-Ă«t popullorĂ«, kĂ«to atribute vendosen automatikisht. Por tĂ« kontrolloni konfigurimin e serverit web dhe tĂ« vendosni flamurin: Set-Cookie HttpOnly; Secure.

    Në këtë rast, atributi «HTTPOnly» do t'i bëjë cookies të padukshëm dhe për JavaScript-in tuaj.  

  3. Përgjigjet e Dëmtueshme Baze të Rrugës.

    Skeneri raporton për një vulnerabilitet të tillë nëse gjen një skedar ose direktor të aksesueshëm publik të faqes me informacione potencialisht të ndjeshme. Për shembull, zb discoversf ekton skedarë të veçantë me konfigurimin e sistemit ose qasje në sistemin e skedarëve në tërësi. Kjo situatë është e mundur nëse faqa e internetit ka caktuar gabimisht të drejtat e aksesit.

    ÇfarĂ« rreziku ka: NĂ«se sistemi i skedarĂ«ve «vjen jashtë», njĂ« sulmues mund tĂ« depĂ«rtojĂ« nĂ« ndĂ«rfaqen e sistemit operativ dhe tĂ« pĂ«rpiqet tĂ« gjejĂ« dosje me fjalĂ«kalime, nĂ«se ato ruhen nĂ« formĂ« tĂ« hapur (mos e bĂ«ni atĂ«!). Ose mund tĂ« vjedhĂ« hash-et e fjalĂ«kalimeve dhe tĂ« provojnĂ« t'i gjejnĂ« fjalĂ«kalimin pĂ«rmes mbushjes, si dhe tĂ« pĂ«rpiqet tĂ« rrisĂ« privilegjet nĂ« sistem dhe tĂ« avancojĂ« brenda infrastrukturĂ«s.  

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Mos harroni rreth tĂ« drejtave tĂ« aksesit dhe konfiguroni platformĂ«n, serverin web, aplikacionin web, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos mund tĂ« «shkoni» jashtĂ« direktorisĂ« web.

  4. Format për futjen e të dhënave të ndjeshme me funksionin e plotësimit automatik të aktivizuar.

    Nëse përdoruesi shpesh ploteson forma në faqet e internetit, shfletuesi i tij ruan këto informata me anë të funksionit të plotësimit automatik. 

    Format në faqet e internetit mund të përfshijnë fusha me informacione të ndjeshme, për shembull, fjalëkalime ose numra kartelash krediti. Për këto fusha, duhet të çaktivizoni funksionin e plotësimit automatik në vetë faqen. 

    ÇfarĂ« rreziku ka: NĂ«se shfletuesi i pĂ«rdoruesit ruan informata tĂ« ndjeshme, njĂ« sulmues mund ta kapĂ« atĂ« mĂ« vonĂ«, pĂ«r shembull, me anĂ« tĂ« phishing-ut. NĂ« thelb, zhvilluesi web, i cili harroi kĂ«tĂ« nuancĂ«, vĂ« nĂ« rrezik pĂ«rdoruesit e tij. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: NĂ« kĂ«tĂ« rast kemi njĂ« konflikt klasik: komoditeti vs siguria. NĂ«se zhvilluesi web mendon pĂ«r komfortin e pĂ«rdoruesit, ai mund tĂ« zgjedhĂ« me vetĂ«dije plotĂ«simin automatik. PĂ«r shembull, nĂ«se Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« respektohet UdhĂ«zimet pĂ«r Aksesi tĂ« PĂ«rmbajtjes Web – rekomandimet pĂ«r aksesin nĂ« pĂ«rmbajtje pĂ«r pĂ«rdoruesit me aftĂ«si tĂ« kufizuara. 

    Për shumicën e shfletuesve, mund të çaktivizoni plotësimin automatik me atributin autocompete="off", për shembull:

     <body>
    <form action="/sq/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
      <div>
        <input type="text" placeholder="Emri">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Mbiemri" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Numri i kartës së kreditit">
      </div>
      <input type="submit">
    <input type="hidden" name="trp-form-language" value="sq"/></form>
  </body>

    Por për Chrome kjo nuk do të funksionojë. Kjo anashkalohet me anë të JavaScript, një variant i recetës mund të gjendet. këtu. 

  5. Në kodin e faqes së internetit nuk është caktuar titulli X-Frame-Options. 

    Ky titull ndikon në etiketat frame, iframe, embed ose object. Me të mund të ndalohet plotësisht përfshirja e faqes suaj në një frame. Për këtë, duhet të caktohet vlera X-Frame-Options: deny. Ose mund të caktohet X-Frame-Options: sameorigin, atëherë përfshirja në iframe do të jetë e disponueshme vetëm në domenin tuaj.

    ÇfarĂ« rreziku ka: Mungesa e njĂ« titulli tĂ« tillĂ« mund tĂ« pĂ«rdoret nĂ« faqe tĂ« dĂ«mshme pĂ«r clickjacking. PĂ«r njĂ« sulm tĂ« tillĂ«, sulmuesi krijon njĂ« frame transparent mbi butonat dhe e mashtron pĂ«rdoruesin. PĂ«r shembull: mashtruesit vendosin nĂ« frame nĂ« faqen e dĂ«mshme tĂ« rrjeteve sociale. PĂ«rdoruesi mendon se po klikon mbi njĂ« buton nĂ« kĂ«tĂ« faqĂ«. NĂ« vend tĂ« kĂ«saj, kliku mbulon dhe dĂ«rgon njĂ« kĂ«rkesĂ« tĂ« pĂ«rdoruesit nĂ« rrjetin social, ku ka njĂ« sesion aktiv. NĂ« kĂ«tĂ« mĂ«nyrĂ«, sulmuesit shpĂ«rndajnĂ« spam nĂ« emĂ«r tĂ« pĂ«rdoruesit ose rrisin ndjekĂ«sit dhe like-t. 

    Nëse nuk e ndaloni një mundësi të tillë, sulmuesi mund të vendosë butonin e aplikacionit tuaj në një faqe të dëmshme. Ai mund të ketë interes në programin tuaj referral ose te përdoruesit tuaj.  

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: NjĂ« vulnerabilitet mund tĂ« shfaqet nĂ«se X-Frame-Options me njĂ« vlerĂ« konfliktuese Ă«shtĂ« caktuar nĂ« serverin web ose balancuesin e ngarkesĂ«s. NĂ« kĂ«tĂ« rast, serveri dhe balancuesi i ngarkesĂ«s do ta rishkruajnĂ« thjesht titullin, pasi kanĂ« pĂ«rparĂ«si mĂ« tĂ« lartĂ« nĂ« krahasim me kodin e pjesĂ«s sĂ« prapme.  

    Vlerat deny dhe sameorigin të titullit X-Frame-Options do të pengojnë funksionimin e webvizorit të Yandex. Për të lejuar përdorimin e iframe për webvizorin, duhet të shkruani një rregull të veçantë në cilësimet. Për shembull, për nginx mund të konfigurohet kështu:

    http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}

  6. Vulnerabilitetet PRSSI (Importimi i stilit të rrugës relative).  

    Ky është një vulnerabilitet në stilin e faqes. Ai shfaqet nëse për qasjen në skedarët e stilit përdoren lidhje relative si href="/somefolder/styles.css/". Sulmuesi do ta përdorë këtë, nëse gjen një mënyrë për ta kaluar përdoruesin në një faqe të dëmshme. Faqja do t'i japë lidhjes relative në url-in e saj dhe do të imitojë qasjen në stilin. Do të rezultojë një kërkesë si badsite.ru/.../somefolder/styles.css/, e cila nën pretekstin e stilit mund të kryejë veprime të dëmshme. 

    ÇfarĂ« rreziku ka: NjĂ« mashtrues mund tĂ« pĂ«rfitojĂ« nga kjo dobĂ«si nĂ«se gjen njĂ« tjetĂ«r vrimĂ« nĂ« siguri. Si rezultat, kĂ«shtu mund tĂ« vidhen tĂ« dhĂ«nat e pĂ«rdoruesit nga cookies ose tokenĂ«t.

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Shtoni titullin X-Content-Type-Options: nosniff. NĂ« kĂ«tĂ« rast, shfletuesi do tĂ« kontrollojĂ« llojin e pĂ«rmbajtjes pĂ«r stilet. NĂ«se lloji Ă«shtĂ« ndryshe nga text/css, shfletuesi do ta bllokojĂ« kĂ«rkesĂ«n.

Dobësitë kritike

  1. Faqja me fushën për fjalëkalim dërgohet nga serveri përmes një kanali të pa sigurt (HTML form containing password field(s) is served over HTTP).

    Përgjigjja nga serveri për një kanal të pa kriptuar është e prirur ndaj sulmeve të tipit «Man in the middle». Një sulmues mund të kapë trafikun dhe të ndërhyjë ndërmjet klientit dhe serverit, kur faqa shkon nga serveri te klienti. 

    ÇfarĂ« rreziku ka: NjĂ« mashtrues mund tĂ« zĂ«vendĂ«sojĂ« faqen dhe t'i dĂ«rgojĂ« pĂ«rdoruesit njĂ« formĂ« pĂ«r tĂ« dhĂ«nat e ndjeshme, tĂ« cilat do tĂ« shkojnĂ« nĂ« serverin e sulmuesit. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Disa vende nĂ« vend tĂ« fjalĂ«kalimit dĂ«rgojnĂ« pĂ«rdoruesve njĂ« kod tĂ« vetĂ«m pĂ«rmes emailit/telefonit. NĂ« kĂ«tĂ« rast, dobĂ«sia nuk Ă«shtĂ« aq kritike, por mekanizmi do ta komplikohet jetĂ«n pĂ«rdoruesve.

  2. Dërgimi i formularit me emër përdoruesi dhe fjalëkalim përmes një kanali të pa sigurt (Login Form Is Not Submitted Via HTTPS).

    Në këtë rast, nga përdoruesi në server dërgohet një formular me emër përdoruesi dhe fjalëkalim përmes një kanali të pa kriptuar.

    ÇfarĂ« rreziku ka: Ndryshe nga rastin e mĂ«parshĂ«m, kjo Ă«shtĂ« njĂ« dobĂ«si kritike. Kapja e tĂ« dhĂ«nave tĂ« ndjeshme Ă«shtĂ« mĂ« e lehtĂ«, pasi as nuk Ă«shtĂ« nevoja tĂ« shkruani kod pĂ«r tĂ«. 

  3. Përdorimi i librarive JavaScript me dobësi të njohura.

    GjatĂ« skanimit, biblioteka mĂ« e pĂ«rdorur u bĂ« jQuery me njĂ« gamĂ« tĂ« gjerĂ« versionesh. NĂ« secilĂ«n version ka tĂ« paktĂ«n njĂ«, ndonjĂ«herĂ« edhe mĂ« shumĂ« dobĂ«si tĂ« njohura. Ndikimi mund tĂ« jetĂ« nga mĂ« tĂ« ndryshmet – varet nga natyra e dobĂ«sisĂ«.

    ÇfarĂ« rreziku ka: PĂ«r dobĂ«si tĂ« njohura ka eksploite, pĂ«r shembull kĂ«to:

    Gat e vdekjeve për sigurinë e faqes: çfarë kemi mësuar nga statistika e skanuesve të dobësive të vitit

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Kthehuni rregullisht nĂ« cikĂ«l: kĂ«rkimi i dobĂ«sive tĂ« njohura – eliminimi – kontrolli. NĂ«se po pĂ«rdorni libra tĂ« vjetruar me vetĂ«dije, pĂ«r shembull pĂ«r tĂ« mbĂ«shtetur shfletues tĂ« vjetĂ«r ose pĂ«r tĂ« kursyer buxhetin, kĂ«rkoni mundĂ«si pĂ«r tĂ« eliminuar dobĂ«sinĂ« e njohur. 

  4. Scripts ndër-sajtesh (XSS). 
    Cross-Site Scripting (XSS), ose skriptet ndër-site, janë sulme ndaj aplikacioneve në ueb, ku për pasojë shfaqet malware në bazën e të dhënave. Nëse Qualys gjen një dobie, atëherë një sulmues potencial mund të ketë introduktuar ose tashmë ka introduktuar në kodin e faqes së internetit skriptin e tij js për të kryer veprime të dëmshme.

    XSS të Ruajtura (Stored XSS) janë më të rrezikshme, pasi skripti introduktohet në server dhe ekzekutohet çdo herë kur hapet faqja e sulmuar në shfletues.

    XSS të Reflektuar (Reflected XSS) janë më të lehtë për t'u realizuar, pasi skripti keqbërës mund të introduktohet në kërkesën HTTP. Aplikacioni do marrë kërkesën HTTP, nuk do ta kontrollojë të dhënën, do ta paketojë dhe menjëherë do ta dërgojë. Nëse sulmuesi kap trafikun dhe fut skriptin e tipit

    /*+diçka+e+keqe+*/

    atëherë një kërkesë e dëmshme do të dërgohet në emër të klientit.

    Një shembull i dukshëm i XSS: js-sniferët, të cilët imitojnë faqe për futjen e CVC, afatit të skadencës së kartës dhe kështu me radhë. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: NĂ« titullin Content-Security-Policy pĂ«rdorni atributin script-src, pĂ«r tĂ« siguruar qĂ« shfletuesi i klientit tĂ« ngarkojĂ« dhe tĂ« ekzekutojĂ« vetĂ«m kod nga njĂ« burim i besueshĂ«m. PĂ«r shembull, script-src ‘self’ nĂ« listĂ«n e bardhĂ« pĂ«rfshin tĂ« gjithĂ« skriptet vetĂ«m nga faqja jonĂ«. 
    Praktika mĂ« e mirĂ« Ă«shtĂ« tĂ« lejoni vetĂ«m kodin Inline: lejoni vetĂ«m javascript inline me vlerĂ«n unsafe-inline. Kjo vlerĂ« lejon pĂ«rdorimin e js/css inline, por nuk ndalon ngarkimin e skedarĂ«ve js. NĂ« kombinim me script-src ‘self’ ndalojmĂ« ekzekutimin e skenarĂ«ve tĂ« jashtĂ«m.

    Sigurohuni të regjistroni gjithçka duke përdorur report-uri dhe shqyrtoni përpjekjet për introduktim në faqe.

  5. Injeksionet SQL.
    Dobia tregon mundësinë e introduktimit të kodit SQL në faqe, i cili drejtohet direkt në bazën e të dhënave të faqes. Injeksioni SQL është i mundshëm nëse të dhënat nga përdoruesi nuk janë të shenjuara: nuk kontrollohen për korrektësi dhe përdoren menjëherë në kërkesë. Për shembull, kështu ndodh nëse forma në faqe nuk kontrollon përputhshmërinë e hyrjes me tipin e të dhënave. 

    ÇfarĂ« rreziku ka: NĂ«se njĂ« sulmues fut njĂ« kĂ«rkesĂ« SQL nĂ« njĂ« formĂ« tĂ« tillĂ«, ai mund tĂ« shkatĂ«rrojĂ« bazĂ«n e tĂ« dhĂ«nave ose tĂ« nxjerrĂ« informacion tĂ« ndjeshĂ«m. 

    ÇfarĂ« duhet tĂ« mbajĂ« mend zhvilluesi i uebit: Mos i besoni asaj qĂ« vjen nga shfletuesi. Duhet tĂ« mbroheni edhe nĂ« anĂ«n e klientit, edhe nĂ« anĂ«n e serverit. 

    Në anën e klientit, shkruani verifikimin e fushave me ndihmën e JavaScript. 

    Funksionet e ndërtuara në frameworket e njohura gjithashtu ndihmojnë në ekranuar simbolet e dyshimta në server. Në server, është gjithashtu e rekomanduar të përdoren kërkesat e parametrizuara për bazat e të dhënave.

    Përcaktoni saktësisht ku ndodh ndërveprimi me bazën e të dhënave në aplikacionin web. 

    Ndërveprimi ndodh kur ne marrim ndonjë informacion: një kërkesë me id (ndryshimi i id), krijimi i një përdoruesi të ri, një koment i ri, - regjistrime të reja në bazë. Këtu mund të ndodhin sql-injeksione. Edhe nëse fshijmë një regjistrim nga baza, mund të ndodhi sql-injeksioni.

Rekomandime të përgjithshme

Mos shpikni biçikletĂ«n – pĂ«rdorni frameworke tĂ« provuara. NĂ« pĂ«rgjithĂ«si, frameworket e njohura janĂ« mĂ« tĂ« sigurta. PĂ«r .NET – ky Ă«shtĂ« ASP.NET MVC dhe ASP.NET Core, pĂ«r Python – Django ose Flask, pĂ«r Ruby – Ruby on Rails, pĂ«r PHP – Symfony, Laravel, Yii, pĂ«r JavaScript – Node.JS- Express.js, pĂ«r Java – Spring MVC.

Merrni parasysh azhurnimet e ofruesit dhe azhurnoni rregullisht. Do të gjejnë një dobësi, pastaj do të shkruajnë një exploit, do ta publikojnë në akses publik, dhe gjithçka do të përsëritet përsëri. Regjistrohuni për azhurnime deri në versionet stabile nga ofruesi i softuerit.

Kontrolloni të drejtat e aksesit. Nga ana e serverit, gjithmonë trajtoni kodin tuaj sikur të ishte shkruar nga armiku juaj më i urryer, i cili dëshiron të thyejë faqen tuaj dhe të dëmtojë integritetin e të dhënave tuaja. Sidomos, ndonjëherë, kjo vërtet ndodh.

Përdorni klonime, ambiente testimi, dhe pastaj derdhni në prodhim. Kjo do të ndihmojë, së pari, të shmangni gabimet dhe mangësitë në ambientin produktiv: ambienti produktiv sjell para, ndalimi i ambientit produktiv është kritik. Kur shtoni, korrigjoni ose mbyllni ndonjë problem, është e rëndësishme të bëni punët në një mjedis testimi, pastaj të kontrolloni funksionalitetin dhe dobësitë e gjetura, dhe pastaj të planifikoni punët me ambientin produktiv. 

Mbroni aplikacionin web me Web Application Firewall dhe integro shkresa nga skaneri i dobësive. Për shembull, në DataLine si lidhje shërbimesh përdoren Qualys dhe FortiWeb.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster