Bezpečnostný kontrolný zoznam pre aplikácie vytvorené s AI: čo skontrolovať pred spustením

Predtým, než aplikáciu, ktorú ste postavili s AI, začnú používať skutoční ľudia, skontrolujte sedem vecí: každá stránka a API overuje, kto je používateľ a čo smie robiť; tajné kľúče žijú na serveri, nikdy v prehliadači ani v chate; všetky vstupy sa validujú na serveri; každý používateľ sa dostane iba ku svojim záznamom; prihlásenie a drahé koncové body majú limity požiadaviek; závislosti sú aktuálne; a viete obnoviť svoje dáta, ak sa niečo pokazí. Kontrolný zoznam nižšie premieňa každú z týchto vecí na konkrétne testy, ktoré môžete spustiť bez čítania kódu.

Nástroje na tvorbu aplikácií s AI sú dobré v tom, aby funkcie fungovali. Nie sú automaticky opatrné, pretože „opatrnosť“ sa v zadaní zriedka objaví. Väčšina problémov nižšie vzniká z vecí, o ktoré nikto nepožiadal, takže oprava je zvyčajne v tom, že si to vyžiadate.

Ako používať tento kontrolný zoznam

Prejdite ho v poradí a pri každej položke urobte dve veci: opýtajte sa AI, aby zabezpečila, že je to vyriešené, a otestujte to sami. AI dokáže napísať kontrolu oprávnení; iba test vám povie, že funguje. Položky sú označené takto:

• Musí — urobte to predtým, než aplikáciu použije ktokoľvek iný.
• Malo by — urobte to predtým, než budete mať skutočných používateľov alebo skutočné dáta.
• Neskôr — stojí za to urobiť, keď aplikácia rastie.

Ak máte iba hodinu, urobte všetky položky Musí.

1. Autentifikácia: kto je toto?

Autentifikácia znamená overenie, kto niekto je — zvyčajne prihlásenie. Základy nájdete v čo je autentifikácia a možnosti v ako pridať prihlásenie do aplikácie.

• Musí: Každá stránka, ktorá zobrazuje súkromné dáta, vyžaduje prihlásenie. Test: odhláste sa a vložte adresu URL súkromnej stránky priamo do prehliadača.
• Musí: Každý koncový bod API za týmito stránkami tiež vyžaduje prihlásenie — nielen stránka. Test: odhláste sa, otvorte kartu sieťových požiadaviek v prehliadači a zopakujte požiadavku, ktorú aplikácia odoslala, keď ste boli prihlásení.
• Musí: Heslá sú ukladané zahashované pomaly fungujúcim algoritmom na hashovanie hesiel, nikdy v čistom texte. Odporúčania OWASP pre ukladanie hesiel odporúčajú najprv Argon2id, s alternatívami scrypt, bcrypt alebo PBKDF2. Opýtajte sa: „Ako sa ukladajú heslá?“
• Malo by: Odkazy na obnovenie hesla vypršia a fungujú iba raz.
• Malo by: Relačné cookies sú označené Secure, HttpOnly a SameSite a odhlásenie ukončí reláciu na serveri.
• Neskôr: Ponúknite dvojfaktorovú autentifikáciu alebo prihlásenie cez poskytovateľa, ktorý ju má.

Skontrolujte každú trasu API a stránku, ktorá vracia dáta používateľa. Každá musí odmietnuť požiadavky od používateľov, ktorí nie sú prihlásení, na serveri, nielen v kóde stránky. Vypíšte trasy, ktoré ste skontrolovali.

2. Autorizácia: čo smú robiť?

Autorizácia je krok po prihlásení: rozhodnutie, čo smie tento konkrétny používateľ vidieť a meniť. Práve tu majú aplikácie vytvorené s AI najčastejšie vážne diery, pretože aplikácia vyzerá správne — dashboard každého používateľa zobrazuje iba jeho dáta — zatiaľ čo server ochotne vydá dáta ktoréhokoľvek používateľa, ak sa ho niekto opýta priamo.

• Musí: Každé čítanie, aktualizácia a mazanie overuje na serveri, že záznam patrí aktuálnemu používateľovi (alebo jeho tímu).
• Musí: Otestujte to: vytvorte dva účty, A a B. Ako A otvorte jeden zo záznamov A a poznačte si ID v adrese URL alebo sieťovej požiadavke. Prihláste sa ako B a požiadajte o rovnaké ID. B musí dostať chybu, nie dáta A.
• Musí: Stránky správcu a koncové body API správcu kontrolujú rolu používateľa na serveri. Skrytie odkazu na správcu nie je ochrana.
• Musí: Používatelia nemôžu zmeniť svoju rolu, cenu, zostatok ani vlastnícke polia úpravou požiadavky. Test: v karte sieťových požiadaviek sa pozrite, čo posiela aktualizácia profilu. Ak obsahuje polia ako role alebo isAdmin, požiadajte AI, aby ich z klienta ignorovala.
• Malo by: ID v adresách URL sa ťažko odhadujú (náhodné ID namiesto 1, 2, 3). Toto nenahrádza kontroly oprávnení, ale obmedzuje škodu, keď jedna chýba.

