Turvakontrollloend AI-ga ehitatud rakendustele: mida kontrollida enne starti

Enne kui päris inimesed AI-ga ehitatud rakendust kasutavad, kontrolli seitset asja: iga leht ja API kontrollib, kes kasutaja on ja mida ta tohib; salajased võtmed elavad serveris, mitte brauseris ega vestluses; kogu sisend valideeritakse serveris; iga kasutaja pääseb ligi ainult oma kirjetele; sisselogimine ja kulukad lõpp-punktid on piiratud; sõltuvused on ajakohased; ja sa saad andmed taastada, kui midagi läheb valesti. Allpool olev kontrollloend muudab need igaühe konkreetseteks testideks, mida saad teha ilma koodi lugemata.

AI-rakenduste ehitajad on head funktsioonide tööle panemisel. Nad ei ole automaatselt hoolikad, sest „hoolikus“ on harva promptis. Enamik allpool kirjeldatud probleeme tuleb asjadest, mida keegi ei nõudnud, seega on parandus tavaliselt see, et küsid.

Kuidas seda kontrollloendit kasutada

Läbi see järjekorras ja iga punkti juures tee kaks asja: küsi AI-lt, et see oleks käsitletud, ja testi ise. AI võib kirjutada õiguste kontrolli; ainult test näitab, et see töötab. Punktid on märgitud:

• Kohustuslik — tee enne, kui keegi teine rakendust kasutab.
• Soovituslik — tee enne, kui sul on päris kasutajad või päris andmed.
• Hiljem — väärt tegemist, kui rakendus kasvab.

Kui sul on ainult tund aega, tee kõik kohustuslikud punktid.

1. Autentimine: kes see on?

Autentimine tähendab, et kinnitatakse, kes keegi on — tavaliselt sisselogimine. Põhitõdede jaoks vaata mis on autentimine ja valikute jaoks kuidas lisada rakendusele sisselogimine.

• Kohustuslik: iga leht, mis näitab privaatseid andmeid, nõuab sisselogimist. Test: logi välja ja kleebi privaatse lehe URL otse brauserisse.
• Kohustuslik: iga API lõpp-punkt nende lehtede taga nõuab samuti sisselogimist — mitte ainult leht. Test: logi välja, ava brauseri võrgu vaade ja proovi uuesti päringut, mida rakendus tegi sisselogituna.
• Kohustuslik: paroolid salvestatakse räsitult aeglase parooliräsi algoritmiga, mitte kunagi tavateksti. OWASP-i paroolide salvestamise juhend soovitab esmalt Argon2id-d, alternatiividena scrypt, bcrypt või PBKDF2. Küsi: „Kuidas paroole salvestatakse?“
• Soovituslik: parooli lähtestamise lingid aeguvad ja töötavad ainult üks kord.
• Soovituslik: sessiooniküpsised on märgitud Secure, HttpOnly ja SameSite ning väljalogimine lõpetab sessiooni serveris.
• Hiljem: paku kaksikautentimist või sisselogimist teenusepakkuja kaudu, millel see on.

Kontrolli iga API marsruuti ja lehte, mis tagastab kasutajaandmeid. Igaüks neist peab tagasi lükkama päringud kasutajatelt, kes ei ole sisse logitud, serveris, mitte ainult lehe koodis. Loetle kontrollitud marsruudid.

2. Autoriseerimine: mida neil on lubatud teha?

Autoriseerimine on sisselogimisele järgnev samm: otsustad, mida see konkreetne kasutaja tohib näha ja muuta. Siin on AI-ga ehitatud rakendustel kõige sagedamini tõsised augud, sest rakendus näeb õige välja — iga kasutaja armatuurlaud näitab ainult tema andmeid — samal ajal kui server annab kellegi andmed kätte, kui neid otse küsida.

• Kohustuslik: iga lugemine, uuendamine ja kustutamine kontrollib serveris, et kirje kuulub praegusele kasutajale (või tema meeskonnale).
• Kohustuslik: testi seda: loo kaks kontot, A ja B. Kasutajana A ava üks A kirje, märgi üles ID URL-ist või võrgupäringust. Logi sisse kasutajana B ja päri sama ID. B peab saama vea, mitte A andmeid.
• Kohustuslik: administraatorilehed ja administraatori API lõpp-punktid kontrollivad kasutaja rolli serveris. Administraatori lingi peitmine ei ole kaitse.
• Kohustuslik: kasutajad ei saa muuta oma rolli, hinda, saldot ega omanikuvälju päringut muutes. Test: võrgu vaates vaata, mida profiili uuendus saadab. Kui seal on väljad nagu role või isAdmin, palu AI-l need kliendipoolelt ignoreerida.
• Soovituslik: URL-ides olevad ID-d on raskesti arvatavad (juhuslikud ID-d, mitte 1, 2, 3). See ei asenda õiguste kontrolli, kuid piirab kahju, kui see puudub.

