Fantastilised haavatavused ja nende leidmine (1. osa) - saidiülene skriptimine Django vormivigadega

XSS-skriptimise haavatavused

Miks on saitideülene skriptimine (XSS) endiselt kõige levinum veebihaavatavus? XSS tuvastamise teooria on üsna sirgjooneline, selle tuvastamiseks on loodud palju staatilisi analüüsivahendeid ja ometi on avastamata haavatavusi nii palju. Mis siis annab?

Noh, üks põhjusi on see, et traditsioonilised programmi analüüsimeetodid ei suuda sageli tuvastada antud kooditüki eesmärki. Näiteks võib tööriist vaeva näha nuputades, millised programmis olevad objektid võivad sisaldada kasutaja sisestust.

Eelmises postituses kirjeldasin, kuidas me selle probleemiga tegelesime, luues süsteemi, mis õpib tuhandete avatud lähtekoodiga projektide turbespetsifikatsioone ja kasutab neid tõeliste haavatavuste leidmiseks. Lubasin jagada ka lahedaid näiteid õpitu kohta.

Otsustasin Djangot kasutavates projektides alustada huvitava ja üsna ootamatu võimalike probleemide allikaga. See postitus on juhend XSS-i haavatavuste tuvastamiseks ja kasutamiseks, kasutades valideerimisvigu Django vormides. Siin on ehe näide: https://github.com/mozilla/pontoon/pull/1175.

Hüppame otse sinna ja alustame väikese viktoriiniga. Mitu korda olete järgmise lõiguga sarnast koodi kirjutanud / näinud?

Mis sellest saab?

Või see?

Need kõik on laialt levinud näited sellest, kuidas tavaliselt annate kasutajale teada, et sisestatud sisend on vale, eks? Sisend võetakse HTTP päringu parameetritest ja vormistatakse korralikult MyFormi objektiks. Kui mõni väljadest sisaldab valet sisestust (nt keegi sisestas stringi "foobar" numbriväljale), saadetakse 400 vigase päringu leht koos vea kirjeldusega. Katkendite erinevus seisneb tagastatud tõrke vormingus - HTML-loend, lihttekst või JSON.

Nüüd on miljoni dollari küsimus - millised neist lõikudest muudavad teie veebirakenduse XSS-i kasutatavaks?

Sellele vastamiseks uurime Django vormide API-d kahest vaatenurgast:

  1. Kas ründaja saab kasutaja brauseris kuvatavale veebilehele sisestada pahatahtlikku sisendit?
  2. Kas sellest pahatahtlikust sisestusest pääsetakse alati enne kasutajale naasmist alati õigesti?

Django dokumentatsiooni kohaselt on välja valideerimise vigade jaoks dünaamiliste tõrketeadete loomise viis django.core.exmissions.ValidationError erandi lisamine vastava teatega. Vormi valideerimisfunktsioonidest (nt klassi django.forms.BaseForm meetodid clean () ja clean_ () meetoditest vabastatud erand) salvestatakse kiri vormi tõrkesõnastikku (django .forms.utils.ErrorDict) ja hiljem võib-olla ka kasutajale.

Üks viis sellise erandi kasutamiseks on kasutada mõnda sisseehitatud vormivälja, mis kajastab mugavalt eranditeate vigase sisendi. Proovisin kõiki siin loetletud Django vormiväljade tüüpe ja sain järgmise nimekirja: ChoiceField, TypedChoiceField, MultipleChoiceField, FilePathField. Kõik need genereerivad veateate, näiteks "Valige kehtiv valik.% (Väärtus) s ei ole üks võimalikest valikutest.", Kus väärtus on vigane sisend. Win .

Teine võimalus on kohandatud väljade ja / või valideerimisprotseduuride kasutamine. Mõelge näiteks järgmisele katkendile (võetud reaalsest projektist ja lühendatud):

Hea kasulik koormus oleks siin midagi sellist nagu foo. .

Jah, teil on õigus, ainult ValidationErrori erandid ei anna meile XSS-i. Nõuetekohase haavatavuse tagamiseks vajame veel ühte koostisosa - võimalust sisestada tõrketeateid lõplikule HTML-lehele, mis kasutajale tagastatakse.

Ülalnimetatud ErrorDicti klassil on veateadete eraldamiseks järgmised meetodid:

  1. as_data () - puhastus puudub
  2. get_json_data (escape_html = vale) - puhastus puudub, kui escape_html == vale (vaikimisi)
  3. as_json (escape_html = vale) puhastus puudub, kui escape_html == vale (vaikimisi)
  4. as_ul () - ohutu
  5. as_text () - puhastus puudub
  6. __str __ () (kutsub as_ul ()) - turvaline

Läheme tagasi meie väikese viktoriini juurde. On lihtne näha, et katkend 1 on ohutu, kuna see kasutab sisendist pääsevat meetodit __str __ (). Lõigud 2 ja 3 on siiski ohtlikud ja võivad põhjustada XSS-i.

Siin on kaks peamist takeaway sõnumit. Üks arendajate jaoks on mantra “puhastage alati ebausaldusväärne sisend”. Turvateadlaste jaoks on üks: lihtne grep -R "ValidationError" võib teie jaoks rünnakupinda laiendada.

Muide, teil on minu lugupidamine, kui läbisite viktoriini õigesti ilma kogu postitust lugemata.

Veebi- või mobiilirakenduse loomine?

Crowdbotics on kiireim viis rakenduse loomiseks, käivitamiseks ja mõõtmete muutmiseks.

Arendaja? Proovige Crowdbotics App Builderit, et kiiresti tellida ja juurutada mitmesuguste populaarsete raamistikega rakendusi.

Hõivatud või mittetehniline? Liituge sadade õnnelike meeskondade loomise tarkvaraga Crowdbotics peaministrite ja asjatundlike arendajatega. Ulatuse ajakava ja maksumus koos Crowdboticsi hallatava rakenduste arendamisega tasuta.