Biztonsági ellenőrzőlista AI-val épített alkalmazásokhoz: mit nézzen át indítás előtt

Mielőtt valódi emberek használnák az AI-val épített alkalmazást, hét dolgot ellenőrizzen: minden oldal és API ellenőrzi, ki a felhasználó és mit tehet; a titkos kulcsok a szerveren élnek, soha nem a böngészőben vagy a csevegésben; minden bemenet szerveroldalon validált; minden felhasználó csak a saját rekordjaihoz fér hozzá; a bejelentkezés és a költséges végpontok sebességkorláttal védettek; a függőségek naprakészek; és vissza tudja állítani az adatait, ha valami elromlik. Az alábbi ellenőrzőlista ezeket konkrét tesztekké alakítja, amelyeket kód olvasása nélkül is el tud végezni.

Az AI alkalmazásépítők jók abban, hogy a funkciók működjenek. Attól még nem lesznek automatikusan óvatosak, mert az „óvatosság” ritkán szerepel a promptban. Az alábbi problémák nagy része olyan dolgokból ered, amelyeket senki nem kért, ezért a megoldás általában az, hogy kérje.

Hogyan használja ezt az ellenőrzőlistát

Sorban haladjon végig rajta, és minden tételnél két dolgot tegyen: kérje meg az AI-t, hogy gondoskodjon a kezeléséről, és teszteljen saját maga. Az AI meg tud írni jogosultsági ellenőrzést; csak egy teszt mutatja meg, hogy működik. A tételek jelölése:

• Kötelező — ezt végezze el, mielőtt bárki más használná az alkalmazást.
• Ajánlott — ezt végezze el, mielőtt valódi felhasználói vagy valódi adatai lesznek.
• Később — érdemes elvégezni, ahogy az alkalmazás növekszik.

Ha csak egy órája van, végezze el az összes Kötelező tételt.

1. Hitelesítés: ki ez?

A hitelesítés azt jelenti, hogy megerősítjük, ki az adott személy — általában a bejelentkezést. Az alapokért lásd mi a hitelesítés, a lehetőségekért pedig hogyan adjon bejelentkezést az alkalmazásához.

• Kötelező: Minden olyan oldal, amely privát adatot mutat, bejelentkezést követel meg. Teszt: jelentkezzen ki, majd illessze be egy privát oldal URL-jét közvetlenül a böngészőbe.
• Kötelező: Az ezek mögötti minden API végpont is bejelentkezést követel meg — nem csak az oldal. Teszt: jelentkezzen ki, nyissa meg a böngésző hálózati fülét, és ismételjen meg egy kérést, amelyet az alkalmazás bejelentkezve küldött.
• Kötelező: A jelszavak lassú jelszó-hash algoritmussal, hash-elve tárolódnak, soha nem egyszerű szövegként. Az OWASP jelszótárolási útmutatója először az Argon2id-t ajánlja, alternatívaként a scrypt, bcrypt vagy PBKDF2 használható. Kérdezze meg: „Hogyan tároljuk a jelszavakat?”
• Ajánlott: A jelszó-visszaállító linkek lejárnak, és csak egyszer működnek.
• Ajánlott: A munkamenet-sütik Secure, HttpOnly és SameSite jelöléssel rendelkeznek, a kijelentkezés pedig a szerveren is megszünteti a munkamenetet.
• Később: Kínáljon kétfaktoros hitelesítést, vagy olyan szolgáltatón keresztüli bejelentkezést, amely ezt támogatja.

Ellenőrizze minden olyan API útvonalat és oldalt, amely felhasználói adatot ad vissza. Mindegyiknek el kell utasítania a be nem jelentkezett felhasználók kéréseit, a szerveren, nem csak az oldal kódjában. Sorolja fel az ellenőrzött útvonalakat.

2. Jogosultság: mit tehet?

