Sisukord

• Mis on turvatestimine?
• Miks läbi viia turvateste?
• Turvatestimise lähenemisviisid
  • Dynamic Application Security Testing (DAST)
  • Rakenduse staatiline turbetest (SAST)
  • Rakenduse läbitungimistest (APT)
• Enim kasutatud meetodid turvatestimisel
  • 1. Parooli murdmine
  • 2. URL-i manipuleerimine HTTP GET-i kaudu
  • 3. SQL-i süstimine
  • 4. Saidiülene skriptimine (XSS)
• Turvatesti eeldused
• Turvatesti plussid
• Turvatesti miinused
• Näpunäiteid veebirakenduste turvalisuse testimiseks
• Soovitatavad artiklid

Mis on turvatestimine?

Turvalisuse testimine on protsess, mis uurib, kas privaatsed/salastatud andmed jäävad selliseks või mitte, st turvatestist on kasu tagamaks, et veebirakenduse konfidentsiaalne teave jääb avalikustamata isikutele/üksustele, kellel ei ole selle teabe hankimiseks luba.

Veebirakendused võivad olla suhteliselt haavatavamad pahatahtlikule organisatsioonile, mis püüab rikkuda nende turvalisust. Seetõttu tuleb teie veebirakenduse häkkeritest vabaks muutmiseks rakendada lisameetmeid.

Veebiturbelahendused on hõlpsasti kättesaadavad, kuid enamik nõuab märkimisväärseid investeeringuid riist- ja tarkvarasse. Kuid pole midagi, mis võiks olla rohkem väärt kui teie toote ohutus.

Teine turvatesti kasutusviis on tagada, et kasutajad ei saaks veebirakenduse funktsionaalsust tahtmatult muuta jne.

Näiteks kui kasutajad pole selle lisatasu funktsioone tellinud, tuleks nende kasutamine piirata. Turvatestimine tagab, et pole lünki või nippi, mis annaks oma esmaklassilisi funktsioone tasuta ning tagaks selle kasutajaandmete ja muu teabe turvalisuse.

Miks läbi viia turvateste?

Veebirakenduste turvatestide läbiviimise üks kriitilisemaid omadusi oleks võitlus veebirakenduste haavatavusega. Veebirakenduste uurimisel avastatakse desinfitseerimata sisend, mis on haavatav koodi sisestamise rünnakute suhtes. Konkreetne sisend võib rikkuda veebirakenduse turvalisust ja selle rakenduse komponente, nagu kasutajaliides ja andmebaas. Turvatest, mis rakendab töötavale rakendusele selliseid tehnikaid nagu läbitungimistest, on selliste turvaaukude tuvastamise aluseks töötavas rakenduses.

Veebirakenduste turvalisuse parimad tavad on tagada, et rakenduse arendus- ja testimisprotsessi kaasatakse mitu turbekihti. Kaasates kõik kaasa ja veendudes, et nad teavad, mida turvaaukude või muude probleemide ilmnemisel teha, saavad arendajad tugevdada kogu veebirakenduse turbeprotsessi ja säilitada parema arusaamise teie veebirakenduse turbega seotud probleemidest.

Turvatestimise lähenemisviisid

Dynamic Application Security Testing (DAST)

DAST-i metoodika hõlmab veebirakenduse haavatavuste otsimist, mida ründaja võib proovida ära kasutada. See lähenemine aitab leida, milliseid turvaauke ründaja võib sihtida ja kuidas nad võivad väliselt süsteemi ebaseaduslikult siseneda.

DAST-tööriistad ei vaja juurdepääsu rakenduse lähtekoodile; seega DAST on kiire ja sagedane protsess. Erinevalt SAST-i tööriistadest võib DAST-i tööriistu vaadelda kui musta kasti testimismeetodit, mille puhul testijal puuduvad teadmised süsteemisisesest ehitusest. Tester käivitab ja tuvastab kõik tingimused, mis võivad potentsiaalselt viia tööolekus oleva rakenduse turvaauku.

DAST-i tööriistad töötavad operatsioonikoodiga, et tuvastada liideste, päringute, vastuste, skriptimise (st JavaScripti), andmete sisestamise, seansside, autentimise jne probleeme. DAST-i tööriistad kasutavad hägustamist: teadaolevate kehtetute ja ootamatute testjuhtumite viskamine rakendusele, sageli suures mahus.

DAST-i veebirakenduse turvatesti tööriistad:

• GitLab.
• HCL AppScan.
• Acunetixi haavatavuse skanner.
• võrguparkija.
• Appknox.
• CheckMarx.
• Micro Focus Fortify On Demand.
• Veracode'i rakenduste turvaplatvorm.

Rakenduse staatiline turvatest (SAST)

SAST metoodika järgib seest-välja lähenemisviisi; see tähendab, et erinevalt DAST-ist kipub SAST veebirakenduse sisekoodis turvaauke leidma. Kuna see nõuab juurdepääsu rakenduse lähtekoodile, võib SAST pakkuda pilti veebirakenduse turvalisuse reaalajas voost.

