Kuidas kirjutada turvalist koodi?

Kaitske end katkise autentimise ja seansihalduse eest!

Kas vajate turvalist koodi?

Olen töötanud turvalise kodeerimise tavade kallal ja üritanud õppida võimalikult palju olulisi punkte. Viimastel aastatel infosüsteemis olemise ajal olen aru saanud, kui palju võib tavalise inimese elus väike haavatavus tekkida. Küberrünnakud, nagu näiteks WannaCry ja Petya lunavara, on paljude selle all kannatanud inimeste meeles üsna värsked.

Siiski suudavad teadlased iga päev veebirakendustes ja muudes domeenides leida üksteise järel väga raskeid vigu. See suundumus ei vähene, kui programmeerijad ei saa kirjutatava koodi teada. Kood ei peaks mitte ainult suutma teostada kavandatud tööd, vaid peaks olema võimeline tõrjuma ka pahatahtliku kasuliku koormuse ja rünnaku stsenaariumid. Parim viis selleks on võimalus luua sünkroniseerimine kodeerimise ja turbekogukonna vahel ning üksteist aidata.

Kaevame sisse!

Niisiis on see konkreetne artikkel „Kuidas turvalist koodi kirjutada?“ Keskendunud probleemile Broken auth ja Session management.

Autentimise ja seansihaldusega seotud rakenduste funktsioone ei rakendata sageli õigesti, võimaldades ründajatel salastada salasõnu, võtmeid, seansilubasid või kasutada muid rakendusvigu, et eeldada teise kasutaja identiteeti.

Selles artiklis tutvun mitut tüüpi rünnakuid ja meetodeid, mida saate nende vastu ennetamiseks kasutada:

1. Kõva kodeerimisega sisselogimismandaadid

Kõva kodeerimisega sisselogimismandaadid on üks kõige uuemaid vigu, mida programmeerija võib teha, kuna see on sama hea kui mandaatide kätteandmine häkkeritele hõbedane vaagen. Tundlikke andmeid ei tohiks kunagi kõvasti kodeerida.

Ebaturvaline kood - kõvakodeeritud kreedid

Küljel olev kood on üks neist näidetest, kus sisselogimise mandaadid on programmeerija kirjutatud koodi kõvasti kodeeritud.

Allpool esitatud kood on näide, kus mandaadid pole programmis kõvakodeeritud, muutes selle eksponentsiaalselt turvalisemaks kui need, kus krediiti on kõvasti kodeeritud.

Turvaline kood - kreedid pole kõvasti kodeeritud

Sellised väikesed erinevused võivad avaldada rakenduse turvalisusele tohutut mõju.

2. Präänikutega manipuleerimine

Präänikutega manipuleerimine on tõusmas kui üks kõige ohtlikumaid rünnakuid, mis tänapäeval läbi viiakse, kuna üha enam autentimisprotsesse viiakse läbi kasutaja esitatud küpsiste üksikasjade kontrollimisega.

Ründajad otsivad võimalusi murda ja mõistavad, kuidas veebirakendused küpsiseid määravad, et nad saaksid nendega manipuleerida ja kujutada endast nagu mõni teine ​​konto ülevõtmist teostav kasutaja.

Lubage mul näidata, kuidas ründaja võib ära kasutada ok nõrgad küpsised, mis on kasutajale määratud, või kui küpsist hoitakse sama.

See küljel olev pilt on sisselogimisportaal, kus kavatseme rünnaku läbi viia ja näidata küpsiste nõrga rakendamise probleeme.

Kui oleme rakendusse sisse loginud, pealtkuulamise Burp-Suite'i liikluses, et seda vaadata ja küpsiseid, mis meile kasutaja autentimiseks üle antakse.

Prääniku üksikasjad

Ülaltoodud pilt kuvab neli parameetrit “Set-Cookie”, mis on määratud siis, kui proovime sisse logida. Need neli erinevat küpsiste sisselogimist, PHPSESSID, näitavad näpunäiteid, kasutajanime ja uid. Arvame, et uid on iga kasutaja jaoks ainulaadne. Nii et lähme edasi ja manipuleerime uidiga, et kontrollida, kas meil on ligipääs kellegi teise kontole.

Küpsise muutmine

Küpsise väärtuse hõivamiseks kasutame brauseris olevat küpsisehalduri küpsisehaldurit ja edastame siis päringu. Muutame oma “uid” 24-lt 12-le, nagu allpool näidatud.

Muudetud küpsis

Niipea kui küpsise väärtust muudame, näeme, et oleme teise kasutaja kontole juurdepääsu saamise korral korraldanud konto ülevõtmise rünnaku.

Selle rünnaku põhjuseks oli asjaolu, et PHPSESSIDi ei muudetud enne ega pärast kasutaja sisselogimist üldse, muutes uid ainsaks otsustavaks teguriks, mis võimaldab tuvastada, milline kasutaja on just oma kontole sisse loginud. Nagu ülal näeme, on konto ülevõtmise hõlpsasti manipuleeritav.

Selleks, et midagi sellist ei juhtuks, peame küpsise pärast sisselogimiskatset uuesti määrama ja peame meeles pidama, et küpsis peab olema ka kordumatu. Siin on idee, kuidas saaksite teha järgmist.

