Kontrolni seznam varnosti za aplikacije, zgrajene z AI: kaj preveriti pred objavo

Preden resnični ljudje uporabljajo aplikacijo, ki ste jo zgradili z AI, preverite sedem stvari: vsaka stran in vsak API preverita, kdo je uporabnik in kaj sme; skrivni ključi so na strežniku, nikoli v brskalniku ali klepetu; vsi vnosi se preverijo na strežniku; vsak uporabnik lahko doseže samo svoje zapise; prijava in dragi končni nabori so omejeni po hitrosti; odvisnosti so posodobljene; in podatke lahko obnovite, če kaj gre narobe. Spodnji kontrolni seznam vsako od teh točk spremeni v konkretne preizkuse, ki jih lahko opravite, ne da bi brali kodo.

Graditelji aplikacij z AI so dobri pri tem, da stvari delujejo. Niso samodejno skrbni, ker „skrbnost“ redko stoji v pozivu. Večina spodnjih težav izhaja iz stvari, o katerih nihče ni prosil, zato je popravek običajno to, da jih zahtevate.

Kako uporabiti ta kontrolni seznam

Preglejte ga po vrsti in pri vsaki točki naredite dvoje: vprašajte AI, naj zagotovi, da je urejeno, in preizkusite sami. AI lahko napiše preverjanje dovoljenj; samo preizkus vam pove, ali deluje. Točke so označene takole:

• Obvezno — naredite pred tem, da aplikacijo uporabi kdorkoli drug.
• Priporočeno — naredite, preden imate prave uporabnike ali prave podatke.
• Pozneje — vredno narediti, ko aplikacija raste.

Če imate samo eno uro, opravite vse obvezne točke.

1. Avtentikacija: kdo je to?

Avtentikacija pomeni potrditev, kdo nekdo je — ponavadi prek prijave. Osnove preberite v kaj je avtentikacija, možnosti pa v kako dodati prijavo v svojo aplikacijo.

• Obvezno: Vsaka stran, ki prikazuje zasebne podatke, zahteva prijavo. Preizkus: odjavite se in v brskalnik neposredno prilepite naslov zasebne strani.
• Obvezno: Vsaka končna točka API za temi stranmi prav tako zahteva prijavo — ne samo stran. Preizkus: odjavite se, odprite zavihek omrežja v brskalniku in ponovite zahtevo, ki jo je aplikacija poslala med prijavo.
• Obvezno: Gesla so shranjena zgoščena z počasnim algoritmom za zgoščevanje gesel, nikoli v čistem besedilu. Smernice OWASP za shranjevanje gesel priporočajo najprej Argon2id, z scrypt, bcrypt ali PBKDF2 kot alternativami. Vprašajte: „Kako se shranjujejo gesla?“
• Priporočeno: Povezave za ponastavitev gesla potečejo in delujejo samo enkrat.
• Priporočeno: Piškotki seje so označeni z Secure, HttpOnly in SameSite, odjava pa na strežniku konča sejo.
• Pozneje: Ponudite dvostopenjsko preverjanje ali prijavo prek ponudnika, ki ga ima.

Preverite vsako pot API in stran, ki vrača uporabniške podatke. Vsaka mora zavrniti zahteve uporabnikov, ki niso prijavljeni, na strežniku, ne samo v kodi strani. Naštejte poti, ki ste jih preverili.

2. Avtorizacija: kaj smejo narediti?

Avtorizacija je korak po prijavi: odločitev, kaj ta določen uporabnik sme videti in spremeniti. Prav tu imajo aplikacije, zgrajene z AI, najpogosteje resne luknje, ker aplikacija izgleda pravilno — nadzorna plošča vsakega uporabnika prikazuje samo njegove podatke —, strežnik pa bo brez težav izročil podatke kogarkoli, če jih direktno zahtevate.

• Obvezno: Vsako branje, posodobitev in brisanje na strežniku preveri, ali zapis pripada trenutnemu uporabniku (ali njegovi ekipi).
• Obvezno: Preizkusite: ustvarite dva računa, A in B. Kot A odprite enega od zapisov A in si zapišite ID iz naslova URL ali omrežne zahteve. Prijavite se kot B in zahtevajte isti ID. B mora dobiti napako, ne podatkov od A.
• Obvezno: Strani za skrbnike in končne točke API za skrbnike na strežniku preverijo vlogo uporabnika. Skrivanje povezave do skrbniške strani ni zaščita.
• Obvezno: Uporabniki ne morejo spremeniti lastne vloge, cene, stanja ali polj lastnika s urejanjem zahteve. Preizkus: v zavihku omrežja poglejte, kaj pošlje posodobitev profila. Če vključuje polja, kot sta role ali isAdmin, zahtevajte od AI, naj jih ignorira iz odjemalca.
• Priporočeno: ID-ji v naslovih URL so težko uganljivi (naključni ID-ji namesto 1, 2, 3). To ni nadomestek za preverjanja dovoljenj, vendar omeji škodo, kadar kakšno manjka.

