Drošības kontrolsaraksts AI veidotām lietotnēm: ko pārbaudīt pirms palaišanas

Pirms reāli cilvēki lieto lietotni, ko esat veidojis ar AI, pārbaudiet septiņas lietas: katra lapa un API pārbauda, kas lietotājs ir un ko viņš drīkst; slepenās atslēgas atrodas serverī, nekad pārlūkprogrammā vai tērzēšanā; visa ievade tiek pārbaudīta serverī; katrs lietotājs var piekļūt tikai saviem ierakstiem; pieteikšanās un dārgie galapunkti ir ierobežoti pēc pieprasījumu skaita; atkarības ir atjauninātas; un jūs varat atjaunot datus, ja kaut kas noiet greizi. Tālāk kontrolsaraksts katru no tiem pārvērš konkrētos testos, ko var veikt, nelasot kodu.

AI lietotņu veidotāji labi spēj padarīt funkcijas darbīgas. Tie paši par sevi nav piesardzīgi, jo „piesardzība” reti ir uzdevumā. Lielākā daļa tālāk aprakstīto problēmu rodas lietās, ko neviens nav pieprasījis, tāpēc labojums parasti ir pieprasīt.

Kā izmantot šo kontrolsarakstu

Izejiet cauri tam pēc kārtas un katram vienumam izdariet divas lietas: pajautājiet AI, lai pārliecinātos, ka tas ir risināts, un pārbaudiet pats. AI var uzrakstīt atļauju pārbaudi; tikai tests parāda, ka tā darbojas. Vienumi ir atzīmēti:

• Obligāti — izdariet pirms tam, kad lietotni izmanto kāds cits.
• Vajadzētu — izdariet, pirms jums ir reāli lietotāji vai reāli dati.
• Vēlāk — vērts izdarīt, lietotnei augot.

Ja jums ir tikai stunda, izdariet visus Obligātos.

1. Autentifikācija: kas tas ir?

Autentifikācija nozīmē apstiprināt, kas ir cilvēks — parasti pieteikšanos. Pamatiem skatiet kas ir autentifikācija, bet iespējām skatiet kā pievienot pieteikšanos savai lietotnei.

• Obligāti: Katra lapa, kas rāda privātus datus, prasa pieteikšanos. Tests: izrakstieties un ielīmējiet privātas lapas URL tieši pārlūkprogrammā.
• Obligāti: Katrs API galapunkts aiz šīm lapām arī prasa pieteikšanos — ne tikai lapa. Tests: izrakstieties, atveriet pārlūkprogrammas tīkla cilni un atkārtojiet pieprasījumu, ko lietotne veica, kamēr bijāt pieteicies.
• Obligāti: Paroles glabājas sajauktas ar lēnu paroļu sajaukšanas algoritmu, nekad vienkāršā tekstā. OWASP paroļu glabāšanas vadlīnijas iesaka vispirms Argon2id, ar scrypt, bcrypt vai PBKDF2 kā alternatīvām. Pajautājiet: „Kā tiek glabātas paroles?”
• Vajadzētu: Paroles atjaunošanas saites beidzas un darbojas tikai vienreiz.
• Vajadzētu: Sesijas sīkfaili ir atzīmēti kā Secure, HttpOnly un SameSite, un izrakstīšanās beidz sesiju serverī.
• Vēlāk: Piedāvājiet divfaktoru autentifikāciju vai pieteikšanos caur pakalpojumu sniedzēju, kuram tā ir.

Pārbaudiet katru API maršrutu un lapu, kas atgriež lietotāja datus. Katram no tiem serverī jānoraida pieprasījumi no lietotājiem, kas nav pieteikušies, ne tikai lapas kodā. Uzskaitiet maršrutus, ko pārbaudījāt.

2. Autorizācija: ko viņi drīkst darīt?

