Listë kontrolli sigurie për aplikacione të ndërtuara me AI: çfarë të kontrollosh para lançimit

Para se njerëzit e vërtetë të përdorin një aplikacion që ke ndërtuar me AI, kontrollo shtatë gjëra: çdo faqe dhe API kontrollon kush është përdoruesi dhe çfarë mund të bëjë; çelësat sekretë jetojnë në server, kurrë në shfletues ose në bisedë; i gjithë inputi validohet në server; çdo përdorues mund të arrijë vetëm regjistrimet e veta; hyrja dhe pikat e kushtueshme kufizohen me kufij kërkesash; varësitë janë të përditësuara; dhe mund të rikthesh të dhënat nëse diçka shkon keq. Lista më poshtë e kthen secilën prej tyre në teste specifike që mund t'i bësh pa lexuar kod.

Ndërtuesit me AI janë të mirë në bërjen e veçorive që funksionojnë. Nuk janë automatikisht të kujdesshëm, sepse "kujdes" rrallë shkruhet në kërkesë. Shumica e problemeve më poshtë vijnë nga gjëra që askush nuk i kërkoi, prandaj zgjidhja zakonisht është ta kërkosh.

Si ta përdorësh këtë listë

Punoje me radhë, dhe për çdo pikë bëj dy gjëra: kërko nga AI të sigurohet që është trajtuar, dhe testoje vetë. AI mund të shkruajë një kontroll lejesh; vetëm një test të tregon që funksionon. Pikat shënohen si:

• Detyrueshme — bëje para se ta përdorë dikush tjetër aplikacionin.
• Duhet — bëje përpara se të kesh përdorues dhe të dhëna reale.
• Më vonë — e vlen të bëhet ndërsa aplikacioni rritet.

Nëse ke vetëm një orë, bëji të gjitha pikat Detyrueshme.

1. Autentikimi: kush je ti?

Autentikimi do të thotë të konfirmosh kush është dikush, zakonisht me hyrje. Shih çfarë është autentikimi për bazat dhe si të shtosh hyrje në aplikacionin tënd për opsionet.

• Detyrueshme: Çdo faqe që shfaq të dhëna private kërkon hyrje. Testi: dil nga llogaria, pastaj ngjit URL-në e një faqe private direkt në shfletues.
• Detyrueshme: Çdo pikë API prapa atyre faqeve kërkon gjithashtu hyrje — jo vetëm faqja. Testi: dil nga llogaria, hap skedën e rrjetit të shfletuesit dhe rijep një kërkesë që aplikacioni bëri ndërsa ishe i hyrë.
• Detyrueshme: Fjalëkalimet ruhen të hashuara me një algoritëm të ngadaltë për hashimin e fjalëkalimeve, kurrë në tekst të thjeshtë. Udhëzimi i OWASP për ruajtjen e fjalëkalimeve rekomandon Argon2id së pari, me scrypt, bcrypt ose PBKDF2 si alternativa. Pyet: "Si ruhen fjalëkalimet?"
• Duhet: Lidhjet e rivendosjes së fjalëkalimit skadojnë dhe funksionojnë vetëm një herë.
• Duhet: Cookie-t e sesionit shënohen si Secure, HttpOnly dhe SameSite, dhe dalja nga llogaria e mbyll sesionin në server.
• Më vonë: Ofro autentikim me dy faktorë, ose hyrje përmes një ofruesi që e ka.

Kontrollo çdo rrugë API dhe çdo faqe që kthen të dhëna përdoruesi. Secila duhet të refuzojë kërkesat nga përdorues që nuk janë hyrë, në server, jo vetëm në kodin e faqes. Listo rrugët që kontrolluar.

2. Autorizimi: çfarë lejohen të bëjnë?

