Saugumo kontrolinis sąrašas DI sukurtoms programoms: ką patikrinti prieš paleidimą

Prieš tai, kai žmonės pradeda naudoti jūsų DI sukurtą programą, patikrinkite septynis dalykus: kiekvienas puslapis ir API tikrina, kas yra naudotojas ir ką jis gali daryti; slaptieji raktai laikomi serveryje, o ne naršyklėje ar pokalbyje; visa įvestis tikrinama serveryje; kiekvienas naudotojas gali pasiekti tik savo įrašus; prisijungimas ir brangūs galutiniai taškai turi ribojimus; priklausomybės atnaujintos; o jūs galite atkurti duomenis, jei kažkas nutinka. Toliau kiekvienas punktas paverčiamas konkrečiais testais, kuriuos galite atlikti neskaitydami kodo.

DI kūrimo įrankiai gerai padaro, kad funkcijos veiktų. Jie nėra automatiškai atsargūs, nes „atsargumas“ retai įrašomas užklausoje. Daugelis toliau aprašytų problemų kyla iš dalykų, kurių niekas neprašė, todėl pataisymas dažniausiai – tiesiog paprašyti.

Kaip naudoti šį kontrolinį sąrašą

Eikite per jį iš eilės ir kiekvienam punktui padarykite du dalykus: paprašykite DI įsitikinti, kad tai padaryta, ir patikrinkite patys. DI gali parašyti leidimų patikrinimą; tik testas parodo, kad jis veikia. Punktai pažymėti taip:

• Privaloma – padaryti prieš tai, kai programą naudoja kiti žmonės.
• Rekomenduojama – padaryti prieš turint tikrų naudotojų ar tikrų duomenų.
• Vėliau – verta padaryti augant programai.

Jei turite tik valandą, atlikite visus Privalomus punktus.

1. Autentifikavimas: kas tai?

Autentifikavimas – tai patvirtinti, kas yra asmuo, paprastai per prisijungimą. Pagrindus žr. kas yra autentifikavimas, o variantus – kaip pridėti prisijungimą prie programos.

• Privaloma: Kiekvienas puslapis, rodantis privačius duomenis, reikalauja prisijungimo. Testas: atsijunkite, tada įklijuokite privataus puslapio URL tiesiai į naršyklę.
• Privaloma: Kiekvienas API galutinis taškas, esantis už tų puslapių, taip pat reikalauja prisijungimo – ne tik puslapis. Testas: atsijunkite, atidarykite naršyklės tinklo skirtuką ir pakartokite užklausą, kurią programa siuntė, kol buvote prisijungę.
• Privaloma: Slaptažodžiai saugomi užšifruoti lėtu slaptažodžių maišos algoritmu, niekada paprastu tekstu. OWASP slaptažodžių saugojimo rekomendacijos pirmiausia nurodo Argon2id, o alternatyvos – scrypt, bcrypt ar PBKDF2. Klauskite: „Kaip saugomi slaptažodžiai?“
• Rekomenduojama: Slaptažodžio atstatymo nuorodos baigiasi galiojimu ir veikia tik vieną kartą.
• Rekomenduojama: Sesijos slapukai pažymėti Secure, HttpOnly ir SameSite, o atsijungus sesija nutraukiama serveryje.
• Vėliau: Pasiūlykite dviejų faktorių autentifikavimą arba prisijungimą per teikėją, kuris jį turi.

Patikrinkite kiekvieną API maršrutą ir puslapį, grąžinantį naudotojo duomenis. Kiekvienas jų turi atmesti užklausas iš naudotojų, kurie neprisijungę, serveryje, o ne vien puslapio kode. Išvardykite maršrutus, kuriuos patikrinote.

2. Autorizacija: ką jie gali daryti?