A jogosultság a bejelentkezés utáni lépés: annak eldöntése, mit láthat és változtathat meg ez a konkrét felhasználó. Itt szoktak az AI-val épített alkalmazások komoly hibái lenni, mert az alkalmazás helyesnek látszik — minden felhasználó irányítópultja csak a saját adatait mutatja —, miközben a szerver közvetlen kérésre szívesen kiadja bárki adatait.

• Kötelező: Minden olvasás, frissítés és törlés ellenőrzi a szerveren, hogy a rekord az aktuális felhasználóhoz (vagy a csapatához) tartozik.
• Kötelező: Teszteljen: hozzon létre két fiókot, A-t és B-t. A-ként nyisson meg egy A-hoz tartozó rekordot, és jegyezze fel az azonosítót az URL-ben vagy a hálózati kérésben. Jelentkezzen be B-ként, és kérje le ugyanazt az azonosítót. B-nek hibát kell kapnia, nem A adatait.
• Kötelező: Az admin oldalak és admin API végpontok a szerveren ellenőrzik a felhasználó szerepkörét. Az admin link elrejtése nem védelem.
• Kötelező: A felhasználók a kérés szerkesztésével sem változtathatják meg a saját szerepkörüket, árukat, egyenlegüket vagy tulajdonos mezőiket. Teszt: a hálózati fülön nézze meg, mit küld egy profilfrissítés. Ha olyan mezőket tartalmaz, mint a role vagy az isAdmin, kérje meg az AI-t, hogy a kliensoldalról ezeket hagyja figyelmen kívül.
• Ajánlott: Az URL-ekben lévő azonosítók nehezen kitalálhatók (véletlen azonosítók 1, 2, 3 helyett). Ez nem helyettesíti a jogosultsági ellenőrzéseket, de korlátozza a kárt, ha egy hiányzik.

Minden olyan végpontnál, amely rekordot olvas vagy módosít, ellenőrizze a szerveren, hogy a bejelentkezett felhasználó birtokolja-e, vagy hozzáférhet-e. Ha nem, adjon 404-es választ. Utána mutassa meg, hogyan tesztelné ezt két fiókkal.

3. Sorszintű hozzáférés az adatbázisban

A „sorszintű hozzáférés” azt jelenti, hogy egy tábla minden sora (egy foglalás, egy számla) csak azoknak a felhasználóknak látható, akikhez tartozik. Kétféle elterjedt módon lehet ezt érvényesíteni:

Mindkettő jól megvalósítható. Ami számít:

• Kötelező: Ha a böngésző közvetlenül kommunikál az adatbázissal (néhány hostolt adatbázis-termék ezt engedi), a sorszintű szabályok minden táblán be vannak kapcsolva. Nélkülük bárki, akinek megvan a nyilvános kulcs, kiolvashatja az egész táblát.
• Kötelező: A lekérdezések az aktuális felhasználóra vagy csapatra szűrnek, nem a böngésző által küldött azonosítóra.
• Ajánlott: A megosztott adatoknál (egy csapat projektjei) egyértelmű szabály van arra, ki tartozik a csapathoz, és ezt egy helyen érvényesítik.

4. Titkok és API kulcsok

Az API kulcs egy szolgáltatás jelszava. A Stripe, az e-mail és az AI szolgáltatók mind használják. Háttérinformációért lásd mik a környezeti változók és titkos kulcsok.

• Kötelező: A kulcsok a projekt környezeti változóiban vagy titkos kulcsaiban vannak tárolva, soha nem íródnak bele a kódba.
• Kötelező: Azokat a kulcsokat, amelyekkel pénzt lehet költeni vagy privát adatot olvasni, csak a szerveren használják. Teszt: nyissa meg élő oldalát, nézze meg az oldal forráskódját és a JavaScript fájlokat a fejlesztői eszközökben, és keressen rá a kulcs elejére (például sk_). Ennek nem szabad megjelennie.
• Kötelező: A kulcsokat soha nem illesztették be csevegésbe, nyilvános tárolóba vagy képernyőképbe. Ha mégis, cserélje le a szolgáltatónál (hozzon létre újat, és törölje a régit).
• Ajánlott: Ahol a szolgáltató kínálja, használjon korlátozott vagy hatókörös kulcsokat. A Stripe például olyan korlátozott kulcsokat javasol, amelyeknek csak az integrációhoz szükséges jogosultságai vannak.
• Ajánlott: A teszt- és az éles kulcsok külön vannak, és az éles alkalmazás csak akkor használ éles kulcsot, amikor Ön felkészült.