Autorizimi është hapi pas hyrjes: vendos çfarë mund të shohë dhe të ndryshojë ky përdorues i caktuar. Këtu aplikacionet e ndërtuara me AI kanë më shpesh vrima serioze, sepse aplikacioni duket i saktë — paneli i secilit përdorues shfaq vetëm të dhënat e tij — ndërsa serveri do t'i japë me qejf të dhënat e kujtdo nëse i kërkohen drejtpërdrejt.

• Detyrueshme: Çdo lexim, përditësim dhe fshirje kontrollon në server që regjistrimi i përket përdoruesit aktual (ose ekipit të tij).
• Detyrueshme: Testoje: krijo dy llogari, A dhe B. Si A, hap një nga regjistrimet e A dhe shëno ID-në në URL ose në kërkesën e rrjetit. Hyr si B dhe kërko të njëjtën ID. B duhet të marrë një gabim, jo të dhënat e A.
• Detyrueshme: Faqet e administratorit dhe pikat API të administratorit kontrollojnë rolin e përdoruesit në server. Fshehja e lidhjes së administratorit nuk është mbrojtje.
• Detyrueshme: Përdoruesit nuk mund ta ndryshojnë vetë rolin, çmimin, bilancin ose fushat e pronarit duke redaktuar kërkesën. Testi: në skedën e rrjetit, shiko çfarë dërgon një përditësim profili. Nëse përfshin fusha si role ose isAdmin, kërko nga AI t'i injorojë ato nga klienti.
• Duhet: ID-të në URL janë të vështira për t'u hamendësuar (ID të rastësishme, jo 1, 2, 3). Kjo nuk zëvendëson kontrollet e lejeve, por kufizon dëmin kur mungon një.

Për çdo pikë fundore që lexon ose ndryshon një regjistrim, kontrollo në server që përdoruesi i hyrë e zotëron ose ka leje ta aksesojë. Kthe 404 nëse jo. Pastaj më trego si do ta testoje këtë me dy llogari.

3. Aksesi në nivel rreshti në bazën e të dhënave

"Aksesi në nivel rreshti" do të thotë që çdo rresht i një tabele (një rezervim, një faturë) të jetë i dukshëm vetëm për përdoruesit kujt i takon. Ka dy mënyra të zakonshme për ta zbatuar:

Të dyja mund të bëhen mirë. Ajo që ka rëndësi:

• Detyrueshme: Nëse shfletuesi flet drejtpërdrejt me bazën e të dhënave (disa produkte bazash të hostuara e lejojnë këtë), rregullat e nivelit të rreshtit janë të aktivizuara për çdo tabelë. Pa to, kushdo me çelësin publik mund të lexojë gjithë tabelën.
• Detyrueshme: Pyetjet filtrojnë sipas përdoruesit ose ekipit aktual, jo sipas një ID-je që e dërgon shfletuesi.
• Duhet: Të dhënat e përbashkëta (projektet e një ekipi) kanë një rregull të qartë për kush është në ekip, të zbatuar në një vend.

4. Sekretet dhe çelësat API

Një çelës API është një fjalëkalim për një shërbim. Stripe, email-i dhe ofruesit e AI përdorin të gjithë. Për sfond, shih çfarë janë variablat e mjedisit dhe sekretet.

• Detyrueshme: Çelësat ruhen te variablat e mjedisit ose sekretet e projektit, kurrë të shkruar në kod.
• Detyrueshme: Çelësat që mund të shpenzojnë para ose të lexojnë të dhëna private përdoren vetëm në server. Testi: hap site-in tënd live, shiko burimin e faqes dhe skedarët JavaScript në devtools, dhe kërko fillimin e çelësit tënd (për shembull sk_). Nuk duhet të shfaqet.
• Detyrueshme: Çelësat nuk janë ngjitur kurrë në bisedë, në një repozitor publik ose në një pamje ekrani. Nëse ka ndodhur, rrotullo (rotate) atë te ofruesi (krijo një të ri, fshi të vjetrin).
• Duhet: Përdor çelësa të kufizuar ose të caktuar kur ofruesi i ofron. Stripe, për shembull, rekomandon çelësa të kufizuar që kanë vetëm lejet që i duhen integrimit tënd.
• Duhet: Çelësat e testit dhe ata live janë të ndarë, dhe aplikacioni live përdor çelësa live vetëm kur je gati.

