Sigurnosni popis za aplikacije izrađene AI-jem: što provjeriti prije lansiranja

Prije nego što stvarni ljudi počnu koristiti aplikaciju koju si izradio AI-jem, provjeri sedam stvari: svaka stranica i API provjerava tko je korisnik i što smije raditi; tajni ključevi žive na poslužitelju, nikada u pregledniku ili razgovoru; sav unos se provjerava na poslužitelju; svaki korisnik može doći samo do vlastitih zapisa; prijava i skupi krajnji API-ji imaju ograničenje zahtjeva; ovisnosti su ažurne; a podatke možeš vratiti ako nešto pođe po krivu. Popis u nastavku pretvara svaku od tih stavki u konkretne testove koje možeš provesti bez čitanja koda.

Alati za izradu aplikacija izvrsni su u tome da funkcionalnosti rade. Nisu automatski pažljivi, jer se „pažljivost“ rijetko navodi u upitu. Većina problema u nastavku dolazi od stvari koje nitko nije tražio, pa je rješenje obično to tražiti.

Kako koristiti ovaj popis

Prođi ga redom i za svaku stavku učini dvije stvari: zamoli AI da osigura da je riješeno i sam to testiraj. AI može napisati provjeru dopuštenja; samo test pokazuje da radi. Stavke su označene:

• Obavezno — učini prije nego što itko drugi koristi aplikaciju.
• Treba — učini prije nego što imaš stvarne korisnike ili stvarne podatke.
• Kasnije — vrijedi učiniti kako aplikacija raste.

Ako imaš samo sat vremena, učini sve Obavezno stavke.

1. Autentifikacija: tko je ovo?

Autentifikacija znači potvrditi tko je netko — obično putem prijave. Osnove pogledaj u što je autentifikacija, a mogućnosti u kako dodati prijavu u aplikaciju.

• Obavezno: Svaka stranica koja prikazuje privatne podatke zahtijeva prijavu. Test: odjavi se, a zatim izravno u pregledniku zalijepi URL privatne stranice.
• Obavezno: Svaka API krajnja točka iza tih stranica također zahtijeva prijavu, ne samo stranica. Test: odjavi se, otvori karticu mreže u pregledniku i ponovi zahtjev koji je aplikacija slala dok si bio prijavljen.
• Obavezno: Lozinke se pohranjuju kao hash sporim algoritmom za hashiranje lozinki, nikada u običnom tekstu. OWASP-ove smjernice za pohranu lozinki preporučuju prvo Argon2id, a kao alternative scrypt, bcrypt ili PBKDF2. Pitaj: „Kako se pohranjuju lozinke?“
• Treba: Poveznice za resetiranje lozinke istječu i rade samo jednom.
• Treba: Kolačići sesije označeni su s Secure, HttpOnly i SameSite, a odjava završava sesiju na poslužitelju.
• Kasnije: Ponudi dvofaktorsku autentifikaciju ili prijavu putem pružatelja koji je ima.

Provjeri svaku API rutu i stranicu koja vraća korisničke podatke. Svaka mora odbiti zahtjeve korisnika koji nisu prijavljeni, na poslužitelju, a ne samo u kodu stranice. Navedi rute koje si provjerio.

2. Autorizacija: što smiju raditi?

Autorizacija je korak nakon prijave: odlučivanje što taj korisnik smije vidjeti i mijenjati. Tu AI izrađene aplikacije najčešće imaju ozbiljne rupe, jer aplikacija izgleda ispravno — nadzorna ploča svakog korisnika prikazuje samo njegove podatke — dok poslužitelj rado vraća tuđe podatke ako ih izravno zatražiš.

• Obavezno: Svako čitanje, ažuriranje i brisanje provjerava na poslužitelju pripada li zapis trenutnom korisniku (ili njegovu timu).
• Obavezno: Testiraj: napravi dva računa, A i B. Kao A otvori jedan od A-ovih zapisa i zabilježi ID u URL-u ili mrežnom zahtjevu. Prijavi se kao B i zatraži isti ID. B mora dobiti pogrešku, a ne A-ove podatke.
• Obavezno: Admin stranice i admin API krajnje točke na poslužitelju provjeravaju ulogu korisnika. Skrivanje admin poveznice nije zaštita.
• Obavezno: Korisnici ne mogu promijeniti vlastitu ulogu, cijenu, stanje ili polja vlasnika uređivanjem zahtjeva. Test: u kartici mreže pogledaj što šalje ažuriranje profila. Ako uključuje polja poput role ili isAdmin, zamoli AI da ih ignorira s klijentske strane.
• Treba: ID-ovi u URL-ovima teško se pogađaju (nasumični ID-ovi umjesto 1, 2, 3). To nije zamjena za provjere dopuštenja, ali ograničava štetu kada jedna nedostaje.

