Kontrolna lista sigurnosti za aplikacije napravljene AI-jem: šta provjeriti prije lansiranja

Prije nego što stvarni ljudi počnu koristiti aplikaciju koju si napravio AI-jem, provjeri sedam stvari: svaka stranica i API provjerava ko je korisnik i šta smije da radi; tajni ključevi žive na serveru, nikad u browseru ili chatu; sav unos se provjerava na serveru; svaki korisnik može doći samo do svojih zapisa; prijava i skupi endpointi imaju ograničenje zahtjeva; zavisnosti su ažurne; i možeš vratiti podatke ako nešto pođe po zlu. Kontrolna lista u nastavku pretvara svaku od tih stavki u konkretne testove koje možeš izvesti bez čitanja koda.

AI graditelji aplikacija dobro prave funkcije koje rade. Nisu automatski oprezni, jer se "oprezno" rijetko navodi u upitu. Većina problema u nastavku dolazi od stvari koje niko nije tražio, pa je rješenje obično da ih zatražiš.

Kako koristiti ovu kontrolnu listu

Radi kroz nju redom i za svaku stavku uradi dvije stvari: zamoli AI da se postara da je riješeno, i testiraj sam. AI može napisati provjeru dozvola; samo test ti kaže da radi. Stavke su označene:

• Obavezno — uradi prije nego što išta drugi koristi aplikaciju.
• Preporučeno — uradi prije nego što imaš prave korisnike ili prave podatke.
• Kasnije — vrijedi uraditi kako aplikacija raste.

Ako imaš samo sat vremena, uradi sve obavezne stavke.

1. Autentifikacija: ko je ovo?

Autentifikacija znači potvrditi ko je neko, obično kroz prijavu. Pogledaj šta je autentifikacija za osnove i kako dodati prijavu u aplikaciju za opcije.

• Obavezno: Svaka stranica koja prikazuje privatne podatke traži prijavu. Test: odjavi se, pa zalijepi URL privatne stranice direktno u browser.
• Obavezno: Svaki API endpoint iza tih stranica također traži prijavu, ne samo stranica. Test: odjavi se, otvori network tab u browseru i ponovi zahtjev koji je aplikacija slala dok si bio prijavljen.
• Obavezno: Lozinke se čuvaju heširane sporim algoritmom za heširanje lozinki, nikad u čistom tekstu. OWASP-ove smjernice za čuvanje lozinki preporučuju prvo Argon2id, a kao alternative scrypt, bcrypt ili PBKDF2. Pitaj: "Kako se čuvaju lozinke?"
• Preporučeno: Linkovi za resetovanje lozinke istječu i rade samo jednom.
• Preporučeno: Kolačići sesije su označeni s Secure, HttpOnly i SameSite, a odjava gasi sesiju i na serveru.
• Kasnije: Ponudi dvofaktorsku autentifikaciju ili prijavu preko providera koji je ima.

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

2. Autorizacija: šta smiju da rade?

Autorizacija je korak nakon prijave: odlučivanje šta ovaj konkretan korisnik smije da vidi i mijenja. Upravo tu AI aplikacije najčešće imaju ozbiljne rupe, jer aplikacija izgleda ispravno — kontrolna tabla svakog korisnika prikazuje samo njegove podatke — dok server bez problema preda tuđe podatke ako ih neko direktno zatraži.

• Obavezno: Svako čitanje, izmjena i brisanje provjerava na serveru da zapis pripada trenutnom korisniku (ili njegovom timu).
• Obavezno: Testiraj: napravi dva naloga, A i B. Kao A, otvori jedan od A-ovih zapisa i zapamti ID iz URL-a ili mrežnog zahtjeva. Prijavi se kao B i zatraži isti ID. B mora dobiti grešku, a ne A-ove podatke.
• Obavezno: Admin stranice i admin API endpointi provjeravaju korisnikovu ulogu na serveru. Sakrivanje admin linka nije zaštita.
• Obavezno: Korisnici ne mogu promijeniti svoju ulogu, cijenu, stanje ili polja vlasnika mijenjanjem zahtjeva. Test: u network tabu pogledaj šta šalje ažuriranje profila. Ako uključuje polja poput role ili isAdmin, zamoli AI da ih ignoriše kada dolaze od klijenta.
• Preporučeno: ID-ovi u URL-ovima teško se pogađaju (nasumični ID-ovi umjesto 1, 2, 3). Ovo nije zamjena za provjere dozvola, ali ograničava štetu kada nedostaje jedna.