Néhány kulcs úgy van tervezve, hogy nyilvános legyen — a Stripe publikálható kulcsa (pk_…) vagy a domainhez korlátozott térképkulcs. A szabály azokra a kulcsokra vonatkozik, amelyek hatalmat adnak, nem minden olyan szövegre, amely kulcsnak látszik.

5. Bemenetek validálása

Bármit küldhet a felhasználó — űrlapmezőket, fájlfeltöltést, URL paramétereket —, nem csak azt, amit az űrlap enged.

• Kötelező: A validálás a szerveren történik, nem csak a böngészőben. A böngészős ellenőrzések kényelmi célúak; bárki megkerülheti őket.
• Kötelező: Az adatbázis-lekérdezések paramétereket használnak, nem a felhasználói bemenetből összeragasztott szöveget (ez akadályozza meg az SQL injekciót). Kérje meg az AI-t, hogy erősítse meg.
• Kötelező: A felhasználók által beírt szöveg szövegként jelenik meg, nem HTML-ként futtatva. Teszt: írja be a nevének <b>hello</b> szöveget. A címkéket kell látnia, nem félkövér szöveget.
• Ajánlott: A fájlfeltöltések ellenőrzik a típust és a méretet, a feltöltött fájlokat pedig nem szolgálják ki az alkalmazás fő domainjéről futtatható oldalakként.
• Ajánlott: A felhasználóknak megjelenített hibák egyszerűek („Valami hiba történt”); a részletes hibák csak a szerver naplóiba kerülnek.
• Ajánlott: Az olyan szolgáltatók webhookjait, mint a Stripe, a művelet előtt ellenőrizze az aláírással. Lásd mi a webhook.

Adjon szerveroldali validálást minden űrlapnak és API végpontnak: kötelező mezők, hosszak, formátumok és megengedett értékek. Mindent, ami nem felel meg, utasítson el egyértelmű üzenettel. Ne mutasson belső hibarészleteket a felhasználóknak.

6. Sebességkorlátok és visszaélés

A sebességkorlát azt szabja meg, hány kérést küldhet valaki egy időszak alatt. Enélkül bárki egész nap találgathatja a jelszavakat, elárasztja a regisztrációs űrlapot, vagy felhúzza a számláját egy fizetős API-n.

• Kötelező: A bejelentkezés, a regisztráció és a jelszó-visszaállítás IP-címenként és fiókonként sebességkorlátozott.
• Kötelező: Minden, ami hívásonként pénzbe kerül — AI modellkérések, SMS, e-mail — felhasználónkénti korláttal rendelkezik, és bejelentkezést igényel.
• Ajánlott: A nyilvános űrlapok (kapcsolat, várólista) spamvédelmet kapnak: sebességkorlát, rejtett csalimező (honeypot) vagy CAPTCHA.
• Ajánlott: Állítson be költési korlátot vagy riasztást a fizetős szolgáltatóinál, hogy egy hiba vagy egy támadó ne tudjon korlátlan számlát előállítani.

7. Függőségek

Az alkalmazások nyílt forráskódú csomagokból épülnek, és a csomagoknak néha ismert sebezhetőségeik vannak.