Autorizācija ir solis pēc pieteikšanās: lēmums, ko šis konkrētais lietotājs drīkst redzēt un mainīt. Šeit AI veidotām lietotnēm visbiežāk ir nopietni caurumi, jo lietotne izskatās pareizi — katra lietotāja informācijas panelis rāda tikai viņa datus —, bet serveris labprāt izsniegs jebkura datus, ja tos tieši pieprasīs.

• Obligāti: Katrs lasīšanas, atjaunināšanas un dzēšanas darbība serverī pārbauda, ka ieraksts pieder pašreizējam lietotājam (vai viņa komandai).
• Obligāti: Pārbaudiet to: izveidojiet divus kontus, A un B. Kā A atveriet vienu no A ierakstiem un ievērojiet ID URL adresē vai tīkla pieprasījumā. Pieteikieties kā B un pieprasiet to pašu ID. B jāsaņem kļūda, nevis A dati.
• Obligāti: Administratora lapas un administratora API galapunkti serverī pārbauda lietotāja lomu. Administratora saites paslēpšana nav aizsardzība.
• Obligāti: Lietotāji nevar mainīt savu lomu, cenu, atlikumu vai īpašnieka laukus, rediģējot pieprasījumu. Tests: tīkla cilnē apskatiet, ko nosūta profila atjaunināšana. Ja tajā ir tādi lauki kā role vai isAdmin, pajautājiet AI tos ignorēt no klienta puses.
• Vajadzētu: ID URL adresēs ir grūti uzminami (nejauši ID, nevis 1, 2, 3). Tas nav atļauju pārbaužu aizstājējs, bet ierobežo kaitējumu, ja kāda trūkst.

Katram galapunktam, kas lasa vai maina ierakstu, pārbaudiet serverī, ka pieteikušais lietotājs to pieder vai drīkst piekļūt. Ja nē, atgrieziet 404. Pēc tam parādiet, kā to pārbaudītu ar diviem kontiem.

3. Rindu līmeņa piekļuve datubāzē

„Rindu līmeņa piekļuve” nozīmē, ka katra tabulas rinda (viena rezervācija, viens rēķins) ir redzama tikai tiem lietotājiem, kam tā pieder. Ir divi biežākie veidi, kā to nodrošināt:

Abas var izdarīt labi. Svarīgi ir:

• Obligāti: Ja pārlūkprogramma sarunājas ar datubāzi tieši (dažas hostētas datubāzu platformas to ļauj), rindu līmeņa noteikumi ir ieslēgti katrai tabulai. Bez tiem jebkurš ar publisko atslēgu var nolasīt visu tabulu.
• Obligāti: Vaicājumi filtrē pēc pašreizējā lietotāja vai komandas, nevis pēc ID, ko nosūta pārlūkprogramma.
• Vajadzētu: Kopīgiem datiem (komandas projektiem) ir skaidrs noteikums, kas ir komandā, un tas tiek nodrošināts vienuviet.

4. Noslēpumi un API atslēgas

API atslēga ir parole pakalpojumam. Stripe, e-pasts un AI pakalpojumu sniedzēji visi tās izmanto. Pamatiem skatiet kas ir vides mainīgie un noslēpumi.

• Obligāti: Atslēgas glabājas projekta vides mainīgajos vai noslēpumos, nekad nav ierakstītas kodā.
• Obligāti: Atslēgas, ar kurām var tērēt naudu vai lasīt privātus datus, tiek izmantotas tikai serverī. Tests: atveriet savu dzīvo vietni, apskatiet lapas avotu un JavaScript failus izstrādātāju rīkos un meklējiet atslēgas sākumu (piemēram, sk_). Tai nevajadzētu parādīties.
• Obligāti: Atslēgas nekad nav ielīmētas tērzēšanā, publiskā repozitorijā vai ekrānuzņēmumā. Ja tā bija, nomainiet to pie pakalpojumu sniedzēja (izveidojiet jaunu un dzēsiet veco).
• Vajadzētu: Izmantojiet ierobežotas vai aprobežotas atslēgas, kur pakalpojumu sniedzējs to piedāvā. Stripe, piemēram, iesaka ierobežotas atslēgas, kurām ir tikai integrācijai nepieciešamās atļaujas.
• Vajadzētu: Testa un dzīvās atslēgas ir atdalītas, un dzīvā lietotne izmanto dzīvās atslēgas tikai tad, kad esat gatavs.