Autorizacija – tai žingsnis po prisijungimo: nuspręsti, ką šis konkretus naudotojas gali matyti ir keisti. Čia DI sukurtos programos dažniausiai turi rimtų spragų, nes programa atrodo teisingai – kiekvieno naudotojo skydelis rodo tik jo paties duomenis – o serveris tyliai atiduos bet kieno duomenis, jei juos tiesiogiai paprašys.

• Privaloma: Kiekvienas skaitymo, atnaujinimo ir trynimo veiksmas serveryje patikrina, ar įrašas priklauso dabartiniam naudotojui (ar jo komandai).
• Privaloma: Testas: sukurkite dvi paskyras, A ir B. Prisijungę kaip A, atidarykite vieną iš A įrašų ir užsirašykite ID iš URL ar tinklo užklausos. Prisijunkite kaip B ir paprašykite to paties ID. B turi gauti klaidą, o ne A duomenis.
• Privaloma: Administratoriaus puslapiai ir administratoriaus API galutiniai taškai serveryje tikrina naudotojo vaidmenį. Administratoriaus nuorodos paslėpimas nėra apsauga.
• Privaloma: Naudotojai negali pakeisti savo vaidmens, kainos, balanso ar savininko laukų redaguodami užklausą. Testas: tinklo skirtuke pažiūrėkite, ką siunčia profilio atnaujinimas. Jei jame yra laukai, pavyzdžiui, role ar isAdmin, paprašykite DI, kad jie būtų ignoruojami iš kliento pusės.
• Rekomenduojama: Ką nors URL adresuose sunku atspėti (atsitiktiniai ID, o ne 1, 2, 3). Tai nepakeičia leidimų patikrinimų, bet apriboja žalą, jei kažkuris trūksta.

Kiekvienam galutiniam taškui, kuris skaito ar keičia įrašą, patikrinkite serveryje, ar prisijungęs naudotojas jį valdo arba gali juo naudotis. Jei ne – grąžinkite 404. Tada parodykite, kaip tai patikrintumėte su dviem paskyromis.

3. Eilučių lygio prieiga duomenų bazėje

„Eilučių lygio prieiga“ reiškia, kad kiekviena lentelės eilutė (viena rezervacija, viena sąskaita) matoma tik tiems naudotojams, kuriems ji priklauso. Yra du dažni būdai tai užtikrinti:

Abu būdai gali būti atlikti gerai. Svarbiausia:

• Privaloma: Jei naršyklė bendrauja su duomenų baze tiesiogiai (kai kurie valdomi duomenų bazių produktai tai leidžia), eilučių lygio taisyklės įjungtos kiekvienai lentelei. Be jų bet kas su viešuoju raktu gali perskaityti visą lentelę.
• Privaloma: Užklausos filtruojamos pagal dabartinį naudotoją ar komandą, o ne pagal ID, kurį siunčia naršyklė.
• Rekomenduojama: Bendriems duomenims (komandos projektams) yra aiški taisyklė, kas yra komandoje, ir ji užtikrinama vienoje vietoje.

4. Slaptieji raktai ir API raktai

API raktas – tai paslauga pasiekiantis slaptažodis. Stripe, el. pašto ir DI teikėjai visi naudoja tokius raktus. Bendrai žr. kas yra aplinkos kintamieji ir paslaptys.

• Privaloma: Raktai laikomi projekto aplinkos kintamuosiuose ar paslaptyse, niekada neįrašyti į kodą.
• Privaloma: Raktai, kurie gali išleisti pinigus ar nuskaityti privačius duomenis, naudojami tik serveryje. Testas: atidarykite gyvą svetainę, pažiūrėkite puslapio šaltinį ir JavaScript failus kūrėjo įrankiuose, ir ieškokite savo rakto pradžios (pavyzdžiui, sk_). Jos neturi būti.
• Privaloma: Raktai niekada nebuvo įklijuoti į pokalbį, viešą saugyklą ar ekrano nuotrauką. Jei taip nutiko, pakeiskite jį teikėjo sistemoje (sukurkite naują ir ištrinkite seną).
• Rekomenduojama: Naudokite apribotus ar ribotos apimties raktus ten, kur teikėjas siūlo. Pavyzdžiui, Stripe rekomenduoja apribotus raktus, turinčius tik jūsų integracijai reikalingus leidimus.
• Rekomenduojama: Testiniai ir gyvi raktai atskirti, o gyvoji programa naudoja gyvus raktus tik tada, kai esate pasirengę.

