Bezbednosna checklista za aplikacije napravljene uz AI: šta proveriti pre lansiranja

Pre nego što prave ljude počnu da koriste aplikaciju koju ste napravili uz AI, proverite sedam stvari: svaka stranica i API proverava ko je korisnik i šta sme da radi; tajni ključevi žive na serveru, nikada u pregledaču ili chatu; sav unos se validira na serveru; svaki korisnik može da pristupi samo svojim zapisima; prijava i skupi krajnji tačke su ograničeni po broju zahteva; zavisnosti su ažurne; i možete da vratite podatke ako nešto pođe po zlu. Checklista ispod pretvara svaku od ovih stvari u konkretne testove koje možete da izvedete bez čitanja koda.

Alati za izradu aplikacija uz AI dobro čine da funkcije rade. Nisu automatski pažljivi, jer „pažljivost“ retko stoji u zahtevu. Većina problema ispod nastaje zbog stvari koje niko nije tražio, pa je popravka obično u tome da to tražite.

Kako koristiti ovu checklistu

Prolazite kroz nju redom, a za svaku stavku uradite dve stvari: pitajte AI da se postara da je rešeno i sami je testirajte. AI može da napiše proveru dozvola; samo test pokazuje da radi. Stavke su označene ovako:

• Obavezno — uradite ovo pre nego što aplikaciju počne da koristi iko drugi.
• Preporučeno — uradite ovo pre nego što imate prave korisnike ili prave podatke.
• Kasnije — vredi uraditi kako aplikacija raste.

Ako imate samo sat vremena, uradite sve obavezne stavke.

1. Autentikacija: ko je ovo?

Autentikacija znači potvrđivanje ko je neko — obično prijavom. Pogledajte šta je autentikacija za osnove i kako dodati prijavu u aplikaciju za opcije.

• Obavezno: Svaka stranica koja prikazuje privatne podatke zahteva prijavu. Test: odjavite se, pa URL privatne stranice nalepite direktno u pregledač.
• Obavezno: Svaka API krajnja tačka iza tih stranica takođe zahteva prijavu — ne samo stranica. Test: odjavite se, otvorite karticu mreže u pregledaču i ponovite zahtev koji je aplikacija slala dok ste bili prijavljeni.
• Obavezno: Lozinke se čuvaju heširane sporim algoritmom za heširanje lozinki, nikada u običnom tekstu. OWASP-ove smernice za čuvanje lozinki preporučuju Argon2id na prvom mestu, uz scrypt, bcrypt ili PBKDF2 kao alternative. Pitajte: „Kako se čuvaju lozinke?“
• Preporučeno: Linkovi za resetovanje lozinke ističu i rade samo jednom.
• Preporučeno: Kolačići sesije su označeni sa Secure, HttpOnly i SameSite, a odjava završava sesiju i na serveru.
• Kasnije: Ponudite dvofaktorsku autentikaciju ili prijavu preko provajdera koji je ima.

Proverite svaku API rutu i stranicu koja vraća korisničke podatke. Svaka mora da odbije zahteve korisnika koji nisu prijavljeni, na serveru, a ne samo u kodu stranice. Navedite rute koje ste proverili.

2. Autorizacija: šta smeju da rade?

Autorizacija je korak posle prijave: odlučivanje šta ovaj konkretan korisnik sme da vidi i menja. Tu aplikacije napravljene uz AI najčešće imaju ozbiljne rupe, jer aplikacija izgleda ispravno — kontrolna tabla svakog korisnika prikazuje samo njegove podatke — dok server rado vraća tuđe podatke ako ih neko direktno zatraži.

• Obavezno: Svako čitanje, izmena i brisanje proverava da zapis pripada trenutnom korisniku (ili njegovom timu), na serveru.
• Obavezno: Testirajte: napravite dva naloga, A i B. Kao A, otvorite jedan od A-ovih zapisa i zapišite ID iz URL-a ili mrežnog zahteva. Prijavite se kao B i zatražite isti ID. B mora da dobije grešku, a ne podatke od A.
• Obavezno: Stranice i API krajnje tačke za administratore proveravaju ulogu korisnika na serveru. Sakrivanje linka za admin nije zaštita.
• Obavezno: Korisnici ne mogu da promene sopstvenu ulogu, cenu, saldo ili polja vlasnika izmenom zahteva. Test: u kartici mreže pogledajte šta šalje ažuriranje profila. Ako uključuje polja poput role ili isAdmin, zatražite od AI-ja da ih ignoriše sa klijenta.
• Preporučeno: ID-ovi u URL-ovima teško se pogađaju (nasumični ID-ovi umesto 1, 2, 3). Ovo nije zamena za provere dozvola, ali ograničava štetu kada nedostaje jedna.