Disa çelësa janë projektuar të jenë publikë — çelësi i publikueshëm i Stripe (pk_…) ose një çelës hartash i kufizuar në domenin tënd. Rregulla lidhet me çelësat që japin fuqi, jo me çdo varg që duket si çelës.

5. Validimi i inputit

Çdo gjë që dërgon një përdorues — fusha formularësh, ngarkime skedarësh, parametra URL — mund të jetë çdo gjë, jo vetëm ajo që lejon formulari yt.

• Detyrueshme: Validimi bëhet në server, jo vetëm në shfletues. Kontrollet në shfletues janë për komoditet; kushdo mund t'i anashkalojë.
• Detyrueshme: Pyetjet e bazës së të dhënave përdorin parametra, jo tekst i ngjitur nga inputi i përdoruesit (kjo parandalon SQL injection). Kërko nga AI ta konfirmojë.
• Detyrueshme: Teksti që shkruajnë përdoruesit shfaqet si tekst, jo ekzekutohet si HTML. Testi: shkruaj <b>hello</b> si emrin tënd. Duhet të shohësh etiketat, jo tekst me shkronja të trasha.
• Duhet: Ngarkimet e skedarëve kontrollojnë llojin dhe madhësinë, dhe skedarët e ngarkuar nuk shërbehen nga domeni kryesor i aplikacionit si faqe të ekzekutueshme.
• Duhet: Gabimet që shihen nga përdoruesit janë të thjeshta ("Diçka shkoi keq"); gabimet e detajuara shkojnë vetëm te regjistrat e serverit.
• Duhet: Webhook-ët nga shërbime si Stripe verifikojnë nënshkrimin e ofruesit para se të veprojnë. Shih çfarë është një webhook.

Shto validim në server për çdo formular dhe pikë API: fusha të detyrueshme, gjatësi, formate dhe vlera të lejuara. Refuzo çdo gjë tjetër me një mesazh të qartë. Mos shfaq detaje të brendshme gabimi te përdoruesit.

6. Kufijtë e kërkesave dhe abuzimi

Një kufi kërkesash e kufizon sa kërkesa mund të bëjë dikush brenda një periudhe. Pa to, kushdo mund të hamendësojë fjalëkalime gjithë ditën, të mbushë formularin tënd të regjistrimit, ose të rrisë faturën tënde në një API me pagesë.

• Detyrueshme: Hyrja, regjistrimi dhe rivendosja e fjalëkalimit kufizohen sipas adresës IP dhe sipas llogarisë.
• Detyrueshme: Çdo gjë që të kushton para për thirrje — kërkesa modelesh AI, SMS, email — ka një kufi për përdorues dhe kërkon hyrje.
• Duhet: Formularët publikë (kontakti, lista e pritjes) kanë mbrojtje nga spam-i: një kufi kërkesash, një fushë e fshehur e kurtheve (honeypot), ose një CAPTCHA.
• Duhet: Vendos kufij shpenzimesh ose alarme te ofruesit e tu me pagesë, që një gabim ose një sulmues të mos krijojë një faturë të pakufizuar.

7. Varësitë

Aplikacionet ndërtohen nga paketa me burim të hapur, dhe paketat ndonjëherë kanë cenueshmëri të njohura.