Pri vsaki končni točki, ki bere ali spreminja zapis, preverite na strežniku, da je prijavljeni uporabnik lastnik ali da sme dostopati. Če ne, vrnite 404. Nato mi pokažite, kako bi to preizkusili z dvema računoma.

3. Dostop na ravni vrstic v bazi podatkov

„Dostop na ravni vrstic“ pomeni, da je vsaka vrstica v tabeli (ena rezervacija, en račun) vidna samo uporabnikom, ki ji pripadajo. Obstajata dva pogosta načina, kako to uveljaviti:

Oba načina lahko izvedete dobro. Pomembno je:

• Obvezno: Če brskalnik komunicira z bazo neposredno (nekateri gostujoči izdelki baz to dovoljujejo), so pravila na ravni vrstic vklopljena za vsako tabelo. Brez njih lahko kdorkoli z javnim ključem prebere celotno tabelo.
• Obvezno: Poizvedbe filtrirajo po trenutnem uporabniku ali ekipi, ne po ID-ju, ki ga pošlje brskalnik.
• Priporočeno: Skupni podatki (projekti ekipe) imajo jasno pravilo, kdo je v ekipi, uveljavljeno na enem mestu.

4. Skrivnosti in ključi API

Klju API je geslo za storitev. Stripe, e-pošta in ponudniki AI uporabljajo vse take ključe. Za ozadje glejte kaj so okoljske spremenljivke in skrivnosti.

• Obvezno: Ključi so shranjeni v okoljskih spremenljivkah ali skrivnostih projekta, nikoli zapisani v kodo.
• Obvezno: Ključi, s katerimi se lahko porabi denar ali preberejo zasebni podatki, se uporabljajo samo na strežniku. Preizkus: odprite svojo živo stran, poglejte izvorno kodo strani in datoteke JavaScript v orodjih za razvijalce ter poiščite začetek svojega ključa (na primer sk_). Ne sme se pojaviti.
• Obvezno: Ključi nikoli niso bili prilepljeni v klepet, javni repozitorij ali posnetek zaslona. Če so, zamenjajte ključ pri ponudniku (ustvarite novega in izbrišite starega).
• Priporočeno: Kjer ponudnik ponuja omejene ali omejene na področje ključe, jih uporabite. Stripe na primer priporoča omejene ključe, ki imajo samo dovoljenja, ki jih vaša integracija potrebuje.
• Priporočeno: Testni in produkcijski ključi so ločeni, produkcijski ključi pa se uporabljajo v živi aplikaciji šele, ko ste pripravljeni.

Nekateri ključi so namenjeni javni uporabi — javni ključ Stripe (pk_…) ali ključ za zemljevide, omejen na vašo domeno. Pravilo velja za ključe, ki dajejo moč, ne za vsak niz, ki izgleda kot ključ.

5. Preverjanje vnosov

Karkoli uporabnik pošlje — polja obrazcev, nalaganje datotek, parametri v naslovu URL — je lahko karkoli, ne samo to, kar dovoljuje vaš obrazec.

• Obvezno: Preverjanje poteka na strežniku, ne samo v brskalniku. Preverjanja v brskalniku so za udobje; kdorkoli jih lahko preskoči.
• Obvezno: Poizvedbe v bazi uporabljajo parametre, ne besedila, zlepljenega iz uporabniškega vnosa (to preprečuje SQL injection). Vprašajte AI, naj potrdi.
• Obvezno: Besedilo, ki ga vnesejo uporabniki, je prikazano kot besedilo, ne izvedeno kot HTML. Preizkus: za svoje ime vnesite <b>hello</b>. Videti morate oznake, ne krepkega besedila.
• Priporočeno: Nalaganje datotek preveri vrsto in velikost, naložene datoteke pa se ne streži z glavne domene vaše aplikacije kot izvedljive strani.
• Priporočeno: Napake, prikazane uporabnikom, so preproste („Nekaj je šlo narobe“); podrobne napake gredo samo v dnevnike strežnika.
• Priporočeno: Webhooki iz storitev, kot je Stripe, preverijo podpis ponudnika, preden ukrepajo. Glejte kaj je webhook.

Dodajte preverjanje na strežniku za vsak obrazec in vsako končno točko API: obvezna polja, dolžine, oblike in dovoljene vrednosti. Vse drugo zavrnite z jasnim sporočilom. Uporabnikom ne prikazujte podrobnosti notranjih napak.

6. Omejitve hitrosti in zloraba

Omejitev hitrosti omeji, koliko zahtev lahko nekdo pošlje v določenem obdobju. Brez nje lahko kdorkoli ves dan ugiba gesla, zaplavi vaš obrazec za registracijo ali poveča račun za plačljiv API.