Za svaku krajnju tačku koja čita ili menja zapis, proverite na serveru da je prijavljeni korisnik njen vlasnik ili ima pravo pristupa. Ako nije, vratite 404. Zatim mi pokažite kako biste ovo testirali sa dva naloga.

3. Pristup na nivou reda u bazi podataka

„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 mogu da se urade dobro. Važno je:

• Obavezno: Ako pregledač direktno razgovara sa bazom podataka (neki hostovani proizvodi baza to dozvoljavaju), pravila na nivou reda su uključena za svaku tabelu. Bez njih, svako sa javnim ključem može da pročita celu tabelu.
• Obavezno: Upiti filtriraju po trenutnom korisniku ili timu, a ne po ID-u koji pošalje pregledač.
• Preporučeno: Deljeni podaci (projekti tima) imaju jasno pravilo o tome ko je u timu, sprovedeno na jednom mestu.

4. Tajne i API ključevi

API ključ je lozinka za neki servis. Stripe, imejl i AI provajderi svi ih koriste. Za pozadinu pogledajte šta su promenljive okruženja i tajne.

• Obavezno: Ključevi se čuvaju u promenljivima okruženja ili tajnama projekta, nikada upisani u kod.
• Obavezno: Ključevi koji mogu da troše novac ili čitaju privatne podatke koriste se samo na serveru. Test: otvorite živi sajt, pogledajte izvorni kod stranice i JavaScript fajlove u alatima za programere i potražite početak ključa (na primer sk_). Ne sme da se pojavi.
• Obavezno: Ključevi nikada nisu nalepljeni u chat, javni repozitorijum ili snimak ekrana. Ako jesu, zamenite ih kod provajdera (napravite novi, obrišite stari).
• Preporučeno: Koristite ograničene ili ograničenog opsega ključeve tamo gde provajder to nudi. Stripe, na primer, preporučuje ograničene ključeve koji imaju samo dozvole koje vaša integracija treba.
• Preporučeno: Probni i pravi ključevi su odvojeni, a živa aplikacija koristi žive ključeve tek kada ste spremni.

Neki ključevi su namenjeni da budu javni — Stripe-ov javni ključ (pk_…) ili ključ za mape ograničen na vaš domen. Pravilo se odnosi na ključeve koji daju moć, a ne na svaki niz koji liči na ključ.

5. Validacija unosa

Sve što korisnik pošalje — polja formulara, otpremanje fajlova, parametri u URL-u — može da bude bilo šta, a ne samo ono što vaš formular dozvoljava.

• Obavezno: Validacija se radi na serveru, a ne samo u pregledaču. Provere u pregledaču služe za udobnost; svako može da ih preskoči.
• Obavezno: Upiti ka bazi koriste parametre, a ne tekst nalepljen od unosa korisnika (ovo sprečava SQL injection). Pitajte AI da potvrdi.
• Obavezno: Tekst koji korisnici unose prikazuje se kao tekst, a ne izvršava se kao HTML. Test: unesite <b>hello</b> kao ime. Trebalo bi da vidite oznake, a ne podebljan tekst.
• Preporučeno: Otpremanje fajlova proverava tip i veličinu, a otpremljeni fajlovi se ne služe sa glavnog domena aplikacije kao stranice koje se mogu pokrenuti.
• Preporučeno: Greške prikazane korisnicima su proste („Nešto nije u redu“); detaljne greške idu samo u logove servera.
• Preporučeno: Webhook-ovi od servisa poput Stripe-a proveravaju potpis provajdera pre nego što deluju. Pogledajte šta je webhook.

Dodajte validaciju na serveru u svaku formu i API krajnju tačku: obavezna polja, dužine, formati i dozvoljene vrednosti. Odbijte sve drugo uz jasnu poruku. Ne prikazujte korisnicima interne detalje grešaka.

6. Ograničenja zahteva i zloupotreba

Ograničenje zahteva ograničava koliko zahteva neko može da pošalje u jednom periodu. Bez njega, bilo ko može da pogađa lozinke ceo dan, da zatrpa vašu formu za registraciju ili da napravi veliki račun na plaćenom API-ju.