Pre každý koncový bod, ktorý číta alebo mení záznam, skontrolujte na serveri, že prihlásený používateľ ho vlastní alebo k nemu smie pristupovať. Ak nie, vráťte 404. Potom mi ukážte, ako by ste to otestovali s dvoma účtami.

3. Prístup na úrovni riadkov v databáze

„Prístup na úrovni riadkov“ znamená, že každý riadok tabuľky (jedna rezervácia, jedna faktúra) je viditeľný iba pre používateľov, ku ktorým patrí. Sú dva bežné spôsoby, ako to vynútiť:

Oboje sa dá urobiť dobre. Dôležité je:

• Musí: Ak prehliadač komunikuje s databázou priamo (niektoré hostované databázové produkty to umožňujú), pravidlá na úrovni riadkov sú zapnuté pre každú tabuľku. Bez nich môže ktokoľvek s verejným kľúčom prečítať celú tabuľku.
• Musí: Dotazy filtrujú podľa aktuálneho používateľa alebo tímu, nie podľa ID, ktoré pošle prehliadač.
• Malo by: Zdieľané dáta (projekty tímu) majú jasné pravidlo, kto je v tíme, presadzované na jednom mieste.

4. Tajomstvá a API kľúče

API kľúč je heslo pre službu. Stripe, e-mail a poskytovatelia AI ich všetci používajú. Na pozadí si pozrite čo sú premenné prostredia a tajomstvá.

• Musí: Kľúče sú uložené v premenných prostredia alebo tajomstvách projektu, nikdy zapísané v kóde.
• Musí: Kľúče, ktoré môžu míňať peniaze alebo čítať súkromné dáta, sa používajú iba na serveri. Test: otvorte svoj živý web, pozrite zdrojový kód stránky a súbory JavaScript v nástrojoch pre vývojárov a vyhľadajte začiatok svojho kľúča (napríklad sk_). Nesmie sa objaviť.
• Musí: Kľúče nikdy neboli vložené do chatu, verejného repozitára ani na snímku obrazovky. Ak áno, zrušte ich u poskytovateľa (vytvorte nový a starý vymažte).
• Malo by: Tam, kde to poskytovateľ ponúka, používajte obmedzené alebo rozsahom vymedzené kľúče. Stripe napríklad odporúča obmedzené kľúče, ktoré majú iba oprávnenia, ktoré vaša integrácia potrebuje.
• Malo by: Testovacie a živé kľúče sú oddelené a živá aplikácia používa živé kľúče, iba keď ste pripravení.

Niektoré kľúče sú navrhnuté ako verejné — Stripe publishable key (pk_…) alebo kľúč pre mapy obmedzený na vašu doménu. Pravidlo sa týka kľúčov, ktoré dávajú moc, nie každého reťazca, ktorý vyzerá ako kľúč.

5. Validácia vstupov

Čokoľvek, čo používateľ pošle — polia formulára, nahrávané súbory, parametre v URL — môže byť čokoľvek, nielen to, čo váš formulár povoľuje.

• Musí: Validácia prebieha na serveri, nie iba v prehliadači. Kontroly v prehliadači slúžia na pohodlie; každý ich môže preskočiť.
• Musí: Dotazy do databázy používajú parametre, nie text zlepený zo vstupu používateľa (to zabraňuje SQL injection). Požiadajte AI, aby to potvrdila.
• Musí: Text, ktorý používatelia zadajú, sa zobrazuje ako text, nie ako spustený HTML. Test: zadajte <b>ahoj</b> ako svoje meno. Mali by ste vidieť značky, nie tučný text.
• Malo by: Nahrávanie súborov kontroluje typ a veľkosť a nahrané súbory sa nepodávajú z hlavnej domény aplikácie ako spustiteľné stránky.
• Malo by: Chyby zobrazené používateľom sú jednoduché („Niečo sa pokazilo“); podrobné chyby idú iba do logov servera.
• Malo by: Webhooky zo služieb ako Stripe overia podpis poskytovateľa pred tým, ako niečo urobia. Pozrite si čo je webhook.

Pridajte validáciu na strane servera ku každému formuláru a koncovému bodu API: povinné polia, dĺžky, formáty a povolené hodnoty. Čokoľvek iné odmietnite s jasnou správou. Používateľom neukazujte interné podrobnosti chýb.

6. Limity požiadaviek a zneužitie

Limit požiadaviek obmedzuje, koľko požiadaviek môže niekto odoslať v danom období. Bez nich môže ktokoľvek uhádnuť heslá celý deň, zaplaviť váš registračný formulár alebo nafúknuť účet za platený API.

