XSS-sikkerhed i populære Javascript-biblioteker. Bør jeg stadig være bekymret?

XSS

Vi lever i en tid med frameworks, ikke sprog. Det betyder, at programmører bør være i stand til at bekymre sig mindre om mange aspekter af udviklingen, herunder sikkerhed. Størstedelen af de nuværende backend-frameworks implementerer sikkerhedsmoduler, som bliver testet af eksterne, specialiserede virksomheder og store organisationer. Det er derfor, faldende sikkerhedsbevidsthed kan være tydelig, for eksempel mellem unge programmører, som tager mere ansvar for produkterne, især med hensyn til freelancearbejde.

Et af de mest almindelige angreb på applikationens klientside er XSS (Cross-Site Scripting). Det udføres ved at injicere kørbare scripts på klientsiden i webapplikationer [1] og bruger implementerede HTML-renderingsmetoder eller Javascript Kode evaluatorer, der udfører den. XSS er relativt lukrativt, da der kan indsamles mange forskellige data, herunder sessionscookies eller brugerdata, og det kan installere et sporingsprogram som f.eks. en keylogger, hvilket gør det farligt for både brugere og virksomhedsejere. Nogle gange udføres der andre former for angreb for at tillade XSS på siden, f.eks. SQL-indsprøjtning.

Eksempel

Login-formularen på siden gengiver loginName-parameteren, der sendes i GET-anmodningen, i login-navnets input. Værdien behandles ikke af hverken server- eller klientsiden af applikationen. Ved at anmode: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
kode udføres, og data eksponeres

Dette er et eksempel på en Reflekteret XSS-angrebhvor scripts indsprøjtes via en særligt forberedt URL-adresse, der sendes til offeret og afspejles i serverens svar. Andre kendte populære former for angreb er som følger:

• Gemt XSS udføres med injicerede data, der er gemt på serversiden, normalt ved hjælp af formularer, der er tilgængelige i applikationen. Klientprogrammet gengiver kode, der f.eks. er gemt i en database.
• DOM XSS udfører et XSS-angreb uden brug af serversiden. I den næste del af artiklen vil vi fokusere på denne form for angreb.

Aktuelle sårbarheder i React- og Vue-bibliotekerne

For de nuværende React/Vue-versioner er der fundet to store problemer, som endnu ikke er officielt løst. Den første sårbarhed har samme karakter for alle rammer og er relateret til metoder, der tillader rendering af rå HTML i skabeloner: v-html og farligtSetInnerHTML, henholdsvis for Vue og React. Hver dokumentation [2] informerer læserne om, at uklog brug kan udsætte brugerne for XSS-angreb. Hvis der ikke er andre muligheder for at løse problemet, skal du sikre dig, at dataene er filtreret og undsluppet. Selvom de er farlige, skal du ikke forvente, at disse metoder bliver rettet. Brug dem på egen risiko.

I første kvartal af 2018 blev der opdaget en stor fejl i React, som muliggjorde direkte udførelse af kode ved at indstille egenskaben for tag-elementet. Overførsel af eksempelkode inden for attributter, såsom javascript:alert(1) og at køre et gengivet link vil udføre koden. Dette problem [4] er stadig åbent, og der er ikke udarbejdet og flettet nogen løsning, så sørg for, at din kode er sikker. Eksempler foreslået i den officielle diskussion foreslår nogle måder at overvinde dette problem på.

Hvis det ikke er muligt at opdatere til de nyeste versioner, skal du sørge for, at gamle problemer ikke skaber problemer for dig ved at sikre, at din kode ikke er udsat for:

• barn Knudepunkt Indsprøjtning - React, brug af React.createElement [5]
• Rendering på serversiden - React/Vue [6]
• CSS-indsprøjtning [8]

Det handler stadig om Javascript. Det handler stadig om front-end

Glem ikke, at ud over selve frameworket eller bibliotekerne har Javascript som sprog nogle farlige funktioner, som skal undgås eller bruges med forsigtighed. De er generelt relateret til DOM-manipulation eller script-eksekvering. eval() repræsenterer flagskibsfunktioner af denne art og er ekstremt farlig, fordi den udfører given stringificeret kode direkte [9]. Tag også et bedre kig på din kode, når du finder en af disse funktioner:

• dokument.skriv
• document.writeln
• (element).innerHTML
• (element).outerHTML
• (element).insertAdjacentHTML

Her kan det være nyttigt at bruge linters med et ordentligt regelsæt til at finde sådanne sårbare punkter. Der findes også masser af åbne eller kommercielle kodeanalysatorer, som kan hjælpe dig med at opdage sikkerhedshuller i udviklet kode.

Uanset hvilket bibliotek/framework der vælges, skal vi stadig huske de grundlæggende principper for front-end-udvikling. For det første skal du altid sikre dig, at den eksterne kode, du indsætter, kommer fra en pålidelig kilde. Revision dine afhængigheder, og vælg dem med omhu. Nogle kan indeholde alvorlige sårbarheder, som kan afsløre din kode, selv om alt er i orden med selve koden. Du kan læse mere om afhængigheders sikkerhed her:

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

Så ... bør du stadig være bekymret?

Ja - og jeg vil på det kraftigste opfordre alle til aldrig at stole på eksterne biblioteker eller sig selv, når det gælder sikkerhed. Uanset hvor sikker du forventer, at din software er, skal du altid gøre en indsats for at teste den så meget som muligt med hensyn til almindelige angrebsformer [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!

Læs mere om det:

5 fejl, du bør undgå, når du vedligeholder et projekt i PHP

PHP udvikling. Symfony-konsolkomponent - tips og tricks

Hvorfor har vi brug for Symfony Polyfill (... og hvorfor vi ikke bør)