SAST-i tööriistu võib pidada valge kasti testimiseks, kuna see nõuab juurdepääsu lähtekoodile. Testija on juba teadlik sisemisest süsteemist või tarkvara testimisel , sealhulgas struktuurskeem, juurdepääs lähtekoodile jne. SAST-i tööriistad uurivad lähtekoodi (puhkeolekus), et tuvastada ja teavitada nõrkusi, mis võivad põhjustada turvaauke.

Lähtekoodianalüsaatorid võivad töötada kompileerimata koodiga, et kontrollida selliseid defekte nagu numbrilised vead, sisendi valideerimine, võistlustingimused, tee läbimised, viited ja viited jms. Binaar- ja baitkoodianalüsaatorid teevad sama ehitatud ja kompileeritud koodiga. Mõned tööriistad töötavad lähtekoodil, mõned ainult kompileeritud koodil ja mõned mõlemal.

SAST-i veebirakenduse turvatestimine:

• SonarQube.
• Veracode'i staatiline analüüs.
• Staatilise koodianalüsaatori tugevdamine.
• Kodeeritus.
• AppScan.
• Checkmarx CxSAST.
• SAST-i jõudlus.
• SAST turvalisus.

Rakenduse läbitungimistest (APT)

Rakenduse läbitungimise testimine võib pidada eetiliseks häkkimiseks, mille eesmärk on näidata rakenduse turvareeglite tõhusust, tuues esile tegelike ärakasutatavate üksuste ohud.

Kuna seda tüüpi testimine nõuab inimfaktorit, proovib valgekraede häkker simuleerida, kuidas ründaja võib veebirakendusse sattuda, kasutades oma isiklikke turvateadmisi ja mitmeid läbitungimise testimise tööriistu, et leida kasutatavaid defekte. Tänapäeval tellivad ettevõtted ja arendajad oma veebirakendusi ka kolmandalt osapoolelt, kui teil pole ettevõttesiseseid ressursse.

Manuaalsete turbetestide esmane eesmärk on tuvastada haavatavused ja potentsiaalsed haavatavused rakenduses, mida ei pruugi automatiseeritud turvatestide abil täielikult mõista või tuvastada.

Automaatsed haavatavuse skannerid ei pruugi olla nii loomingulised kui inimesed, vaid käsitsi läbitungimistestid tuleks alati teha

APT veebirakenduse turvatest:

• netsparker
• Wireshark.
• Metasploit.
• Veiseliha.
• John The Ripper paroolimurdja.
• Õhulõhe.
• Acunetixi skanner.
• Burp Suite'i pliiatsi tester.

Enim kasutatud meetodid turvatestimisel

1. Parooli murdmine

Veebirakenduse turvatesti saab läbi viia Parooli murdmine . Olemasoleva kasutajakonto kaudu rakendusse sisselogimiseks saavad häkkerid kas kasutaja parooli ära arvata või kasutada paroolimurdmise tööriista. Siin tulevad mängu paroolimurdmise tööriistad; seda tüüpi krakkimistööriistad, mis on üldiselt avatud lähtekoodiga, loetlevad tavalised kasutajanimed ja paroolid, mis on automatiseeritud ja mida kasutatakse kõigis loetletud kombinatsioonides.

Paroolimurdmise rünnakute vältimiseks peavad veebirakendused oma kasutajatele jõustama keeruka parooli (mis võib olla numbrite, tähestiku ja kordumatute märkide kombinatsioon); see tagab, et parool on võimatu või võtab selle lahtimurdmine ebasoodsalt aega.

Oletame, et veebisaidi küpsistesse salvestatud kasutajanimi või parool ei krüpteeri korralikult. Sel juhul saab ründaja kasutada küpsiste ja nendega salvestatud andmete, näiteks kasutajanime ja parooli, varandamiseks teistsugust meetodit.

2. URL-i manipuleerimine HTTP GET-i kaudu

Turvatesti ajal peab testija kontrollima, kas rakendus edastab päringustringis olulist teavet või mitte. See eksitus juhtub siis, kui rakendus kasutab HTTP GET disain edastab teavet serveri ja selle kliendi vahel.

Andmed edastatakse päringustringis olevaid parameetreid pidi. Testija saab muuta parameetri väärtust päringustringis, et kontrollida, kas server aktsepteerib seda.

HTTP GET päringu kaudu edastatakse kasutajaandmed autentimiseks ja andmete toomiseks serveri kaudu. Ründaja saab olulise teabe hankimiseks manipuleerida ja muuta sellest GET-i päringust serverile edastatud sisendmuutujat või saidi rikkuda ja krahhi teha. Sellistes tingimustes on rakenduse või veebiserveri ebatavaline käitumine ründaja jaoks ukseava rakendusse pääsemiseks.

3. SQL-i süstimine

SQL-i süstimine teostatakse programmeerimiskeelega SQL (Structured Query Language). SQL-i kasutatakse tagaosas hoitavate andmete haldamiseks. Seetõttu kasutatakse selle rünnaku ajal seda programmeerimiskeele koodi pahatahtliku süstina.

