XSS turvalisus populaarsetes Javascript raamatukogudes. Kas ma peaksin ikka veel mures olema?

XSS

Me elame raamistike, mitte keelte ajastul. See tähendab, et programmeerijad peaksid saama vähem muretseda paljude arenduse aspektide, sealhulgas turvalisuse pärast. Enamik praegustest backend raamistikest rakendab turvamooduleid, mida testivad välised, spetsialiseerunud ettevõtted ja suured seltsid. Seetõttu, vähenev turvatundlikkus võib ilmneda näiteks noorte programmeerijate vahel, kes võtavad rohkem vastutust toodete eest, eriti vabakutseliste puhul.

Üks levinumaid rünnakuid rakenduse kliendipoolel on XSS (Cross-Site Scripting). See toimub käivitatavate kliendipoolsete skriptide süstimise teel veebirakendustesse [1] ja kasutab rakendatud HTML-redaktsioonimeetodeid või Javascript kood hindajad, kes seda täidavad. XSS on suhteliselt tulutoov, kuna võib koguda palju erinevaid andmeid, sealhulgas seansiküpsiseid või kasutajaandmeid, ning see võib paigaldada jälgimisrakenduse, näiteks keyloggeri, mis muudab selle ohtlikuks nii kasutajatele kui ka ettevõtte omanikele. Mõnikord viiakse läbi ka muid ründeid, et võimaldada XSS-i lehel, näiteks SQL-süstimine.

Näide

Sisselogimise vorm lehel muudab loginName parameeter saata jooksul GET taotluse sisselogimise nimi sisend. Väärtust ei töötle ei server ega rakenduse kliendipoolne osa. Taotluse esitamisel: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
koodi täidetakse ja andmed on avatud

See on näide peegeldunud XSS rünnak, kus skripte sisestatakse ohvrile esitatud ja serveri vastuses kajastatud spetsiaalselt ettevalmistatud URL-aadressi kaudu. Teised tuntud populaarsed ründevormid on järgmised:

• Salvestatud XSS teostatakse serveripoolsete, tavaliselt rakenduses olevate vormide abil salvestatud andmete sisestamisega. Kliendirakendus renderdab koodi, mis on salvestatud näiteks andmebaasi.
• DOM XSS teostab XSS-rünnaku ilma serveripoolset kasutamata. Artikli edasises osas keskendume sellele rünnakuvormile.

Praegused haavatavused React ja Vue raamatukogudes

Praeguste versioonide React/Vue puhul on tuvastatud kaks suuremat probleemi, mida ei ole veel ametlikult parandatud. Esimene haavatavus on iga raamistiku puhul sama iseloomuga ja on seotud meetoditega, mis võimaldavad toor-HTMLi esitamist mallide sees: v-html ja ohtlikultSetInnerHTML, vastavalt Vue ja React. Iga dokumentatsioon [2] teavitab lugejaid sellest, et ebaõige kasutamine võib kasutajaid ohustada XSS-rünnakuga. Kui muud võimalused probleemi lahendamiseks puuduvad, tuleb tagada, et andmed on filtreeritud ja põgenenud. Kuigi need on ohtlikud, ei tohiks eeldada, et need meetodid on fikseeritud. Kasutage neid omal vastutusel.

2018. aasta esimeses kvartalis avastati Reacts suur viga, mis võimaldas otsest koodi täitmist, määrates tag-elemendi omaduse. Näiteks koodi edastamine atribuutide sees, näiteks javascript:alert(1) ja renderdatud lingi käivitamine täidab koodi. See probleem [4] on endiselt lahtine ning parandust ei ole veel ette valmistatud ja ühendatud, seega veenduge, et teie kood on turvaline. Ametlikus arutelus pakutud näited pakuvad mõningaid võimalusi selle probleemi ületamiseks.

Kui uuele versioonile uuendamine ei ole võimalik, veenduge, et vanad probleemid ei tekita teile probleeme, tagades, et teie kood ei ole avatud:

• laps sõlme süstimine - React, kasutamine React.createElement [5]
• serveripoolne renderdamine - React/Vue [6]
• CSS-i süstimine [8]

Tegemist on ikka veel Javascriptiga. See on ikka veel front-end

Ärge unustage, et lisaks raamistikele või raamatukogudele endile on Javascriptil kui keelel ka mõned ohtlikud funktsioonid, mida tuleb vältida või kasutada ettevaatlikult. Need on üldiselt seotud DOM-ga manipuleerimise või skriptide täitmisega. eval() esindab selliseid lipulaevafunktsioone ja on äärmiselt ohtlik, sest see täidab antud stringitud koodi otse [9]. Samuti vaadake oma koodi paremini üle, kui leiate ühe sellise funktsiooni:

• document.write
• document.writeln
• (element).innerHTML
• (element).outerHTML
• (element).insertAdjacentHTML

Siinkohal võib selliste haavatavate punktide leidmisel olla abiks sobivate reeglite kasutamine. Samuti on palju avatud või kommertskoodi analüsaatoreid, mis võivad aidata teil tuvastada turvaauke väljatöötatud koodis.

Olenemata sellest, milline raamatukogu/raamistik on valitud, peame ikkagi meeles pidama esipoole arendamisega seotud põhiprintsiipe. Esiteks, veenduge alati, et väliskood, mida te süstite, pärineb usaldusväärsest allikast. Audit oma sõltuvused ja valige need targalt. Mõned neist võivad sisaldada tõsiseid haavatavusi, mis võivad teie koodi paljastada isegi siis, kui koodis endas on kõik korras. Lisateavet sõltuvuste turvalisuse kohta saate lugeda siit:

https://thecodest.co/blog/security-in-javascript-packages/

Niisiis... kas te peaksite ikka veel mures olema?

Jah - ja ma soovitan kõigile tungivalt, et nad ei usaldaks kunagi väliseid raamatukogusid ega ennast turvalisuse osas. Olenemata sellest, kui turvaliseks te oma tarkvara peate, tehke alati jõupingutusi, et testida seda võimalikult palju tavaliste rünnakuvormide suhtes [10].

1. https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
2. https://vuejs.org/v2/guide/syntax.html#Raw-HTML
3. https://github.com/facebook/react/issues/12441
4. http://danlec.com/blog/xss-via-a-spoofed-react-element
5. https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0
6. https://github.com/dotboris/vuejs-serverside-template-xss
7. https://frontarm.com/james-k-nelson/how-can-i-use-css-in-js-securely/
8. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!

Loe edasi:

5 viga, mida peaksite projekti PHP hooldamisel vältima

PHP arendus. Symfony konsooli komponent - näpunäited ja nipid

Miks me vajame Symfony Polyfill'i (... ja miks me ei peaks seda tegema)