Za svaku krajnju točku koja čita ili mijenja zapis, provjeri na poslužitelju da je prijavljeni korisnik vlasnik ili ima pravo pristupa. Ako nije, vrati 404. Zatim mi pokaži kako bi to testirao s dva računa.

3. Pristup na razini redaka u bazi podataka

„Pristup na razini redaka“ znači da je svaki redak tablice (jedna rezervacija, jedan račun) vidljiv samo korisnicima kojima pripada. Postoje dva uobičajena načina za provedbu:

Oba se mogu dobro napraviti. Važno je:

• Obavezno: Ako preglednik izravno komunicira s bazom podataka (neki hostani proizvodi baza to dopuštaju), pravila na razini redaka uključena su za svaku tablicu. Bez njih svatko s javnim ključem može čitati cijelu tablicu.
• Obavezno: Upiti filtriraju po trenutnom korisniku ili timu, a ne po ID-u koji šalje preglednik.
• Treba: Dijeljeni podaci (projekti tima) imaju jasno pravilo tko je u timu, provedeno na jednom mjestu.

4. Tajne i API ključevi

API ključ je lozinka za neku uslugu. Stripe, e-pošta i AI pružatelji svi ih koriste. Za osnove pogledaj što su varijable okoline i tajne.

• Obavezno: Ključevi se pohranjuju u varijable okoline ili tajne projekta, nikada upisani u kod.
• Obavezno: Ključevi koji mogu trošiti novac ili čitati privatne podatke koriste se samo na poslužitelju. Test: otvori svoju živu stranicu, pogledaj izvorni kod stranice i JavaScript datoteke u alatima za programere i potraži početak svog ključa (na primjer sk_). Ne smije se pojaviti.
• Obavezno: Ključevi nikada nisu zalijepljeni u razgovor, javni repozitorij ili snimku zaslona. Ako jesu, zamijeni ih kod pružatelja (stvori novi i obriši stari).
• Treba: Koristi ograničene ili ograničene po opsegu ključeve gdje ih pružatelj nudi. Stripe, na primjer, preporučuje ograničene ključeve koji imaju samo dopuštenja koja tvoja integracija treba.
• Treba: Testni i produkcijski ključevi su odvojeni, a živa aplikacija koristi žive ključeve tek kada si spreman.

Neki ključevi su namijenjeni da budu javni — Stripeov javni ključ (pk_…) ili ključ za karte ograničen na tvoju domenu. Pravilo se odnosi na ključeve koji daju moć, a ne na svaki niz koji izgleda kao ključ.

5. Provjera unosa

Svaki unos korisnika — polja obrazaca, učitane datoteke, parametri u URL-u — može biti bilo što, a ne samo ono što tvoj obrazac dopušta.

• Obavezno: Provjera se radi na poslužitelju, ne samo u pregledniku. Provjere u pregledniku služe za praktičnost; svatko ih može preskočiti.
• Obavezno: Upiti prema bazi koriste parametre, a ne tekst zalijepljen iz korisničkog unosa (to sprječava SQL injection). Zamoli AI da to potvrdi.
• Obavezno: Tekst koji korisnici unose prikazuje se kao tekst, a ne izvodi kao HTML. Test: za svoje ime upiši <b>hello</b>. Trebao bi vidjeti oznake, a ne podebljani tekst.
• Treba: Učitane datoteke provjeravaju vrstu i veličinu, a učitane datoteke ne poslužuju se s glavne domene aplikacije kao izvršne stranice.
• Treba: Greške prikazane korisnicima su jednostavne („Nešto je pošlo po zlu“); detaljne greške idu samo u dnevnike poslužitelja.
• Treba: Webhookovi od usluga poput Stripea prije djelovanja provjeravaju potpis pružatelja. Pogledaj što je webhook.

Dodaj provjeru na strani poslužitelja za svaki obrazac i API krajnju točku: obavezna polja, duljine, formate i dopuštene vrijednosti. Sve ostalo odbij uz jasnu poruku. Ne prikazuj korisnicima interne detalje grešaka.

6. Ograničenja zahtjeva i zloupotreba

Ograničenje zahtjeva ograničava koliko zahtjeva netko može poslati u razdoblju. Bez njih netko može cijeli dan pogađati lozinke, preplaviti tvoj obrazac za registraciju ili potrošiti tvoj račun na plaćenom API-ju.