Mõnikord kasutatakse SQL-lausete raamimisel kasutaja sisendeid, mille seejärel andmebaasis olev rakendus käivitab. Oletame, et veebipõhine rakendus ei käsitle SQL õigesti. Sel juhul võib pahatahtlik kasutaja/organisatsioon loetleda rakenduse ootamatud sisestused. Kasutajate halb tegevus võib panna andmebaasi raamima ja täitma SQL-lauseid, st häkker võib andmebaasi muuta . Seda nimetatakse SQL-injektsiooniks; kuigi see ei pruugi nii tunduda, võivad sellise tegevuse tulemused olla murettekitavad.

SQL-i süstimise rünnakud on ohtlikud, kuna ründaja võib serveri andmebaasist olulist teavet vastu võtta ja seda muuta. SQL-i rünnaku sisenemispunktide kontrollimiseks peavad testijad leidma koodi koodibaasist, kust MySQL päringud täidetakse andmebaasis kasutajate sisestusi aktsepteerides. Seetõttu on SQL-i testimine väga oluline, kuna SQL-i rikkumine ei saa lihtsalt varastada ega muuta kasutajaandmeid; see võib õige rakendamise korral muuta ka kogu veebirakenduse koodi.

4. Saidiülene skriptimine (XSS)

Testija peaks lisaks veebirakendust uurima Saididevaheline skriptimine (XSS ). Ideaalis ei tohiks rakendus aktsepteerida ühtegi HTML-i. Kui see nõustub, on rakendus altid saidiülese skriptimise meetodi rünnakule.

Kui veebirakendused saavad kasulikku teavet, edastavad nad selle teabe teatud muutujatena erinevatelt lehtedelt.

Ründaja võib hõlpsasti edastada mõne pahatahtliku sisendi või parameetri '&query', mis võib uurida olulisi kasutaja-/serveriandmeid brauseris.

Turvatesti eeldused

Turvatesti peamine ülesanne on läbi viia veebirakenduse funktsionaalseid teste, võttes arvesse ja leides võimalikult palju turvaprobleeme, mis võivad potentsiaalselt kaasa tuua häkkimise. Turvatesti ohtude ja vigade vältimiseks – veebirakenduse turvatestide tegemiseks on vajalik HTTP-protokolli ja selle kasutamise veebirakendustes hea tundmine. Lisaks veebirakenduste kasulike turbetestide tegemisele peaksid turvatestijad enne veebirakenduste turvaauditi läbiviimist teadma ja tundma ka HTTP-protokolle.

Turvatesti plussid

1. Turvatestimine aitab arendajatel turvaohte tuvastada ja korraldada.
2. Täitke jälgimisvajadused ja hoiduge karistustest.
3. Seda tüüpi rünnakud aitavad võrgu seisakutest mööda minna.
4. Kaitske klientide lojaalsust ja ettevõtte mainet.
5. See võimaldab uurida tegelikke ohte ja omada ettevõtte IT-infrastruktuuri turvapositsiooni igal ajahetkel kohapeal.
6. See võimaldab testijatel süsteemi paremini mõista; see aitab neil süsteemist võimalikult palju teada saada ja võib-olla isegi mõne muu vea või teabega kokku puutuda, mis võib süsteemi häirida.
7. Tänu spetsialistidele, kes mõtlevad ja löövad nii nagu enamik pahatahtlikke häkkereid, annab see võimaluse testida mis tahes süsteemi rünnakutega, mis on võimalikult lähedased reaalsetele juhtumitele.

Turvatesti miinused

1. Protsess on väga kulukas ja mõnikord aeganõudev.
2. On väga kaheldav, kas testija suudab turvaaukude otsimisel või skaneerimisel ning automatiseeritud aruande koostamisel kõik võimalikud probleemid leida ja lahendada. See ei saa kunagi olla täielik turvaaudit.
3. Nõuetekohaselt läbiviidud testid võivad serverites kokku kukkuda, avaldada tundlikke andmeid, rikkuda olulisi andmeid jne.
4. See on töömahukas ja võib seetõttu tähendada suuremaid kulusid ning mõnel organisatsioonil ei pruugi olla võimalik selleks eelarvet määrata. See kehtib eriti siis, kui ülesande täitmiseks palgatakse kolmas osapool.

Näpunäiteid veebirakenduste turvalisuse testimiseks

• Ärikriitilisi süsteeme tuleks sageli testida,
• Hoidke arendusmeeskondi kursis, seades esikohale parandustööd ja veaparandused.
• Seadke lahenduste võrdlemisel esikohale kasutatavus; seal on palju suurepäraseid tööriistu, kuid need võivad olla teie projekti jaoks kasutud, kuna see võib olla teie meeskonna jaoks liiga keeruline või aeganõudev
• Mõistke ja hinnake ettevõtte turvaeesmärke ning seejärel koostage täiuslik tegevuskava.
• Kasutage seda toodet või teenust enne selle lahtimurdmist; mida rohkem teate toote kohta, seda parem.
• Kasutage parimaid vaikeandmeid.
• Valige pilvepõhised lahendused, kui teie organisatsioonil on vähe raha.