Za svaki endpoint koji čita ili mijenja zapis, provjeri na serveru da je prijavljeni korisnik vlasnik ili ima pravo pristupa. Ako nije, vrati 404. Zatim mi pokaži kako bih ovo testirao s dva naloga.

3. Pristup na nivou reda u bazi

"Pristup na nivou reda" znači da je svaki red tabele (jedna rezervacija, jedna faktura) vidljiv samo korisnicima kojima pripada. Postoje dva uobičajena načina da se to sprovede:

Oba se mogu uraditi dobro. Važno je:

• Obavezno: Ako browser direktno komunicira s bazom (neki hostovani proizvodi za baze to dozvoljavaju), pravila na nivou reda su uključena za svaku tabelu. Bez njih, svako ko ima javni ključ može pročitati cijelu tabelu.
• Obavezno: Upiti filtriraju po trenutnom korisniku ili timu, a ne po ID-ju koji šalje browser.
• Preporučeno: Zajednički podaci (projekti tima) imaju jasno pravilo ko je u timu, sprovedeno na jednom mjestu.

4. Tajne i API ključevi

API ključ je lozinka za neki servis. Stripe, e-mail i AI provajderi svi koriste ključeve. Za osnove pogledaj šta su varijable okruženja i tajne.

• Obavezno: Ključevi se čuvaju u varijablama okruženja ili tajnama projekta, nikad upisani u kod.
• Obavezno: Ključevi kojima se može trošiti novac ili čitati privatni podaci koriste se samo na serveru. Test: otvori svoj live sajt, pogledaj izvorni kod stranice i JavaScript fajlove u devtools-u i pretraži početak svog ključa (na primjer sk_). Ne smije se pojaviti.
• Obavezno: Ključevi nikad nisu zalijepljeni u chat, javni repozitorij ili snimak ekrana. Ako jesu, zamijeni ih kod provajdera (napravi novi, obriši stari).
• Preporučeno: Koristi ograničene ili scoped ključeve gdje provajder to nudi. Stripe, na primjer, preporučuje ograničene ključeve koji imaju samo dozvole koje tvoja integracija treba.
• Preporučeno: Test i live ključevi su odvojeni, a live aplikacija koristi live ključeve tek kada si spreman.

Neki ključevi su namjerno javni — Stripeov publishable ključ (pk_…) ili ključ za mape ograničen na tvoj domen. Pravilo se odnosi na ključeve koji daju moć, a ne na svaki niz koji liči na ključ.

5. Provjera unosa

Svaka stvar koju korisnik pošalje — polja obrasca, otpremljeni fajlovi, URL parametri — može biti bilo šta, ne samo ono što tvoj obrazac dozvoljava.

• Obavezno: Provjera se radi na serveru, ne samo u browseru. Provjere u browseru služe za praktičnost; svako ih može preskočiti.
• Obavezno: Upiti ka bazi koriste parametre, a ne tekst sastavljen od korisničkog unosa (ovo sprječava SQL injection). Zamoli AI da potvrdi.
• Obavezno: Tekst koji korisnici unose prikazuje se kao tekst, a ne izvršava se kao HTML. Test: u polje za ime unesi <b>hello</b>. Trebalo bi da vidiš oznake, a ne podebljan tekst.
• Preporučeno: Otpremanje fajlova provjerava tip i veličinu, a otpremljeni fajlovi se ne služe s glavnog domena aplikacije kao izvršive stranice.
• Preporučeno: Greške prikazane korisnicima su jednostavne ("Nešto nije u redu"); detaljne greške idu samo u logove servera.
• Preporučeno: Webhook-ovi od servisa poput Stripea provjeravaju potpis providera prije nego što djeluju. Pogledaj šta je webhook.

Dodaj provjeru na serveru za svaki obrazac i API endpoint: obavezna polja, dužine, formati i dozvoljene vrijednosti. Odbij sve ostalo uz jasnu poruku. Ne prikazuj korisnicima interne detalje grešaka.

6. Ograničenja zahtjeva i zloupotreba

Ograničenje zahtjeva ograničava koliko zahtjeva neko može poslati u nekom periodu. Bez njih, bilo ko može cijeli dan pogađati lozinke, preplaviti tvoj obrazac za registraciju ili potrošiti tvoj račun kod plaćenog API-ja.