Dažas atslēgas ir paredzētas publiskai lietošanai — Stripe publiskā atslēga (pk_…) vai kartes atslēga, kas ierobežota uz jūsu domēnu. Noteikums attiecas uz atslēgām, kas piešķir varu, nevis uz katru virkni, kas izskatās pēc atslēgas.

5. Ievades pārbaude

Jebkas, ko lietotājs nosūta — veidlapas lauki, failu augšupielādes, URL parametri —, var būt jebkas, ne tikai tas, ko jūsu veidlapa atļauj.

• Obligāti: Pārbaude notiek serverī, ne tikai pārlūkprogrammā. Pārlūkprogrammas pārbaudes ir ērtībai; ikviens tās var apiet.
• Obligāti: Datubāzes vaicājumi izmanto parametrus, nevis lietotāja ievadi, kas savienota ar tekstu (tas novērš SQL injekciju). Pajautājiet AI, lai apstiprina.
• Obligāti: Lietotāju ievadīts teksts tiek rādīts kā teksts, nevis izpildīts kā HTML. Tests: ievadiet <b>sveiks</b> kā savu vārdu. Jums jāredz tagi, nevis treknraksts.
• Vajadzētu: Failu augšupielādes pārbauda tipu un izmēru, un augšupielādētie faili netiek pasniegti no jūsu lietotnes galvenā domēna kā izpildāmas lapas.
• Vajadzētu: Kļūdas, kas tiek rādītas lietotājiem, ir vienkāršas („Radās kļūda”); detalizētas kļūdas iet tikai serveru žurnālos.
• Vajadzētu: Webhooks no tādiem pakalpojumiem kā Stripe pārbauda pakalpojumu sniedzēja parakstu, pirms rīkojas. Skatiet kas ir webhook.

Pievienojiet servera puses pārbaudi katrai veidlapai un API galapunktam: obligātie lauki, garumi, formāti un atļautās vērtības. Noraidiet visu citu ar skaidru paziņojumu. Neparādiet lietotājiem iekšējās kļūdu detaļas.

6. Pieprasījumu ierobežojumi un ļaunprātīga izmantošana

Pieprasījumu ierobežojums ierobežo, cik pieprasījumus kāds var izdarīt noteiktā laika periodā. Bez tiem jebkurš var visu dienu mēģināt uzminēt paroles, pārpludināt jūsu reģistrācijas veidlapu vai palielināt jūsu rēķinu maksas API.

• Obligāti: Pieteikšanās, reģistrācija un paroles atjaunošana ir ierobežota pēc IP adreses un pēc konta.
• Obligāti: Jebkas, kas jums maksā par katru izsaukumu — AI modeļu pieprasījumi, SMS, e-pasts —, ir ierobežots katram lietotājam un prasa pieteikšanos.
• Vajadzētu: Publiskām veidlapām (kontakti, saraksts gaidītājiem) ir aizsardzība pret surogātpastu: pieprasījumu ierobežojums, paslēpts lauks vai CAPTCHA.
• Vajadzētu: Iestatiet tēriņu ierobežojumus vai brīdinājumus pie maksas pakalpojumu sniedzējiem, lai kļūda vai uzbrucējs nevarētu radīt neierobežotu rēķinu.

7. Atkarības

Lietotnes veido no atvērtā koda pakotnēm, un pakotnēm dažkārt ir zināmas ievainojamības.

