Mozilla beschermt Firefox tegen aanvallen via about:pagina's
Mozilla heeft extra maatregelen genomen om Firefox-gebruikers te beschermen tegen injectieaanvallen via de about-pagina's van de browser en andere manieren. Firefox beschikt over verschillende "ingebouwde" pagina's waarmee gebruikers allerlei zaken kunnen instellen of bekijken.
Het gaat dan bijvoorbeeld om pagina's als about:addons, about:config en about:downloads voor respectievelijk het beheer van add-ons, het aanpassen van de browserconfiguratie en het weergeven van alle downloads. Deze about:pagina's zijn ook via html en JavaScript geïmplementeerd en zijn onderhevig aan hetzelfde beveiligingsmodel als normale webpagina's en daardoor niet immuun voor aanvallen waarbij er code in de browser wordt geïnjecteerd.
Als een aanvaller erin zou slagen om code op een about:pagina te injecteren zou de code binnen de beveiligingscontext van de browser worden uitgevoerd, waardoor de aanvaller willekeurige acties in naam van de gebruiker kan uitvoeren. Om gebruikers hier tegen te beschermen en een aanvullende beveiligingslaag aan Firefox toe te voegen heeft Mozilla voor alle 45 about:pagina's alle inline JavaScript-code naar losse bestanden verplaatst en alle inline event handlers herschreven. Een event handler is een routine die invoer verwerkt.
Door het herschrijven van de code kan er nu een Content Security Policy (CSP) worden toegepast waardoor geïnjecteerde JavaScriptcode niet wordt uitgevoerd. JavaScriptcode wordt nu alleen nog uitgevoerd uit een los bestand via een intern protocol. "Het niet toestaan van inline scripts in de about:pagina's verkleint het aanvalsoppervlak om willekeurige code uit te voeren en biedt daardoor een sterke eerste verdedigingslinie tegen injectieaanvallen", zegt Mozillas Christoph Kerschbaumer.
Verder heeft Mozilla maatregelen genomen om eval-achtige functies te verwijderen. Deze functie voert een willekeurige string uit in dezelfde beveiligingscontext als zichzelf. Hierdoor kan in runtime gegenereerde code of code in non-scriptlocaties worden uitgevoerd. Een nadeel is dat het volgens Mozilla ook een groot aanvalsoppervlak voor injectieaanvallen introduceert. Daarom raadt de browserontwikkelaar het gebruik ervan af. Zelf heeft Mozilla alle eval-achtige functies herschreven zodat de functie niet meer in system-privileged scriptcontexts worden uitgevoerd.
goede actie van Mozilla bladeraar development.
Maar ....... hoeveel websites bestaan er niet zonder maar 1 enkele CSP implementatie?
Kijk maar eens op het kaartje hier https://www.immuniweb.com/websec/
De browser kan dan wel steeds veiliger worden, websites lopen nog heel wat achter,
waar het best security policy implementatie betreft.
Hier op de site, waarop ik deze posting schrijf, komen we ook niet verder dan een D-tje voor de header-security:
https://securityheaders.com/?q=security.nl&followRedirects=on
Ook de website van security.nl staat dus bloot aan bedreigingen (MiM aanvallen o.a.):
https://webscan.upguard.com/#/security.nl , waarvan akte.
Men kan zelf, als browser eindgebruiker, ook wel het een en ander doen,
o.a. door het (gedeeltelijk) blokkeren van JavaScript etc. via een extensie als uMatrix bijvoorbeeld.
Voor Mozilla was er vanouds Giorgio Maone's No Script.
Wel even kijken om een balans te vinden tussen de minimale toestemming
voor het goed functioneren van de website en het blokkeren van alle 3rd party scripts bijvoorbeeld.
Maar hiervoor is bij uMatrix echt geen "power user rocket science" nodig.
Overigens met JavaScript beveiliging blijft het een ongelijke strijd tussen beveiliger en aanvaller.
De beveiliger moet alles over de hele linie beveiligen,
de kwaadwillende hacker heeft vaak aan een enkel klein gaatje om doorheen te wurmen genoeg,
al is het na een honderste parameter, als dat niet uitgestest zou zijn.
Maar ja als beveiliger moet je we wat te doen houden, toch?
De schoorsteen moet roken bij ons en er moeten oliebollen op tafel komen.
luntrus
Ik geef Netscape de schuld.
Met sources als: inner.HTML, e.parent, name, sessinStorage, location.pathname, offset.top
en sinks als: href=, "data", var value, scr, leveren als kwetsbaarheid mogelijk DOM-XSS gevaar op,
een mogelijke aanvaller heeft aan een klein code-gaatje genoeg om zijn slag te slaan.
Veiligheid moet van twee kanten komen op de browser, maar ook op de webpagina/webserver,
daar schort nogal wat aan.
luntrus
Veiligheid moet van twee kanten komen op de browser, maar ook op de webpagina/webserver,
daar schort nogal wat aan.
Dat heb je volgens mij toch vooral als ironische opmerking bedoeld.
Ik weet uit de wereld der opleidingen dat er te weinig aandacht voor is.
JavaScript dat doe je in het eerste jaar maar op eigen houtje.
Kregen die tweede jaars ook nog eens op de HBO een jaar security les uit het verkeerde txt-boek.
Ik stond erbij als proctor en ik keek ernaar.
Trouwens, het wordt je ook niet in dank afgenomen, als je er iets van zegt.
Dat de schoornsteen voor hen, de staarten met een apple, moet blijven branden
en ze weinig tijd krijgen voor het nalopen van de veiligheid op hun ontwerpen is bekend.
Mwah, gecompileerde code heeft natuurlijk de voorkeur boven de alternatieven.
Ook dat de eigenaars van de websites, die overigens nergens verstand van hoeven te hebben,
veiligheid als een "last resort issue" beschouwen en er liever geen geld aan spenderen,
is ook bekend. Dus liever een gelikte site dan een veilige.
Daarom zo weinig best practices, zo weinig geimplementeerde header security, geen DNSSEC, etc. etc.
Mozilla en Chrome developers kunnen doen wat ze willen,
aan de andere kant, die van de website developers, moet men ook eens het licht gaan zien.
Niet te snel overigens en niet al te grondig graag, want jij, MathFox en ondergetekende,
houden ook graag wat te doen over. Maar daar zit ik niet zo over in.
luntrus
Ik zie teveel onveilige praktijken bij de bouwers van websites... Wat te denken van (Javascript) bibliotheken die zonder controle van andere websites gehaald worden. Perfecte aanvalsbron om creditcard gegevens mee te stelen!
Ik ben blij dat webbrowsers een sandbox hebben en dat Debian de webbrowser weer in AppArmor draait.
Met websitebouwers ben ik de ironie ver voorbij.
Goed, dan zitten we denk ik helemaal op dezelfde golflengte. ;)
Wat je noemt, het veredelde knip- en plakwerk, hetwelk een groot risico voor ieders veiligheid kan inhouden.
Denk ook eens in dit verband aan "verlaten" code en wat je daarmee voor risico's kan lopen.
Plus ga.js van google-analytics zonder toegevoegde security op de website.
Heb je daar bijvoorbeeld een werkende exploit, dan ben je gelijk criminele spekkoper, hoor.
Dan moet het ook nog eens een keer allemaal over een veilige webserver,
dus eentje zonder Poodle over TLS, zonder Goldendoodle, zonder Zombie Poodle, zonder Sleeping Poodle,
zonder Open SSLL padding Oracle flaw, zonder ROBOT, zonder Heartbleed, zonder Open SSL CSS flaw
om maar eens wat op te noemen.
luntrus
Die persoon bij Netscape Corp. heette Brendan Eich.
https://en.wikipedia.org/wiki/Brendan_Eich
Hij stond tevens, veel later weer, ook nog aan de wieg van de Brave browser.
We kunnen de fiasco's rond JavaScript hem niet persoonlijk aanrekenen,
dat men toch vaak nalaat de code zeer nauwgezet op allerhande zwakheden door te spitten.
JavaScript was aanvankelijk nog niet klaar voor het gebruik naast HTML.
Dat heeft Eich ook ruiterlijk toegegeven. Of dat ooit nog goedkomt?
Er kan wel wat gedaan worden, doorspitten, scannen, linten, fuzzen.
Wie hebben er hier allemaal Retire.JS draaien in de browser?
Wie scannen er online met de scanner van de Noor, Erlend Oftedal, op af te voeren JQuery bibliotheken:
@ retire.insecurity.today/# ? Ook SNYK geeft JQuery library zwakheden aan.
Met JavaScript kan veel, maar je kunt er ook een spreekwoordelijke "wormendoos" mee openen.
Waar hele draden over zijn gevuld bij Stack Overflow.
Lees dit artikel maar eens:
https://www.zdnet.com/article/an-insecure-mess-how-flawed-javascript-is-turning-web-into-a-hackers-playground/
Toen men meer dan 133.000 websites had onderzocht,
bleek dat er op 37 percent daarvan tenminste zich 1 JavaScript bibliotheek bevond
met tenminste een bekende kwetsbaarheid.
luntrus
Met de --private optie wordt door de firejail sandbox een namaak "/root", en een lege huls als schijnbare "/home/user" directory, in een restrictief en tijdelijk tmpfs filesysteem aangemaakt. Dit werkt onder vrijwel alle Linux systemen.
Met JavaScript gefabriceerde payloads kunnen binnen zo'n firejail weinig uitrichten. Zodra de sandbox wordt afgesloten wordt het tmpfs, met alle eventuele wijzigingen en vreemde download bestanden daarin, weggegooid.
Weet je dat zeker? Vreemd, want toen ik Debian 10 (stable) onlangs nog installeerde, moest ik eigenhandig een alsnog extra te installeren Firefox AppArmor profiel handmatig aanpassen in en enforce modus zetten. Dat kan aan mij liggen.
bleek dat er op 37 percent daarvan tenminste zich 1 JavaScript bibliotheek bevond
met tenminste een bekende kwetsbaarheid.
"Functionality first, security comes later."
Dat was met auto's en oliebollen ook al zo.
Duurde jaaaren en jaaaaren....
CSP policy voorgesteld als added security door het Tor-browser development team binnen Mozilla.
Lijkt me een zeer aannemelijk scenario. Ik geloof je.
Er kan echter best nog wel een schepje bovenop.
Er blijft nog veel te doen tegen alle reguliere ondergravers van security "om den brode".
En diegenen, die het begrijpen, hebben vaak aan een half woord genoeg ;).
luntrus
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?