• Duhet: Kërko nga AI të kontrollojë për cenueshmëri të njohura (për projektet JavaScript, npm audit ose ekuivalenti për menaxherin tënd të paketave) dhe të përditësojë ato që preken.
• Duhet: Hiq paketat që aplikacioni nuk i përdor më.
• Duhet: Ki kujdes me paketa që kanë shumë pak përdorues ose emra që duken si gabime shkrimi të atyre të njohura.
• Më vonë: Rikontrollo çdo muaj ose dy, ose aktivizo alarme automatike nëse kodi yt është në GitHub.

8. Kopjet rezervë dhe rikthimi

Siguria përfshin aftësinë për t'u rikthyer nga gabimet — të tuat, të AI-së, ose të një sulmuesi.

• Detyrueshme: Dij ku jetojnë të dhënat e tua dhe nëse ruhen si kopje rezervë. Mos supozo; kontrollo dokumentacionin e hostit tënd.
• Duhet: Mbaj eksportimin tënd periodik të të dhënave të rëndësishme (për shembull, një veçori eksportimi CSV ose një dump i bazës së të dhënave), të ruajtur diku veçmas.
• Duhet: Mbaj kodin tënd në kontroll versionesh, që çdo version të mund të rikthehet.
• Duhet: Veprimet shkatërruese (fshirja e llogarisë, fshirja e projektit) kërkojnë konfirmim, dhe mendo për një "fshirje të butë" që mund të zhbëhet për një kohë.
• Më vonë: Provo në të vërtetë një rikthim një herë. Një kopje rezervë që nuk e ke rikthyer kurrë është një shpresë, jo një plan.

9. Para lançimit

• Detyrueshme: Site-i live përdor HTTPS kudo.
• Detyrueshme: Të dhënat shembull, llogaritë e testit dhe faqet e debug-ut nga zhvillimi janë hequr.
• Duhet: Një politikë privatësie thotë çfarë të dhënash mbledh dhe pse — e kërkuar në shumë vende nëse mblidh të dhëna personale. Mos pretendo certifikime (SOC 2, HIPAA) që nuk i ke.
• Duhet: Ke një mënyrë për t'u kontaktuar për çështje sigurie, dhe di si të rrotullosh çdo çelës shpejt.

Për një kontroll më të gjerë para lançimit, përtej sigurisë, shih si ta çosh një prototip AI në prodhim.

Kur të kërkohet një rishikim profesional

Një listë kontrolli kap gabimet e zakonshme; nuk zëvendëson një ekspert. Mendo të paguash për një rishikim nëse përpunon vetë numrat e kartave në vend të një checkout-i të hostuar, ruan të dhëna shëndetësore, financiare ose të fëmijëve, shet te kompani që kërkojnë pyetësorë sigurie, ose do të dëmtoheshe seriozisht nga një rrjedhje. Që kodi yt të jetë i eksportueshëm e bën rishikimin shumë më të lehtë.

Siguria kur ndërton në Mythex

Mythex nuk ka një panel skanimi sigurie, prandaj lista e mësipërme është procesi që duhet ndjekur. Disa gjëra që ndihmojnë:

• Sekretet e projektit. Ruaj çelësat te cilësimet e projektit → Secrets, ose përmes kartës së sekreteve që agjenti shfaq në bisedë, që të mos shkojnë në kodin dhe mesazhet e tua. Pasi të ndryshosh një sekret për një aplikacion live, publiko përsëri.
• Modalitetet Plan dhe Ask. Kërko nga agjenti të rishikojë lejet pa redaktuar: "Në modalitetin Ask, listo çdo rrugë API dhe çfarë kontrolli leje bën."
• /test e bën agjentin të klikojë në pamjen tënde paraprake si përdorues — i dobishëm për testin me dy llogari në seksionin 2.
• Pikat e kontrollit të lejojnë të kthehesh mbrapsht nga një ndryshim që prishi diçka.

Shih Siguria për aplikacionet që ndërton dhe Variablat e mjedisit dhe sekretet në dokumentacion. Nëse po shton llogari përdoruesish më pas, lexo si të shtosh hyrje në aplikacionin tënd.

Pyetje