• Vajadzētu: Pajautājiet AI pārbaudīt zināmas ievainojamības (JavaScript projektiem npm audit vai tā ekvivalentu jūsu pakotņu pārvaldniekam) un atjaunināt skartās.
• Vajadzētu: Noņemiet pakotnes, ko lietotne vairs neizmanto.
• Vajadzētu: Esiet piesardzīgi ar pakotnēm ar ļoti maz lietotājiem vai nosaukumiem, kas izskatās pēc populāru pakotņu drukas kļūdām.
• Vēlāk: Pārbaudiet ik pēc mēneša vai diviem vai ieslēdziet automātiskus brīdinājumus, ja jūsu kods ir GitHub.

8. Dublējumi un atjaunošana

Drošība ietver spēju atgūties pēc kļūdām — jūsu, AI vai uzbrucēja.

• Obligāti: Zināt, kur atrodas jūsu dati un vai tie ir dublēti. Nepieņemiet; pārbaudiet sava hostinga dokumentāciju.
• Vajadzētu: Turiet savu periodisku svarīgo datu eksportu (piemēram, CSV eksporta funkciju vai datubāzes izgāzumu), kas glabājas atsevišķi.
• Vajadzētu: Turiet kodu versiju kontrolē, lai jebkuru versiju varētu atjaunot.
• Vajadzētu: Destruktīvas darbības (konta dzēšana, projekta dzēšana) prasa apstiprinājumu, un apsveriet „mīkstu dzēšanu”, ko var atsaukt noteiktu laiku.
• Vēlāk: Reiz patiešām pārbaudiet atjaunošanu. Dublējums, ko nekad neesat atjaunojis, ir cerība, nevis plāns.

9. Pirms palaišanas

• Obligāti: Dzīvā vietne visur izmanto HTTPS.
• Obligāti: Izstrādes paraugdati, testa konti un atkļūdošanas lapas ir noņemtas.
• Vajadzētu: Privātuma politika apraksta, kādus datus vācat un kāpēc — daudzviet tas ir obligāti, ja vācat personas datus. Nepieminiet sertifikātus (SOC 2, HIPAA), kādu jums nav.
• Vajadzētu: Jums ir veids, kā ar jums sazināties par drošības jautājumiem, un jūs zināt, kā ātri nomainīt katru atslēgu.

Plašākai pirmspalaišanas pārbaudei ārpus drošības skatiet kā no AI prototipa nonākt līdz ražošanai.

Kad vajadzīga profesionāla pārbaude

Kontrolsaraksts noķer biežākās kļūdas; tas neaizstāj ekspertu. Apsveriet maksu par pārbaudi, ja kartes numurus apstrādājat paši, nevis caur hostētu norēķinu lapu, glabājat veselības, finanšu vai bērnu datus, pārdodat uzņēmumiem, kas prasa drošības anketas, vai noplūde jums nopietni kaitētu. Ja jūsu kodu var eksportēt, šī pārbaude ir daudz vieglāka.

Drošība, veidojot uz Mythex

Mythex nav iekļauta drošības skenēšanas panelis, tāpēc process ir tas, ko sekot iepriekš minētajam kontrolsarakstam. Dažas lietas, kas palīdz:

• Projekta noslēpumi. Glabājiet atslēgas zem projekta iestatījumiem → Noslēpumi vai caur noslēpumu kartīti, ko aģents rāda tērzēšanā, lai tās paliktu ārpus jūsu koda un ziņojumiem. Pēc noslēpuma maiņas dzīvai lietotnei publicējiet vēlreiz.
• Plānošanas un jautāšanas režīmi. Lūdziet aģentu pārskatīt atļaujas, neko nerediģējot: „Jautāšanas režīmā uzskaiti katru API maršrutu un to, kādu atļauju pārbaudi tas veic.”
• /test liek aģentam noklikšķināt caur jūsu priekšskatījumu kā lietotājam — noderīgi divu kontu testam 2. sadaļā.
• Kontrolpunkti ļauj atgriezt izmaiņu, kas kaut ko salauza.

Skatiet Drošība lietotnēm, ko veidojat un Vides mainīgie un noslēpumi dokumentācijā. Ja tālāk pievienojat lietotāju kontus, izlasiet kā pievienot pieteikšanos savai lietotnei.

Jautājumi