• Obavezno: Prijava, registracija i resetiranje lozinke imaju ograničenje po IP adresi i po računu.
• Obavezno: Sve što te košta po pozivu — zahtjevi AI modela, SMS, e-pošta — ima ograničenje po korisniku i zahtijeva prijavu.
• Treba: Javni obrasci (kontakt, lista čekanja) imaju zaštitu od spama: ograničenje zahtjeva, skriveno polje za zamku ili CAPTCHA.
• Treba: Postavi ograničenja potrošnje ili upozorenja kod plaćenih pružatelja, kako greška ili napadač ne bi stvorio neograničen račun.

7. Ovisnosti

Aplikacije se grade od paketa otvorenog koda, a paketi ponekad imaju poznate ranjivosti.

• Treba: Zamoli AI da provjeri poznate ranjivosti (za JavaScript projekte npm audit ili ekvivalent za tvoj upravitelj paketa) i ažurira što je pogođeno.
• Treba: Ukloni pakete koje aplikacija više ne koristi.
• Treba: Budi oprezan s paketima s vrlo malo korisnika ili nazivima koji izgledaju kao pogreške u pisanju popularnih.
• Kasnije: Provjeri svakih mjesec ili dva ili uključi automatska upozorenja ako je tvoj kod na GitHubu.

8. Sigurnosne kopije i oporavak

Sigurnost uključuje mogućnost oporavka od pogrešaka — tvojih, AI-jevih ili napadačevih.

• Obavezno: Znaj gdje se nalaze tvoji podaci i jesu li sigurnosno kopirani. Ne pretpostavljaj; provjeri dokumentaciju svog hostinga.
• Treba: Čuvaj vlastiti periodični izvoz važnih podataka (na primjer značajku izvoza u CSV ili dump baze), pohranjen odvojeno.
• Treba: Čuvaj kod u sustavu verzija, kako bi se svaka verzija mogla vratiti.
• Treba: Destruktivne radnje (brisanje računa, brisanje projekta) traže potvrdu, a razmisli o „mekom brisanju“ koje se može poništiti neko vrijeme.
• Kasnije: Jednom zaista testiraj vraćanje. Sigurnosna kopija koju nikada nisi vratio nada je, a ne plan.

9. Prije lansiranja

• Obavezno: Živa stranica koristi HTTPS svuda.
• Obavezno: Uzorci podataka, testni računi i stranice za otklanjanje grešaka iz razvoja su uklonjeni.
• Treba: Pravila privatnosti navode koje podatke prikupljaš i zašto — u mnogim zemljama obavezno ako prikupljaš osobne podatke. Ne tvrdi da imaš certifikate (SOC 2, HIPAA) koje nemaš.
• Treba: Imaš način da te kontaktiraju o sigurnosnim problemima i znaš brzo zamijeniti svaki ključ.

Za širu provjeru prije lansiranja, izvan sigurnosti, pogledaj kako prebaciti AI prototip u produkciju.

Kada zatražiti stručnu provjeru

Popis hvata česte greške, ali ne zamjenjuje stručnjaka. Razmotri plaćenu provjeru ako sam obrađuješ brojeve kartica umjesto kroz hostirani sustav plaćanja, čuvaš zdravstvene, financijske ili dječje podatke, prodaješ tvrtkama koje traže sigurnosne upitnike ili bi te curenje ozbiljno oštetilo. Ako se tvoj kod može izvesti, takva provjera puno je lakša.

Sigurnost pri izradi na Mythexu

Mythex nema panel za sigurnosno skeniranje, pa je gore navedeni popis proces koji slijediš. Nekoliko stvari koje pomažu:

• Tajne projekta. Ključeve pohrani u postavkama projekta → Tajne ili kroz karticu tajni koju agent prikazuje u razgovoru, kako ostali izvan koda i poruka. Nakon promjene tajne za živu aplikaciju, ponovno objavi.
• Načini Plan i Ask. Zamoli agenta da pregleda dopuštenja bez uređivanja: „U Ask načinu rada popiši svaku API rutu i koju provjeru dopuštenja radi.“
• /test agent kroz tvoj pregled klikće kao korisnik — korisno za test s dva računa iz odjeljka 2.
• Checkpointi omogućuju vraćanje promjene koja je nešto pokvarila.

Pogledaj Sigurnost za aplikacije koje gradiš i Varijable okoline i tajne u dokumentaciji. Ako sljedeće dodaješ korisničke račune, pročitaj kako dodati prijavu u aplikaciju.

Pitanja