Iga lõpp-punkti puhul, mis loeb või muudab kirjet, kontrolli serveris, et sisselogitud kasutaja omab kirjet või tal on õigus sellele ligi pääseda. Tagasta 404, kui ei ole. Seejärel näita, kuidas seda kahe kontoga testiks.

3. Rea-tasemel juurdepääs andmebaasis

„Rea-tasemel juurdepääs“ tähendab, et tabeli iga rida (üks broneering, üks arve) on nähtav ainult neile kasutajatele, kellele see kuulub. Selle tagamiseks on kaks levinud viisi:

Mõlemat saab hästi teha. Oluline on:

• Kohustuslik: kui brauser räägib andmebaasiga otse (mõned hostitud andmebaasitooted seda lubavad), on rea-tasemel reeglid sisse lülitatud igas tabelis. Ilma nendeta saab kõik tabelit lugeda, kellel on avalik võti.
• Kohustuslik: päringud filtreerivad praeguse kasutaja või meeskonna järgi, mitte brauseri saadetud ID järgi.
• Soovituslik: jagatud andmetel (meeskonna projektid) on selge reegel, kes on meeskonnas, ja see jõustatakse ühes kohas.

4. Saladused ja API-võtmed

API-võti on teenuse parool. Stripe, e-post ja AI-teenusepakkujad kasutavad kõik neid. Taustaks vaata mis on keskkonnamuutujad ja saladused.

• Kohustuslik: võtmed on salvestatud projekti keskkonnamuutujatesse või saladustesse, mitte kunagi kirjutatud koodi.
• Kohustuslik: võtmeid, mis suudavad raha kulutada või privaatseid andmeid lugeda, kasutatakse ainult serveris. Test: ava oma elav sait, vaata lehe lähtekoodi ja JavaScripti faile arendajatööriistades ning otsi võtme algust (näiteks sk_). Seda ei tohi seal olla.
• Kohustuslik: võtmeid ei ole kunagi kleebitud vestlusse, avalikku hoidlasse ega ekraanipildile. Kui on, vaheta see teenusepakkujas (loo uus, kustuta vana).
• Soovituslik: kus pakkuja seda võimaldab, kasuta piiratud või piiritletud võtmeid. Stripe soovitab näiteks piiratud võtmeid, millel on ainult integratsiooniks vajalikud õigused.
• Soovituslik: testimis- ja päris võtmed on eraldi ning päris rakendus kasutab päris võtmeid ainult siis, kui oled valmis.

Mõned võtmed on mõeldud avalikuks — Stripe'i avalik võti (pk_…) või kaardivõti, mis on piiratud sinu domeeniga. Reegel puudutab võtmeid, mis annavad võimu, mitte iga stringi, mis võtmena välja näeb.

5. Sisendi valideerimine

Mida iganes kasutaja saadab — vormiväljad, failide üleslaadimised, URL-i parameetrid — see võib olla mis tahes, mitte ainult see, mida su vorm lubab.

• Kohustuslik: valideerimine toimub serveris, mitte ainult brauseris. Brauseri kontrollid on mugavuse jaoks; igaüks saab neist mööda minna.
• Kohustuslik: andmebaasi päringud kasutavad parameetreid, mitte kasutajasisendist kokkukleebitud teksti (see takistab SQL-süsti). Palu AI-l seda kinnitada.
• Kohustuslik: kasutajate sisestatud tekst kuvatakse tekstina, mitte ei käivitu HTML-ina. Test: sisesta oma nimeks <b>tere</b>. Peaksid nägema silte, mitte paksu teksti.
• Soovituslik: failide üleslaadimised kontrollivad tüüpi ja suurust ning üleslaaditud faile ei serveerita sinu rakenduse põhidomeenilt käivitatavate lehtedena.
• Soovituslik: kasutajatele kuvatavad vead on lihtsad („Midagi läks valesti“); üksikasjalikud vead lähevad ainult serveri logidesse.
• Soovituslik: teenustest nagu Stripe tulevad webhook'id kontrollivad teenusepakkuja allkirja enne tegutsemist. Vaata mis on webhook.

Lisa serveripoolne valideerimine igale vormile ja API lõpp-punktile: kohustuslikud väljad, pikkused, vormingud ja lubatud väärtused. Lükka kõik muu tagasi selge teatega. Ära näita kasutajatele sisemisi veadetaile.

6. Piirangud ja kuritarvitus

Piirang määrab, kui palju päringuid keegi võib perioodi jooksul teha. Ilma selleta võib keegi kogu päeva paroole arvata, registreerimisvormi üle ujutada või tasulise API arve üles ajada.