• Obavezno: Prijava, registracija i resetovanje lozinke imaju ograničenje po IP adresi i po nalogu.
• Obavezno: Sve što te košta po pozivu — zahtjevi AI modelu, SMS, e-mail — ima ograničenje po korisniku i traži prijavu.
• Preporučeno: Javni obrasci (kontakt, lista čekanja) imaju zaštitu od spama: ograničenje zahtjeva, skriveno polje za zamku ili CAPTCHA.
• Preporučeno: Postavi ograničenja potrošnje ili upozorenja kod plaćenih providera, da greška ili napadač ne mogu napraviti neograničen račun.

7. Zavisnosti

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

• Preporučeno: Zamoli AI da provjeri poznate ranjivosti (za JavaScript projekte npm audit ili ekvivalent za tvoj menadžer paketa) i ažurira pogođeno.
• Preporučeno: Ukloni pakete koje aplikacija više ne koristi.
• Preporučeno: Budi oprezan s paketima koje koristi vrlo malo ljudi ili čija imena liče na greške u pisanju popularnih.
• Kasnije: Provjeravaj svakih mjesec-dva ili uključi automatska upozorenja ako je tvoj kod na GitHubu.

8. Sigurnosne kopije i oporavak

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

• Obavezno: Znaj gdje su tvoji podaci i da li su sigurnosno kopirani. Ne pretpostavljaj; provjeri dokumentaciju svog hostinga.
• Preporučeno: Čuvaj vlastiti periodični izvoz važnih podataka (na primjer, funkciju izvoza u CSV ili dump baze), na odvojenom mjestu.
• Preporučeno: Čuvaj kod u sistemu za verzije, da se bilo koja verzija može vratiti.
• Preporučeno: Destruktivne radnje (brisanje naloga, brisanje projekta) traže potvrdu, a razmisli o "meko brisanje" koje se neko vrijeme može poništiti.
• Kasnije: Jednom stvarno testiraj vraćanje. Sigurnosna kopija koju nikad nisi vratio je nada, a ne plan.

9. Prije lansiranja

• Obavezno: Live sajt koristi HTTPS svuda.
• Obavezno: Uzorak podataka, test nalozi i debug stranice iz razvoja su uklonjeni.
• Preporučeno: Politika privatnosti kaže koje podatke prikupljaš i zašto — u mnogim zemljama obavezna ako prikupljaš lične podatke. Ne tvrdi certifikate (SOC 2, HIPAA) koje nemaš.
• Preporučeno: Imaš način da te kontaktiraju o sigurnosnim problemima i znaš kako brzo zamijeniti svaki ključ.

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

Kada zatražiti stručnu provjeru

Kontrolna lista hvata uobičajene greške, ali ne zamjenjuje stručnjaka. Razmisli o plaćenoj provjeri ako sam obrađuješ brojeve kartica umjesto kroz hostovanu naplatu, čuvaš zdravstvene, finansijske ili dječje podatke, prodaješ kompanijama koje traže sigurnosne upitnike ili bi te curenje ozbiljno oštetilo. Ako je tvoj kod moguće izvesti, takva provjera je mnogo lakša.

Sigurnost pri gradnji na Mythexu

Mythex nema panel za sigurnosno skeniranje, pa je gore navedena kontrolna lista proces koji treba pratiti. Nekoliko stvari koje pomažu:

• Tajne projekta. Čuvaj ključeve pod podešavanja projekta → Secrets, ili kroz karticu s tajnama koju agent prikazuje u chatu, da ostanu van tvog koda i poruka. Nakon promjene tajne za live aplikaciju, ponovo objavi.
• Režimi Plan i Ask. Zamoli agenta da pregleda dozvole bez izmjena: "U Ask režimu izlistaj svaku API rutu i koju provjeru dozvola radi."
• /test nalaže agentu da klikće po tvom pregledu kao korisnik — korisno za test s dva naloga iz sekcije 2.
• Checkpoint-i ti omogućavaju da vratiš promjenu koja je nešto pokvarila.

Pogledaj Sigurnost za aplikacije koje praviš i Varijable okruženja i tajne u dokumentaciji. Ako sljedeće dodaješ korisničke naloge, pročitaj kako dodati prijavu u aplikaciju.

Pitanja