Fantastične ranljivosti in kje jih najti (1. del) - Skriptnost med spletnimi stranmi z napakami v obliki Django

Ranljive skripte XSS

Zakaj je križanje spletnih strani (XSS) še vedno najpogostejša spletna ranljivost? Teorija prepoznavanja XSS je dokaj enostavna, na voljo je veliko orodij za statično analizo, da bi to odkrili in kljub temu obstaja toliko neodkritih ranljivosti. Kaj torej daje?

No, eden od razlogov je, da tradicionalne metode programske analize pogosto ne prepoznajo namena dane kode. Na primer, orodje se lahko spopada z ugotovitvijo, kateri predmeti v programu lahko vsebujejo uporabniški vnos.

V svoji prejšnji objavi sem opisal, kako smo se tega problema lotili z izgradnjo sistema, ki se uči varnostnih specifikacij iz tisočev projektov odprtokodnih virov in jih uporablja za iskanje resnih ranljivosti. Obljubil sem tudi, da bom delil nekaj kul primerov tega, kar se je naučil.

Odločil sem se za zanimiv in precej nepričakovan vir možnih težav pri projektih, ki uporabljajo Django. Ta objava je vodnik za prepoznavanje in izkoriščanje ranljivosti XSS z uporabo napak za preverjanje veljavnosti v obrazcih Django. Tu je dejanski primer: https://github.com/mozilla/pontoon/pull/1175.

Skočimo naravnost vanjo in začnemo z malo kviza. Kolikokrat ste napisali / videli kodo, podobno spodnjemu delčku?

Kaj pa tale?

Ali pa ta?

Vsi so široko razširjeni primeri, kako uporabniku običajno sporočite, da je vneseni vnos neveljaven, kajne? Vhod se vzame iz parametrov zahteve HTTP in se lepo razdeli v objekt MyForm. Če katero od polj vsebuje neveljaven vnos (npr. Nekdo je v numerično polje vnesel niz "foobar"), se stran s 400 napačnimi zahtevki vrne z opisom napake. Razlika med odrezki je v obliki vrnjene napake - seznam HTML, navadno besedilo ali JSON.

Zdaj vprašanje o milijon dolarjev - kateri od teh odrezkov bo vašo spletno aplikacijo naredil XSSable?

Če želite odgovoriti nanj, preučimo API obrazcev Django z dveh vidikov:

  1. Ali lahko napadalec vpiše zlonamerni vnos na spletno stran, prikazano v uporabnikovem brskalniku?
  2. Ali se bo ta zlonamerni vnos vedno pravilno izognil, preden se vrne uporabniku?

Po dokumentaciji Django je način za gradnjo dinamičnih sporočil o napakah za napake pri preverjanju polja dvig izjeme django.core.exceptions.ValidationError z ustreznim sporočilom. Takšna izjema, vržena s katere koli od potrditvenih funkcij obrazca (npr. Metode clean () in clean_ () razreda django.forms.BaseForm) bo povzročilo, da se sporočilo shrani v slovarju napak obrazca (django .forms.utils.ErrorDict) in pozneje morda prikazana uporabniku.

Eden od načinov za izkoriščanje takšne izjeme je uporaba nekaterih vgrajenih polj obrazca, ki prikladno odražajo napačen vnos v sporočilo o izjemi. Preizkusil sem vse vrste obrazcev Django, navedene tukaj in dobil naslednji seznam: ChoiceField, TypedChoiceField, MultipleChoiceField, FilePathField. Vsak od njih ustvari sporočilo o napaki, kot je "Izberi veljavno izbiro.% (Vrednost) s ne spada med možnosti, ki so na voljo.", Kjer je vrednost napačni vnos. za zmago .

Druga možnost je uporaba polj po meri in / ali postopkov potrjevanja. Na primer, upoštevajte naslednji delček (vzeti iz resničnega projekta in spremenjen zaradi kratkosti):

Tu bi bila dobra koristna obremenitev nekaj podobnega kot foo. .

Da, prav imate, samo izjeme ValidationError nam ne bodo podelile XSS. Za pravilno ranljivost potrebujemo še eno sestavino - zmožnost vbrizgavanja sporočil o napakah v končno stran HTML, ki se vrne uporabniku.

Zgoraj navedeni ErrorDict razred ima naslednje načine za pridobivanje sporočil o napaki:

  1. as_data () - ni saniranja
  2. get_json_data (escape_html = False) - ni sanitarizacije, če escape_html == False (privzeto)
  3. as_json (escape_html = False) ni saniranja, če escape_html == False (privzeto)
  4. as_ul () - varno
  5. as_text () - ni saniranja
  6. __str __ () (kliče as_ul ()) - varno

Vrnimo se k našemu malemu kvizu. Lahko je videti, da je delček 1 varen, saj uporablja metodo __str __ (), ki se izogne ​​vhodu. Izrezki 2 in 3 pa sta nevarni in lahko povzročijo XSS.

Tu sta dve glavni odvzemni sporočili. Tisti za razvijalce je mantra "vedno sanitirati nezaupljiv vložek". Tisti za raziskovalce na področju varnosti je: preprost grep -R "ValidationError" lahko poveča napadalno površino za vas.

Mimogrede, spoštujete, če ste pravilno opravili kviz, ne da bi prebrali celoten prispevek.

Gradite spletno ali mobilno aplikacijo?

Crowdbotics je najhitrejši način za izdelavo, zagon in širjenje aplikacije.

Razvijalec? Preizkusite Crowdbotics App Builder, da hitro oderujete in uporabljate aplikacije z različnimi priljubljenimi okviri.

Zaseden ali netehničen? Pridružite se stotine srečnih timov, ki gradijo programsko opremo s PM-ji Crowdbotics in strokovnimi razvijalci. Obseg časovnice in stroški brezplačno s Crowdbotics Upravljanjem razvoj aplikacij.