• Kohustuslik: sisselogimine, registreerimine ja parooli lähtestamine on piiratud IP-aadressi ja konto kaupa.
• Kohustuslik: kõik, mis maksab sulle iga kõne eest — AI-mudelite päringud, SMS, e-post — on piiratud kasutaja kaupa ja nõuab sisselogimist.
• Soovituslik: avalikel vormidel (kontakt, ootenimekiri) on rämpsposti kaitse: piirang, peidetud lõks-väli või CAPTCHA.
• Soovituslik: sea oma tasulistes teenustes kulupiirangud või hoiatused, et viga või ründaja ei saaks tekitada piiramatut arvet.

7. Sõltuvused

Rakendused on ehitatud avatud lähtekoodiga paketidest ja paketidel on mõnikord teadaolevad haavatavused.

• Soovituslik: palu AI-l kontrollida teadaolevaid haavatavusi (JavaScripti projektide puhul npm audit või sinu paketihalduri vastav käsk) ja uuendada mõjutatud pakette.
• Soovituslik: eemalda paketid, mida rakendus enam ei kasuta.
• Soovituslik: ettevaatlik ole paketidega, millel on väga vähe kasutajaid või mille nimed meenutavad populaarsete pakettide kirjavigu.
• Hiljem: kontrolli iga kuu või paari kuu tagant või lülita sisse automaatsed hoiatused, kui su kood on GitHubis.

8. Varundused ja taastamine

Turvalisus hõlmab võimet taastuda vigadest — nii sinu, AI oma kui ründaja omadest.

• Kohustuslik: tea, kus su andmed asuvad ja kas neist tehakse varukoopiat. Ära eelda; kontrolli oma hostimisteenuse dokumentatsioonist.
• Soovituslik: hoia oma regulaarset väljavõtet olulistest andmetest (näiteks CSV-eksport või andmebaasi väljavõte) eraldi kohas.
• Soovituslik: hoia oma kood versioonihalduses, et igat versiooni saaks taastada.
• Soovituslik: hävitavad toimingud (konto kustutamine, projekti kustutamine) nõuavad kinnitust ning kaalu „pehmet kustutamist“, mida saab mõnda aega tagasi võtta.
• Hiljem: testi taastamist vähemalt üks kord. Varukoopia, mida pole kunagi taastatud, on lootus, mitte plaan.

9. Enne starti

• Kohustuslik: päris sait kasutab kõikjal HTTPS-i.
• Kohustuslik: arenduse näidisandmed, testikontod ja silumislehed on eemaldatud.
• Soovituslik: privaatsuspoliitika ütleb, milliseid andmeid kogud ja miks — paljudes kohtades nõutav, kui kogud isikuandmeid. Ära väida sertifikaate (SOC 2, HIPAA), mida sul pole.
• Soovituslik: sul on viis, kuidas sind turvaprobleemidest teavitada, ja tead, kuidas kiiresti iga võtme vahetada.

Laiema eelstarditõendi jaoks, mis ulatub turvalisusest kaugemale, vaata kuidas viia AI-prototüüp tootmisse.

Millal lasta teha professionaalne ülevaatus

Kontrollloend püüab tavalisi vigu; see ei asenda eksperti. Kaalu ülevaatuse eest maksmist, kui töötled kaardinumbreid ise, mitte hostitud makse kaudu, hoiad tervise-, finants- või laste andmeid, müüd ettevõtetele, kes nõuavad turvaküsimustikke, või võiksid lekke korral tõsiselt kahju saada. Kui sinu kood on eksporditav, on ülevaatus palju lihtsam.

Turvalisus Mythexiga ehitamisel

Mythex ei sisalda turvaskannimise paneeli, seega on protsessiks ülal olev kontrollloend. Mõned asjad aitavad:

• Projekti saladused. Salvesta võtmed projekti seadete → saladuste alla või agendi vestluses näidatava saladuste kaardi kaudu, et need jääksid koodist ja sõnumitest välja. Pärast saladuse muutmist elavas rakenduses avalda uuesti.
• Plaani- ja küsimisrežiimid. Palu agendil õigusi üle vaadata ilma muutmata: „Küsimisrežiimis loetle iga API marsruut ja selle õiguskontroll.“
• /test laseb agendil klõpsata läbi su eelvaate kasutajana — kasulik kahe konto testiks 2. jaotisest.
• Kontrollpunktid lasevad sul tagasi võtta muudatuse, mis midagi katkestas.

Vaata Turvalisus sinu ehitatud rakendustele ja Keskkonnamuutujad ja saladused dokumentatsioonis. Kui lisad järgmisena kasutajakontod, loe kuidas lisada rakendusele sisselogimine.

Küsimused