Kai kurie raktai skirti būti vieši – pavyzdžiui, Stripe paskelbiamasis raktas (pk_…) ar žemėlapių raktas, apribotas jūsų domenu. Taisyklė susijusi su raktais, suteikiančiais galią, o ne su kiekviena eilute, panašia į raktą.

5. Įvesties tikrinimas

Bet ką, ką naudotojas siunčia – formos laukus, failų įkėlimus, URL parametrus – gali būti bet kas, ne tik tai, ką leidžia jūsų forma.

• Privaloma: Tikrinimas vyksta serveryje, o ne vien naršyklėje. Naršyklės patikros skirtos patogumui; kiekvienas gali jas praleisti.
• Privaloma: Duomenų bazės užklausos naudoja parametrus, o ne tekstą, sulipdytą iš naudotojo įvesties (taip užkertamas kelias SQL injekcijai). Paprašykite DI tai patvirtinti.
• Privaloma: Naudotojų įvestas tekstas rodomas kaip tekstas, o ne vykdomas kaip HTML. Testas: įveskite <b>labas</b> kaip savo vardą. Turėtumėte matyti žymes, o ne paryškintą tekstą.
• Rekomenduojama: Failų įkėlimai tikrina tipą ir dydį, o įkelti failai nėra teikiami iš pagrindinio programos domeno kaip vykdomi puslapiai.
• Rekomenduojama: Klaidos, rodomos naudotojams, yra paprastos („Įvyko klaida“); išsamios klaidos eina tik į serverio žurnalus.
• Rekomenduojama: Webhook'ai iš tokių paslaugų kaip Stripe patikrina teikėjo parašą prieš veikdami. Žr. kas yra webhook.

Pridėkite serverio pusės tikrinimą prie kiekvienos formos ir API galutinio taško: privalomi laukai, ilgiai, formatai ir leidžiamos reikšmės. Atmeskite viską kita aiškiu pranešimu. Nerodykite vidinių klaidų detalių naudotojams.

6. Ribojimai ir piktnaudžiavimas

Ribojimas nustato, kiek užklausų kas nors gali pateikti per tam tikrą laiką. Be jų kas nors gali visą dieną spėti slaptažodžius, užtvindyti registracijos formą ar padidinti jūsų sąskaitą mokamame API.

• Privaloma: Prisijungimas, registracija ir slaptažodžio atstatymas ribojami pagal IP adresą ir pagal paskyrą.
• Privaloma: Viskas, kas kainuoja pinigus už kiekvieną iškvietimą – DI modelio užklausos, SMS, el. laiškai – turi naudotojo ribą ir reikalauja prisijungimo.
• Rekomenduojama: Viešos formos (kontaktų, laukimo sąrašo) turi apsaugą nuo šlamšto: užklausų ribą, paslėptą „medaus pūrelio“ lauką ar CAPTCHA.
• Rekomenduojama: Nustatykite išlaidų limitus ar įspėjimus mokamuose teikėjuose, kad klaida ar įsilaužėlis nesukurtų neribotos sąskaitos.

7. Priklausomybės

Programos sukurtos iš atvirojo kodo paketų, o paketai kartais turi žinomų pažeidžiamumų.

• Rekomenduojama: Paprašykite DI patikrinti žinomus pažeidžiamumus (JavaScript projektams – npm audit ar atitikmuo jūsų paketų tvarkyklei) ir atnaujinti paveiktus paketus.
• Rekomenduojama: Pašalinkite paketus, kurių programa nebenaudoja.
• Rekomenduojama: Būkite atsargūs su paketais, kuriuos naudoja labai mažai žmonių, ar pavadinimais, kurie primena populiarių paketų rašybos klaidas.
• Vėliau: Tikrinkite kas mėnesį ar porą, arba įjunkite automatinius pranešimus, jei jūsų kodas yra GitHub.