• Obvezno: Prijava, registracija in ponastavitev gesla so omejene po hitrosti na naslov IP in na račun.
• Obvezno: Vse, kar vas stane denar na klic — zahteve modelov AI, SMS, e-pošta — ima omejitev na uporabnika in zahteva prijavo.
• Priporočeno: Javni obrazci (kontakt, čakalna lista) imajo zaščito pred neželeno pošto: omejitev hitrosti, skrito polje (honeypot) ali CAPTCHA.
• Priporočeno: Nastavite omejitve porabe ali opozorila pri plačljivih ponudnikih, da napaka ali napadalec ne more ustvariti neomejenega računa.

7. Odvisnosti

Aplikacije so zgrajene iz paketov odprte kode, paketi pa imajo včasih znane ranljivosti.

• Priporočeno: Zahtevajte od AI, naj preveri znane ranljivosti (za projekte JavaScript npm audit ali enakovreden ukaz za vaš upravljalnik paketov) in posodobi prizadete.
• Priporočeno: Odstranite pakete, ki jih aplikacija ne uporablja več.
• Priporočeno: Bodite previdni pri paketih z zelo malo uporabniki ali imenih, ki spominjajo na tipkarske napake priljubljenih paketov.
• Pozneje: Ponovno preverite vsakih nekaj mesecev ali vklopite samodejna opozorila, če je vaša koda na GitHubu.

8. Varnostne kopije in obnova

Varnost vključuje sposobnost okrevanja po napakah — vaših, AI-jevih ali napadalčevih.

• Obvezno: Vedite, kje so vaši podatki in ali so varnostno kopirani. Ne predpostavljajte; preverite dokumentacijo gostitelja.
• Priporočeno: Hranite lasten periodičen izvoz pomembnih podatkov (na primer funkcijo izvoza v CSV ali izpis baze), shranjen ločeno.
• Priporočeno: Hranite kodo v nadzoru različic, da je mogoče obnoviti katerokoli različico.
• Priporočeno: Uničujoča dejanja (izbris računa, izbris projekta) zahtevajo potrditev, razmislite pa tudi o „mehkem brisanju“, ki ga je za nekaj časa mogoče razveljaviti.
• Pozneje: Enkrat dejansko preizkusite obnovo. Varnostna kopija, ki je nikoli niste obnovili, je upanje, ne načrt.

9. Pred lansiranjem

• Obvezno: Živa stran uporablja HTTPS povsod.
• Obvezno: Testni podatki, preizkusni računi in strani za odpravljanje napak iz razvoja so odstranjeni.
• Priporočeno: Pravilnik o zasebnosti pove, katere podatke zbirate in zakaj — v mnogih državah je obvezen, če zbirate osebne podatke. Ne trdite certifikatov (SOC 2, HIPAA), ki jih nimate.
• Priporočeno: Imate način, kako vas je mogoče kontaktirati glede varnostnih težav, in veste, kako hitro zamenjati vsak ključ.

Za širši pregled pred lansiranjem, ki presega varnost, glejte kako AI prototip pripeljati v produkcijo.

Kdaj poiskati strokovni pregled

Kontrolni seznam ujame pogoste napake; strokovnjaka ne nadomesti. Razmislite o plačanem pregledu, če kartične številke obdelujete sami namesto prek gostovane blagajne, hranite zdravstvene, finančne ali podatke otrok, prodajate podjetjem, ki zahtevajo varnostne vprašalnike, ali bi vas uhajanje resno prizadelo. Izvozljiva koda močno olajša tak pregled.

Varnost pri gradnji na Mythexu

Mythex nima plošče za varnostno preverjanje, zato je postopek, ki mu sledite, zgoraj opisani kontrolni seznam. Nekaj stvari, ki pomagajo:

• Skrivnosti projekta. Ključe shranite pod nastavitve projekta → Skrivnosti ali prek kartice s skrivnostmi, ki jo agent prikaže v klepetu, da ostanejo izven vaše kode in sporočil. Po spremembi skrivnosti za živo aplikacijo ponovno objavite.
• Načina Plan in Ask. Zahtevajte od agenta, naj pregleda dovoljenja brez urejanja: „V načinu Ask naštej vsako pot API in kakšno preverjanje dovoljenj opravi.“
• /test agentu omogoči, da klikne po vašem predogledu kot uporabnik — uporabno za preizkus z dvema računoma iz 2. poglavja.
• Kontrolne točke vam omogočajo, da povrnete spremembo, ki je nekaj pokvarila.

Glejte varnost za aplikacije, ki jih gradite in okoljske spremenljivke in skrivnosti v dokumentaciji. Če naslednje dodajate uporabniške račune, preberite kako dodati prijavo v svojo aplikacijo.

Vprašanja