• Musí: Prihlásenie, registrácia a obnovenie hesla majú limit požiadaviek na IP adresu a na účet.
• Musí: Všetko, čo vás stojí peniaze za volanie — požiadavky na AI model, SMS, e-mail — má limit na používateľa a vyžaduje prihlásenie.
• Malo by: Verejné formuláre (kontakt, čakacia listina) majú ochranu proti spamu: limit požiadaviek, skryté pole honeypot alebo CAPTCHA.
• Malo by: Nastavte limity výdavkov alebo upozornenia u platených poskytovateľov, aby chyba alebo útočník nemohli vyprodukovať neobmedzený účet.

7. Závislosti

Aplikácie sa skladajú z balíkov s otvoreným zdrojovým kódom a balíky majú občas známe zraniteľnosti.

• Malo by: Požiadajte AI, aby skontrolovala známe zraniteľnosti (pri projektoch v JavaScripte npm audit alebo ekvivalent pre váš správca balíkov) a aktualizovala postihnuté balíky.
• Malo by: Odstráňte balíky, ktoré aplikácia už nepoužíva.
• Malo by: Buďte opatrní voči balíkom s veľmi malým počtom používateľov alebo názvom, ktorý vyzerá ako preklep populárneho balíka.
• Neskôr: Kontrolujte to každý mesiac alebo dva, alebo zapnite automatické upozornenia, ak je váš kód na GitHube.

8. Zálohy a obnova

Bezpečnosť zahŕňa schopnosť obnoviť sa po chybách — vašich, AI alebo útočníka.

• Musí: Vedzte, kde sú vaše dáta a či sa zálohujú. Nepredpokladajte to; skontrolujte dokumentáciu svojho hostingu.
• Malo by: Ponechajte si vlastný pravidelný export dôležitých dát (napríklad funkciu exportu do CSV alebo výpis databázy) uložený na samostatnom mieste.
• Malo by: Držte kód vo verziovaní, aby sa dala obnoviť ktorákoľvek verzia.
• Malo by: Deštruktívne akcie (zmazanie účtu, zmazanie projektu) žiadajú potvrdenie a zvážte „mäkké mazanie“, ktoré sa dá na chvíľu vrátiť späť.
• Neskôr: Raz skutočne otestujte obnovu. Záloha, ktorú ste nikdy neobnovili, je nádej, nie plán.

9. Pred spustením

• Musí: Živý web používa všade HTTPS.
• Musí: Ukážkové dáta, testovacie účty a ladiace stránky z vývoja sú odstránené.
• Malo by: Zásady ochrany súkromia uvádzajú, aké dáta zbierate a prečo — v mnohých krajinách sa vyžadujú, ak zbierate osobné údaje. Nepripisujte si certifikácie (SOC 2, HIPAA), ktoré nemáte.
• Malo by: Máte spôsob, ako vás môžu kontaktovať kvôli bezpečnostným problémom, a viete, ako rýchlo zmeniť každý kľúč.

Pre širší prehľad pred spustením nad rámec bezpečnosti pozrite ako dostať prototyp AI do produkcie.

Kedy si vyžiadať odborné posúdenie

Kontrolný zoznam zachytí bežné chyby; nenahrádza odborníka. Zvážte zaplatenie posúdenia, ak spracúvate čísla kariet sami namiesto cez hostovanú pokladňu, uchovávate zdravotné, finančné alebo detské údaje, predávate firmám, ktoré žiadajú bezpečnostné dotazníky, alebo by vás únik vážne poškodil. Ak sa dá váš kód exportovať, takéto posúdenie je oveľa jednoduchšie.

Bezpečnosť pri stavbe na Mythex

Mythex neobsahuje panel s bezpečnostným skenom, takže postupom, ktorý treba dodržať, je vyššie uvedený kontrolný zoznam. Niektoré veci, ktoré pomáhajú:

• Tajomstvá projektu. Ukladajte kľúče v nastaveniach projektu → Tajomstvá alebo cez kartu tajomstiev, ktorú agent zobrazí v chate, aby zostali mimo vášho kódu a správ. Po zmene tajomstva pre živú aplikáciu publikujte znova.
• Režimy Plán a Otázka. Požiadajte agenta, aby skontroloval oprávnenia bez úprav: „V režime Otázka vypíš každú trasu API a aký kontrolu oprávnení vykonáva.“
• /test nechá agenta preklikať váš náhľad ako používateľ — užitočné na test s dvoma účtami z časti 2.
• Kontrolné body vám umožnia vrátiť zmenu, ktorá niečo pokazila.

Pozrite si Bezpečnosť aplikácií, ktoré staviate a Premenné prostredia a tajomstvá v dokumentácii. Ak budete ďalej pridávať používateľské účty, prečítajte si ako pridať prihlásenie do aplikácie.

Otázky