8. Atsarginės kopijos ir atkūrimas

Saugumas apima galimybę atsigauti po klaidų – jūsų, DI ar įsilaužėlio.

• Privaloma: Žinokite, kur yra jūsų duomenys ir ar jie kuriami atsarginės kopijos. Nedarykite prielaidų; patikrinkite savo hostingo dokumentaciją.
• Rekomenduojama: Turėkite savo periodinį svarbių duomenų eksportą (pavyzdžiui, CSV eksporto funkciją ar duomenų bazės kopiją), laikomą atskirai.
• Rekomenduojama: Laikykite kodą versijų valdymo sistemoje, kad bet kurią versiją būtų galima atkurti.
• Rekomenduojama: Destruktyviems veiksmams (paskyros trynimas, projekto trynimas) reikalingas patvirtinimas, o galima apsvarstyti „minkštąjį trynimą“, kurį galima atšaukti tam tikrą laiką.
• Vėliau: Kartą iš tikrųjų išbandykite atkūrimą. Atsarginė kopija, kurios niekada neatkūrėte, yra viltis, o ne planas.

9. Prieš paleidimą

• Privaloma: Gyvoji svetainė visur naudoja HTTPS.
• Privaloma: Bandomieji duomenys, testinės paskyros ir derinimo puslapiai iš kūrimo etapo pašalinti.
• Rekomenduojama: Privatumo politikoje nurodyta, kokius duomenis renkate ir kodėl – daugelyje vietų tai privaloma, jei renkate asmeninius duomenis. Nesiskelbkite sertifikatais (SOC 2, HIPAA), kurių neturite.
• Rekomenduojama: Turite būdą, kaip su jumis susisiekti dėl saugumo problemų, ir žinote, kaip greitai pakeisti kiekvieną raktą.

Platesnei prieš paleidimą atliekamai patikrai, neapsiribojant saugumu, žr. kaip perkelti DI prototipą į gamybą.

Kada reikia profesionalo peržiūros

Kontrolinis sąrašas pagauna dažnas klaidas, bet nepakeičia ekspertų. Verta apmokėti peržiūrą, jei kortelių numerius tvarkote patys, o ne per patikimą apmokėjimo puslapį, saugote sveikatos, finansinius ar vaikų duomenis, parduodate įmonėms, kurios reikalauja saugumo klausimynų, arba jūsų nutekėjimas padarytų rimtą žalą. Galimybė eksportuoti kodą labai palengvina tokią peržiūrą.

Saugumas kuriant su Mythex

Mythex neturi saugumo skenavimo skydelio, todėl procesas – tai pateiktas kontrolinis sąrašas. Keletas dalykų padeda:

• Projekto paslaptys. Raktus saugokite projekto nustatymuose → Paslaptys arba per paslapčių kortelę, kurią agentas rodo pokalbyje, kad jie neatsidurtų kode ar pranešimuose. Pakeitus paslaptį gyvai programai, paskelbkite iš naujo.
• Planavimo ir klausimų režimai. Paprašykite agento peržiūrėti leidimus nieko nekeičiant: „Klausimų režime išvardink kiekvieną API maršrutą ir kokį leidimo patikrinimą jis atlieka.“
• /test leidžia agentui paspausti per jūsų peržiūrą kaip naudotojui – naudinga dviejų paskyrų testui iš 2 skyriaus.
• Kontrolinės vietos leidžia atšaukti pakeitimą, kuris ką nors sugadino.

Žr. Saugumas jūsų kuriamoms programoms ir Aplinkos kintamieji ir paslaptys dokumentacijoje. Jei dabar pridedate naudotojų paskyras, perskaitykite kaip pridėti prisijungimą prie programos.

Klausimai