• Obavezno: Prijava, registracija i resetovanje lozinke ograničeni su po IP adresi i po nalogu.
• Obavezno: Sve što vas košta po pozivu — zahtevi AI modela, SMS, imejl — ima ograničenje po korisniku i zahteva prijavu.
• Preporučeno: Javne forme (kontakt, lista čekanja) imaju zaštitu od neželjene pošte: ograničenje zahteva, skriveno polje koje robot popuni (honeypot) ili CAPTCHA.
• Preporučeno: Postavite ograničenja potrošnje ili upozorenja kod plaćenih provajdera, da greška ili napadač ne mogu da prave neograničen račun.

7. Zavisnosti

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

• Preporučeno: Pitajte AI da proveri poznate ranjivosti (za JavaScript projekte, npm audit ili ekvivalent za vaš menadžer paketa) i ažurira ono što je pogođeno.
• Preporučeno: Uklonite pakete koje aplikacija više ne koristi.
• Preporučeno: Budite oprezni sa paketima koje koristi vrlo malo ljudi ili čija imena liče na greške u kucanju popularnih.
• Kasnije: Proveravajte na svakih mesec-dva ili uključite automatska upozorenja ako je vaš kod na GitHub-u.

8. Rezervne kopije i oporavak

Bezbednost obuhvata i mogućnost oporavka od grešaka — vaših, AI-jevih ili napadačevih.

• Obavezno: Znajte gde se nalaze vaši podaci i da li su sačuvani u rezervi. Ne pretpostavljajte; proverite dokumentaciju vašeg hosta.
• Preporučeno: Čuvajte sopstveni periodični izvoz važnih podataka (na primer funkciju izvoza u CSV ili dump baze), na odvojenom mestu.
• Preporučeno: Čuvajte kod u sistemu za verzionisanje, da se bilo koja verzija može vratiti.
• Preporučeno: Destruktivne radnje (brisanje naloga, brisanje projekta) traže potvrdu, a razmotrite „meko brisanje“ koje se neko vreme može poništiti.
• Kasnije: Jednom stvarno testirajte vraćanje. Rezervna kopija koju nikada niste vratili je nada, a ne plan.

9. Pre lansiranja

• Obavezno: Živi sajt koristi HTTPS svuda.
• Obavezno: Probni podaci, test nalozi i stranice za otklanjanje grešaka iz razvoja su uklonjeni.
• Preporučeno: Politika privatnosti navodi koje podatke prikupljate i zašto — u mnogim oblastima obavezno ako prikupljate lične podatke. Ne tvrdite sertifikate (SOC 2, HIPAA) koje nemate.
• Preporučeno: Imate način da vas kontaktiraju o bezbednosnim problemima, i znate kako brzo da zamenite svaki ključ.

Za širi pregled pre lansiranja, pored bezbednosti, pogledajte kako prototip uz AI dovesti u produkciju.

Kada zatražiti profesionalnu proveru

Checklista hvata uobičajene greške; ne zamenjuje stručnjaka. Razmotrite plaćenu proveru ako sami obrađujete brojeve kartica umesto kroz hostovanu naplatu, čuvate zdravstvene, finansijske ili podatke o deci, prodajete kompanijama koje traže bezbednosne upitnike, ili biste bili ozbiljno oštećeni curenjem podataka. Kod koji možete da izvezete znatno olakšava takvu proveru.

Bezbednost pri gradnji na Mythex-u

Mythex nema panel za bezbednosno skeniranje, pa je gornja checklista proces koji treba pratiti. Nekoliko stvari pomaže:

• Tajne projekta. Čuvajte ključeve pod podešavanja projekta → Secrets, ili kroz karticu sa tajnama koju agent prikazuje u chatu, da ostanu van koda i poruka. Posle promene tajne za živu aplikaciju, objavite ponovo.
• Režimi Plan i Ask. Zamolite agenta da pregleda dozvole bez menjanja koda: „U Ask režimu nabroj svaku API rutu i koju proveru dozvola radi.“
• /test agent klikće kroz vaš pregled kao korisnik — korisno za test sa dva naloga iz odeljka 2.
• Checkpoint-i vam omogućavaju da vratite promenu koja je nešto pokvarila.

Pogledajte Bezbednost za aplikacije koje pravite i Promenljive okruženja i tajne u dokumentaciji. Ako sledeće dodajete korisničke naloge, pročitajte kako dodati prijavu u aplikaciju.

Pitanja