• Ajánlott: Kérje meg az AI-t, hogy ellenőrizze az ismert sebezhetőségeket (JavaScript projekteknél az npm audit, vagy a csomagkezelő megfelelője), és frissítse az érintetteket.
• Ajánlott: Távolítsa el azokat a csomagokat, amelyeket az alkalmazás már nem használ.
• Ajánlott: Legyen óvatos azokkal a csomagokkal, amelyeket nagyon kevesen használnak, vagy amelyek nevei népszerű csomagok elgépelésének látszanak.
• Később: Ellenőrizze újra egy-két havonta, vagy kapcsoljon be automatikus riasztásokat, ha a kódja GitHubon van.

8. Mentések és helyreállítás

A biztonsághoz tartozik, hogy vissza tudjon állni a hibákból — az ön hibáiból, az AI hibáiból vagy egy támadó tetteiből.

• Kötelező: Tudja, hol vannak az adatai, és vannak-e mentések. Ne feltételezze; ellenőrizze a szolgáltatója dokumentációjában.
• Ajánlott: Készítsen saját, rendszeres exportot a fontos adatokról (például CSV exportot vagy adatbázis-mentést), és tárolja külön helyen.
• Ajánlott: Verziókezelésben tartsa a kódját, hogy bármely verzió visszaállítható legyen.
• Ajánlott: A romboló műveletek (fiók törlése, projekt törlése) megerősítést kérjenek, és fontolja meg egy „puha törlés” bevezetését, amely egy ideig visszavonható.
• Később: Tesztelje egyszer ténylegesen a visszaállítást. Egy soha vissza nem állított mentés remény, nem terv.

9. Indítás előtt

• Kötelező: Az élő oldal mindenhol HTTPS-t használ.
• Kötelező: A fejlesztés során használt mintaadatok, teszt fiókok és hibakeresési oldalak eltávolítva.
• Ajánlott: Az adatvédelmi szabályzat leírja, milyen adatokat gyűjt és miért — sok helyen ez kötelező, ha személyes adatot gyűjt. Ne állítson olyan tanúsítványt (SOC 2, HIPAA), amellyel nem rendelkezik.
• Ajánlott: Legyen mód arra, hogy biztonsági problémákról megkeressék, és tudja, hogyan cserélje gyorsan az összes kulcsot.

Az indítás előtti, biztonságon túli átfogó átnézéshez lásd hogyan vigyen egy AI prototípust élesbe.

Mikor kérjen szakmai átnézést

Az ellenőrzőlista a gyakori hibákat fogja meg; nem helyettesíti a szakértőt. Fontolja meg a fizetős átnézést, ha bankkártyaszámokat maga kezel a hostolt fizetés helyett, egészségügyi, pénzügyi vagy gyermekadatokat tárol, olyan cégeknek ad el, amelyek biztonsági kérdőíveket kérnek, vagy ha egy szivárgás komoly kárt okozna. Ha a kódja exportálható, az átnézés sokkal könnyebb.

Biztonság a Mythexen történő építésnél

A Mythex nem tartalmaz biztonsági szkennelő panelt, ezért a fenti ellenőrzőlista a követendő folyamat. Néhány hasznos dolog:

• Projekt titkok. A kulcsokat a projektbeállítások → Titkok alatt tárolja, vagy az ügynök által a csevegésben megjelenített titkos kártyán keresztül, hogy kikerüljenek a kódból és az üzenetekből. Egy élő alkalmazás titkának megváltoztatása után publikáljon újra.
• Terv és Kérdés módok. Kérje meg az ügynököt, hogy nézze át a jogosultságokat szerkesztés nélkül: „Kérdés módban sorold fel minden API útvonalat és azt, milyen jogosultsági ellenőrzést végez.”
• /test az ügynök felhasználóként kattint végig az előnézetén — hasznos a 2. szakasz kétfiókos teszthez.
• Ellenőrzőpontok lehetővé teszik, hogy visszagörgessen egy olyan változtatást, amely elrontott valamit.

Lásd a dokumentációban: Biztonság az Ön által épített alkalmazásokban és Környezeti változók és titkok. Ha következőként felhasználói fiókokat ad hozzá, olvassa el a hogyan adjon bejelentkezést az alkalmazásához útmutatót.

Kérdések