// Väljaanne on sama seansiobjekt, nii et hankige praegune seanss
HttpSession before_login = request.getSession ();
// Kehtetu see seanss
before_login.invalidete ();
// Looge uus seanss, uus JSESSIONID
HttpSession after_login = päring .getSession (true);

Ülaltoodud koodi kasutatakse SESSIONID-küpsise muutmiseks enne ja pärast sisselogimist.

3. Kasutajate loendamine veebiteenuse kaudu

Loendamise probleem on üsna tõsine asi, kuna see võimaldab ründajal välja mõelda rakenduses olevate kasutajate kasutajanimed / e-posti aadressid ja järgnevat detaili saab hiljem kasutada julma jõu rünnakute jaoks.

Me viime selle rünnaku Burp-Suite'i vastu, kasutades Widsleri pikendust ja kasutades selle “getuseri” funktsionaalsust. Proovime siis koguda vastuse süsteemist, kui sisestame kehtiva kasutajanime ja sisestame juhusliku stringi, mis pole kasutajanimi, ja kontrollime siis vastust. Vastavat vastust näeme allolevatel piltidel.

Kasutajat pole olemas

Ülalolev pilt on päring ja vastus, mille saime siis, kui teatud kasutajanimega kasutajat ei eksisteeri. Vastuse kontrollimiseks saatsime päringus kordusreklaami.

Kasutaja on olemas

Ülalolev pilt on päring ja vastus, mille saime tingimuse kohta, kus kasutaja eksisteeris. Saatsime vastuse kontrollimiseks korduspäringus päringu ja saime seekord teistsuguse vastuse. See andis meile idee, et saaksime kasutajaid loendada, tuginedes meile tagasisidele.

Niisiis, edastame taotluse sissetungija vahekaardil ja viime siis läbi julma jõu, et kontrollida mitmesuguseid kasutajaid, kes seda rakendust kasutavad.

Loendatud kasutajanimed

Suurimaks probleemiks on siin see, et arendajad sisestavad vastusepäringusse tegelikult liiga palju üksikasju. Nagu selle rünnaku puhul, näeme selgelt, et vastuses sisalduva liiga palju teabe tõttu võisime välja mõelda, milline vastavate kasutajanimedega kasutajatest oli olemas ja milline mitte. Peame tegema mõne standardiseeritud teate, et ründaja ei saaks lihtsalt aru saada, kasutades mõnda lihtsat loendustehnikat.

4. Julma jõu rünnak

See on järgmine etapprünnak, mis viiakse läbi siis, kui ründaja on eelmise meetodi abil loendanud kasutajad ja nende kasutajanimed.

Kõrval oleval pildil kuvatakse sisselogimisleht, kus oleme juba kasutajad üles loetlenud ja peame nende kasutajate sisselogimismandaatide teadmiseks läbi viima julma jõu rünnaku.

Nii et kui proovime sisse logida, peatame Burp-Suite'i liikluse kinni ja hõivame taotluspaketi ning saadame selle sissetungijale.

Taotle päringut

Nüüd, kui meil on kasutajanimed juba loendatud, viime läbi löögi ja proovime julma jõu rünnakut. Saame Internetist grupi tavalisi paroole ja rünnatakse vastavaid paroole.

Julma jõu rünnak Burp-Suite'i kaudu

Brute Force tüüpi rünnakut ei tohi mingil juhul lubada. Konto blokeerimise funktsioon peaks alati olemas olema, kuna see päästab rakenduse sundimisest ja kasutaja mandaatide väljapeksmisest. Julma jõu vastu saab võidelda ka siis, kui lubada kasutajatel mitte kasutada sõnastiku sõnu, kasutada teatud pikkusega paroole, parem paluda neil kasutada parooli. Enne salvestamist tuleks kasutajate paroolid alati räsitud olla, ka räsiga soola kasutamine on uskumatult oluline.

Moraal

Proovides võidelda katkenud autentimise ja seansihalduse probleemidega, võime järgida järgmisi ettevaatusabinõusid ja hoida neid mõistlikke märkusi.

Katkine autentimine

  • Vigade / eduteadete paljastamine
  • Ärge kunagi kõva koodi mandaate
  • Paroolipoliitika jõustamine (vananemine, tugevus, sooladega segamine)

Seansihaldus

  • Tokenite ettearvamatus (st turvaline juhuslikkus)
  • Aegumispoliitika, sisselogimine / väljalogimine lähtestatakse
  • Tugeva krüptimise kasutamine
  • Kompleksne küpsiste turvalisus

Lugege minu muud artiklit turvalise kodeerimise tava kohta

~ Süstimisrünnakud - https://bit.ly/2OqkRv5
~ Saidideülene skriptimine - https://bit.ly/2TcpU2Y

Kui teile see meeldis, siis plaksutage ja tehkem koostööd. Hankige, määrake, hakige!

Veebisait: aditya12anand.com | Anneta: paypal.me/aditya12anand

Telegramm: https://t.me/aditya12anand

Twitter: twitter.com/aditya12anand

LinkedIn: linkedin.com/in/aditya12anand/

E-post: aditya12anand@protonmail.com

Järgige Infoseci üleskirjutusi, et saada veel selliseid vingeid üleskirjutusi.