'Https bevat lek waardoor gegevens met javascript onderschept kunnen worden'

Volgens Belgische beveiligingsonderzoekers bevat https een lek dat het mogelijk maakt om met een javascript persoonlijke gegevens te achterhalen. Het script zou in een advertentie verwerkt kunnen worden. De onderzoekers presenteren hun bevindingen op Black Hat.

Voor de aanval is geen man-in-the-middle-positie nodig. Kwaadwillenden kunnen volgens onderzoekers Tom Van Goethem en Mathy Vanhoef van KU Leuven simpelweg een advertentie plaatsen met daarin een kwaadaardig javascript. De code kan vervolgens op de beveiligde pagina's exact meten hoe groot de versleutelde data is die wordt verstuurd.

Met de hulp van twee andere exploits, bekend als Breach en Crime, is het mogelijk om aan de hand van de grootte sommige data te ontsleutelen. Dat is mogelijk door kwetsbaarheden die zitten in de manier waarop websites data comprimeren om ze sneller te laten laden.

De onderzoekers geven de methode de naam Heist, wat staat voor HTTP Encrypted Information can be Stolen Through TCP-Windows. Op de Black Hat-beveiligingsconferentie zullen de onderzoekers hun bevindingen demonstreren aan de hand van een kwaadaardige advertentie op de New York Times-website.

Van Goethem stelt dat hij als hij er tijd in zou steken met de methode 'een hoop ellende' zou kunnen veroorzaken. Volgens de onderzoeker zou de combinatie van Heist en Breach het voor aanvallers mogelijk maken om csrf-tokens uit te lezen. Afhankelijk van de functionaliteit die de website aanbiedt, zou dat de aanvaller toegang kunnen geven tot het volledige account van het slachtoffer.

Het lijkt onwaarschijnlijk dat de kwetsbaarheid eenvoudig ingezet kan worden voor aanvallen op grote schaal. De code moet specifiek per website zijn geschreven en de methode vereist een groot aantal requests. Websites die dergelijke verzoeken in de gaten houden, zullen deze vermoedelijk tegenhouden.

De onderzoekers hebben Google en Microsoft vooraf ingelicht over hun bevindingen. Volgens Van Goethem is de exploit op dit moment enkel tegen te houden door third-party-cookies te blokkeren.

Update 15.23 uur: De onderzoekers hebben hun presentatie en het volledige onderzoek online gezet.

Reacties (95)

Als ik het zo lees zit de grootste kwetsbaarheid dus in de manier van compilenpressie van code door websites zodat die sneller laden en niet zozeer in https?

[Reactie gewijzigd door Emgeebee op 4 augustus 2016 14:00]

Als ik het zo lees zit de grootste kwetsbaarheid dus in de manier van compilen van code door websites zodat die sneller laden en niet zozeer in https?

Nee. Het probleem zit in TLS compression (wat v.z.i.w. vanwege de eerdere CRIME exploit eigenljik in alle browsers uitgezet is als het überhaupt al ondersteund is geweest) en in HTTP compression m.b.v. bijv. gzip of deflate.

Kort door de bocht werken deze compressies werken door byte-sequences (ook dus gewoon stukjes tekst) die vaak voorkomen in een dictionary op te slaan en dan een kort replacer token in de plaats te zetten.

De eerdere CRIME en BREACH aanvallen werken door een intelligente gok (bij "@gmail.com") te doen op een pagina die gebruikersinvoer terug naar buiten stuurt en te kijken of de grootte v/d gecompresste response wijzigt. Zo ja; dan kwam die reeks characters niet al ergens anders voor. Zo nee; dan hebben ze goed gegokt. Door dit vaak genoeg te doen en een flinke hoeveelheid van de originele plaintext terug op te bouwen kun je een response uiteindelijk compleet gaan kraken.

CRIME en BREACH moeten dan echter wel de grootte v/d response meten. En dat vereistte tot aan nu altijd een Man-in-the-Middle positie om het TCP/IP verkeer te inspecteren.

HEIST is nu een toevoeging hier boven op die een aantal recent aan webbrowsers toegevoegde APIs misbruikt om uit afgeleidde data met redelijke zekerheid op te kunnen maken of een TCP/IP response van grootte is veranderd of niet. Hierdoor is de MitM vereiste komen te vervallen.

----

Het uitzetten van third-party cookies is een botte-bijl workaround. Door deze uit te zetten zal een browser bijv. login tokens die in cookies staan niet meer doorsturen wanneer een service of pagina als derde partij (bijv. in een voor de gebruiker verborgen iframe) benaderd wordt.

Probleem is natuurlijk dat third-party integraties zoals heel veel social media widgets, maar soms ook serieuzer spul zoals internetbetaaloplossingen, dan ook niet meer werken.

----

Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses.

Het grote probleem is organiatorisch: dit vereist dat iedereen het moet ondersteunen want anders 'maken we het internet stuk'.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 14:16]

Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses.

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?

Uitfaseren is niet echt nodig. Deze specifieke toepassing van deze API is zo goed als zeker onbedoeld, en browsers zullen/kunnen deze manier van gebruiken wellicht/waarschijnlijk beperken. Browser fabrikanten hebben wel vaker bepaald gebruik van APIs aangepakt om soortgelijke redenen.

Maar het gevaar van deze aanval is niet echt groot. Zoals het artikel al aangeeft moet de aanval precies gericht zijn op een bepaalde site. En dan moet je al geluk hebben dat jouw add op die site, én op het juiste moment getoond wordt. Je moet immers het initiele echte pakketje van jouw onderscheppen.

En dan nog, zomaar 'onbeperkt' zelf dan probeersels naar een site sturen is niet zomaar mogelijk. Veel sites hebben rate limits. Daarnaast je kent de TLS plain-text niet, dus kunt ook niet zomaar de browser van het slachtoffer dwingen dezelfde plain-text te sturen plus jouw probeersel. Ik schrijf 'zomaar' vetgedrukt, want dat is een essentieel onderdeel van de BREACH aanval.

Je moet dan al een hogere API gebruiken, welke dan door de browser omgezet wordt in een GET met een cookie/token of zo. In feite is dat het enige wat echt mogelijk is: een cookie/token proberen te achterhalen. (Al is dat natuurlijk wel ernstig.)

Dus wat mogelijk is is heel erg site afhankelijk: dus niet alleen is de aanval moet site-afhankelijk opgezet worden, maar de maximale buit zelf is dat ook.

En tenslotte als jij de tab/browser te vroeg afsluit, is de aanval onderbroken.

Deze aanval is op zich goed gevonden, maar het effect wordt wel een beetje flink opgeklopt. Zomaar 'even' BREACH gebruiken is immers niet mogelijk.

Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses.

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?

HEIST misbruikt volgens het originele artikel secundaire karakteristieken en kennis van hoe het TCP protocol in frames/windows opgebouwd is om redelijk accuraat te voorspellen of een response van grootte is veranderd mbv informatie uit o.a. de Resource Timing en Fetch APIs.

Die APIs uitfaseren is het foute antwoord. Dat is gewoon wachten tot er weer een nieuwe manier is om die informatie boven te krijgen. Los het bij de bron op door de request lengte te randomizen en zo het compressie orakel onbruikbaar te maken.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 15:03]

Misschien niet de gehele API uitfaseren, maar bijvoorbeeld de API standaard zo configureren dat de hoofdpagina toestemming moet geven voor geladen javascript om API's volledig uit te lezen (net zoals x-frame-options voor iframes doet).

Zinniger is het om geleidelijk alle client-side scripting uit te faseren, het is nu na twintig jaar internet wel duidelijk dat dit het grootste security risico is. De afgelopen jaren zijn er al een aantal de nek omgedraaid (Java applets, Silverlight en Flash), en JavaScript zou de laatste moeten zijn.

Er is anno 2016 niet echt een goede reden meer waarom je niet alle code netjes serverside zou doen, en de client script-vrij HTML/CSS kan serveren. De scripts die bepalen welke random banner je aan je client laat zien kan ook gewoon serverside draaien.

[Reactie gewijzigd door Dreamvoid op 4 augustus 2016 18:02]

Als je ooit een moderne webapplicatie gebouwd hebt zou je snappen waarom je niet alles met serverside rendering kan doen. Je krijgt er heel statische pagina's van en hebt voor iedere kleine verandering een page-reload nodig. Simpele ajax om een klein stukje opnieuw te renderen is zelfs al javascript. Niet zo gebruiksvriendelijk dus. Een beetje zoals het web in de jaren 90 was.

Komt nog bij dat het juist mogelijk was om binaire rotzooi als flash, silverlight en active-x uit te faseren door de beschikbaarheid van javascript. Ik ben echt geen fan van frameworks van megabytes groot die je binnen moet trekken over je gelimiteerde mobiele verbinding, maar het is het een of het ander, je kunt niet alles verwijderen en nog een functioneel web overhouden.

Maar als je het veilig wilt houden: iedere browser heeft een optie om javascript compleet uit te zetten. Have fun.

Third-party cookies standaard geblokkeerd. (hé, dat is extra veilig!)
u-block origin, ghostery, noscript laat alleen het domein zelf toe.
En soms geef ik een cdn of ander gerelateert domein toestemming.
Active-x altijd al geblokkeerd. Net als flash.
Heeft me altijd aardig beschermt.
Er is geen enkele site die enig script nodig heeft tenzij ik er zelf iets wil posten, zoals nu hier.

LOL js heeft nog een hoop meer functies dan alleen een uitklap menu

Denk bijvoorbeeld aan online games, die schrijf je in HTML5 ÉN JavaScript, de een is de markup taal en de ander is de dynamische taal die daadwerkelijk de site functioneel maakt.

Zonder JavaScript zijn alleen nog maar webpaginas zoals wikipedia en nu.nl mogelijk....

Het idee om javascript uit te zetten is dan ook bizar. JavaScript kan je daarnaast nogeens niet te vergelijken met Adobe Flash, de een vereiste een hele eigen runtime en was een programma opzich ge-embed in de site en JavaScript is daadwerkelijk onderdeel van de browser en heeft daadwerkelijke interactie met de html en de gehele website.

JavaScript is en blijft een virtual machine. Dat het "scherm" van die virtual machine bijna altijd de DOM en HTML5 component van een browser is, maakt dat het zelfs een slechte virtual machine is. Want dat "beeldscherm" blijkt nu ook nog eens een heuse aanvalsvector te zijn.

Ikzelf ben nooit voorstander geweest van "applicaties die in je browser draaien". Daar is HTML nooit voor bedoeld geweest, en die hele AJAX en JavaScript zooi is er maar tegenaangeplakt gewoon om het toch enigzinds mogelijk te maken. Webapplicaties zijn dan ook, net zoals de omgeving waarop ze werken, snot, plak, ducktape, rotzooi en geklooi tot en met. De meeste code van de meeste webapplicaties die ik in m'n carriere als programmeur tegenkwam waren dan ook ook net zo'n grote en bijna altijd veel grotere rommel. Maar goed ... een raadsel dat het toch 'werkt'.

Wat wel goed is aan het 'nieuwe' HTML5 en JavaScript is dat toch een paar van die websites kunnen gebruikt worden door blinden en slechtzienden. Dat was ten tijde van die mottige Flash rotzooi helemaal uitgesloten. Man, wat was dat rommel en wat voor rottige websites zijn er toen gemaakt. Nuja, HTML5 en JavaScript gaat precies dezelfde richting op. M.a.w. de juniors leren het niet.

Uitklap menu's kan je met <details> <summary> doen, etc. Het is gewoon luiheid of gewenning om het op de ouderwetse JS manier te doen.

Details/summary is nog lang niet overal native ondersteunt.
Dus daar gaat je hele voorbeeld al.

en hoe ben je van plan om data uit een database the krijgen op verzoek van een gebruiker? wachtwoord sterkte, vrijwel elke Async operatie op een web pagina? ik zie client side code executie binnen de volgende 5/10 jaar niet verdwijnen, de manier waarop zal aanzienlijk veranderen, silverlight was een flop, flash wordt uitgerangeerd. maar Javascript heeft juist stappen in de juiste richting gemaakt. het is vaak aan de developer om dit beveiligd en kwalitatief op te lossen, dus niet altijd naar jQuery grijpen. of een andere library.

Hoe kan het dat dezelfde stukjes tekst dan steeds terugkomen in de TLS stream? Je zou verwachten dat door block-chaining dit niet zou voorkomen.

Hoe kan het dat dezelfde stukjes tekst dan steeds terugkomen in de TLS stream? Je zou verwachten dat door block-chaining dit niet zou voorkomen.

Het feit dat dezelfde stukjes tekst niet steeds terugkomen (en de grootte v/d response niet wijzigt) geeft juist aan dat je goed gegokt hebt...

Hij heeft wel een punt, wat als een nieuwe versie van je eliptische forwarded secrecy key zou kunnen resulteren in een andere grootte van dezelfde content.
En dat die variantie niet af te leiding is uit de key.

Dan zou de aanval meer requests nodig hebben per veranderd teken. Om zo te compenseren voor de variantie.

Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses

Een goede reactie, maar helaas is dit voorstel niet waterdicht. Immers als de paddding random is, kun je door dezelfde request X keer uit te voeren alsnog via statistiek bepalen of je succes had.

Het maakt het wel een stuk moeilijker omdat er meer tijd nodig is, afhankelijk van de omvang van maximaal toevoegbare padding.

Maar dan vergroot je dus de omvang van je compressed data, en kun je wellicht net zo goed compressie uitzetten bij deze typische kleine POST requests?

Gelukkig echter zijn inlog-tokens/cookies vaak best lang en hoe dan ook random-achtig, dus echt veel zorgen maak ik me niet. Immers de kans dat het zomaar toevoegen van text een patroon bevat van een cookie. Deflate vervangt bovendien enkel patronen van 3 tekens of groter, en dan weet een valler nog steeds niet waar in de inlog-token/cookie die zat.
De tijd nodig om zoiets te kraken is aanzienlijk groter dan de voorbeelden die in de HEIST presentatie gegeven worden van email-adressen etc.

Aangezien de cookies gebruteforced worden, waarom niet ook de cookielengte verhogen naar effectief minstens 256-bit entropy? Wat overigens heel lang wordt, omdat elke character apart goed of fout gerekend word.

[Reactie gewijzigd door Anoniem: 801137 op 5 augustus 2016 00:28]

[...]Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses.

Een goede vinding, we zouden een nieuw algorithme kunnen bedenken dat niet alleen elliptisch is en elk request de key wijzigd, maar ook variantie toevoegd aan de output size.

Het is naam mijn idee echter niet een oplossing voor dit soort aanvallen.
De 'random' sprijding die je toevoegd kent een minimum.
Door het aantal requests per veranderde character te vergroten, kun je met grotere zekerheid schatten of je dat mnimum hebt lange zien komen, en dus of er een nieuwe key in de lookup tabel van het compressiealgoritme werd toegevoegd of niet.

Bedenk dat technieken als WebSockets er voor zorgen dat duizenden requests per seconde aghandellen heel normaal wordt.

Ik verwacht dus dat het toevoegen van padding op korte termijn vertraging opleverd bij de attack, en dus verminderde succes rate zal kennen.

Maar dat dit van korte duur is.

---

Maar het gevaar van deze aanval is niet echt groot. Zoals het artikel al aangeeft moet de aanval precies gericht zijn op een bepaalde site. En dan moet je al geluk hebben dat jouw add op die site, én op het juiste moment getoond wordt. Je moet immers het initiele echte pakketje van jouw onderscheppen.

Vergeet ook niet dat we tegenwoordig iemand heel gericht kunnen vinden op internet. Je biedt op die unieke adkey van de persoon. En elke website waar hij langskomt met die ad provider (Google DoubleClick), zal jou advertentie tonen. Dus dat is in Nederland 80% van de bezochte sites.

[Reactie gewijzigd door djwice op 6 augustus 2016 11:26]

Nee, de basis is compressie.

Stel de webpagina die de Server naar mijn browser stuurt bevat "username = Hans". Deze is gecomprimeerd en ge-encrypted, dus kan niet gelezen worden.
Maar stel dat ik mijn "banner" samen met de webpagina word gecomprimeerd, en ik voeg "username = Pietje" toe, dan neemt de bestandsgrote toe van de webpagina toe.
Maar stel nu dat mijn "banner", "username = Hans" toevoegt dan zal de gecomprimeerde grote van het bestand nauwelijks toenemen, omdat deze "sequence" al voorkomt in het compressie woordenboek.

Oftewel dit type attack veranderd letter voor letter een bepaalde string tot dat deze matched met b.v. de cookie tekst...

de aanval bouwt verder op bestaande aanvallen die gericht zijn op HTTPS in combinatie met het GZIPen van request/responses. Dit heeft verder niets met compileren of code te maken.

En wat betreft CSRF-tokens stelen. Een fatsoenlijke JSON REST API heeft gelukkig geen CSRF-tokens nodig en rate-limiting om het aantal verzoeken, dus echt wakker lig ik er niet van.

Je bedoelt compressie denk ik. http(s) wordt met gzip ingepakt. En omdat gzip een vrij eenvoudige compressie is kun je (door informatie toe te voegen) meten wat voor effect dat heeft op de content lengte.

Volgens Van Goethem is de exploit op dit moment enkel tegen te houden door third-party-cookies te blokkeren.

Denk dat een ad-blocker ook prima werkt.

Nee, een adblocker werkt meestal op basis van een lijst bekende adverteerders of trefwoorden in de website. Zodra je dus javascript van een onbekende host gaat laden dan vind de adblocker dat prima (die houd ook geen facebook knoppen tegen om maar iets te noemen).

Volledige zekerheid heb blijkbaar dus pas als je third party cookies blokkeert (en er is bijna geen goede reden om dat niet te doen).

Mijn gedachte ook. Ik blokkeer javascript al jaren.

Echt? Je kan JavaScript gewoon uitvinken in de browser en dan wordt er geen JavaScript meer uitgevoerd. Maar ik ken me moeilijk inbeelden dat jij het blokkeert. Veel sites werken simpelweg niet meer zonder JavaScript. Vroeger hielden webbouwers wel eens rekening dat hun site ook compatible is met browsers waar JavaScript is uitgeschakeld, maar ik denk dat de meesten hier geen rekening meer houden.

Zonder javascript kan je niet reageren op Tweakers, dus het lijkt me sterk dat hij het blokkeert

Dat maakt het toch glashelder? Dat hij Javascript blokkeert in plaats van gewoon uitzet betekent dus dat hij Javascript in beginsel blokkeert, totdat hij het op een bepaalde pagina goedkeurt of misschien een bepaalde website whitelist.

Mijn dank, ik had het niet beter kunnen uitleggen. Whitelisting is the way to go. Het zal je verbazen hoeveel nutteloze javascripts er draaien die absoluut niet nodig zijn voor de functionaliteit van een website. Tweakers heb ik gewoon in mn whitelist staan.

• Websites laden sneller.
• Het geeft je inzicht in welke sites betrouwbaar zijn.
• Je bent een stuk veiliger
• Alleen de scripts draaien die jij toestaat

[Reactie gewijzigd door PizZa_CalZone op 4 augustus 2016 14:22]

Wat is hier een goede voor in chrome. Ik zie veel extenties die het doen maar die hebben allemaal erg weinig votes < 400.

Zelf dacht ik Ghostery misschien, daar heb ik hier wel dingen over gehoord in het verleden. NotScripts bestaat niet meer in de store

Ik gebruik noscript op firefox.
https://noscript.net/

Deden we dit niet in 2001 en zijn we er inmiddels mee gestopt ?

Waarom zouden we stoppen? Het is alleen maar erger geworden. De meeste sites hebben alleen javascripts nodig op het primaire domain en een content delivery network. De tientallen google scripts, advertentiescripts, vage tracking sites etc. vertragen de boel, zijn soms zo lek als een mandje of doen aan data-hebberigheid.

Ja, het maakt je browserervaring soms wat minder. Je moet per site uitzoeken wat nodig is voor de functionaliteit. En niet handig voor de huis-tuin en keuken internetter. Als je weet wat je doet heb je echter on the long run veel meer plezier ervan.

[Reactie gewijzigd door PizZa_CalZone op 4 augustus 2016 14:52]

Zonder client-side scripting ga je meteen terug gaat naar web 1.0. Een pagerefresh voor iedere verandering aan de pagina, nou liever niet...

Waarom niet? Er zijn ladingen websites die prima werken met page refreshes. Tweakers zou bv net zo functioneel zijn met een page refresh na een post, er zijn duizenden forums die zo prima werken.

Het scheelt enorm in de client-side cpu belasting, plus je voorkomt security issues als cross-site scripting en talloze exploits in de js runtime. Ik zie op langere termijn meer heil in een script-loos web, met native apps voor toepassingen waarvoor client-side zware cpu belasting nodig is. Noem het "web 3.0" ofzo.

[Reactie gewijzigd door Dreamvoid op 5 augustus 2016 17:42]

Helemaal blokkeren is inderdaad niet mogelijk, maar met plugins als uMatrix, noscript en/of request policy is het goed te doen voor technische gebruikers.

In de meeste gevallen kom je een heel eind door "first-party" javascript (van de site zelf) wel toe te laten en alle externe scriptjes te blokkeren met een paar uitzonderingen voor sites als wordpress en jquery die grote delen van internet aansturen.

Niks voor je moeder, die wordt gillend gek, maar een techneut met inzicht in hoe websites werken kan de controle zelf in handen nemen.

Waarom is het moeilijk in te beelden?
Niet iedereen heeft behoefte aan sites die vol animaties en dergelijke zitten, zelf whitelist ik voor javascript een enkel paar sites of bepaalde pagia's als het nodig is, want je ontkomt er soms niet aan, maar zoveel mogelijk niet, zelfde geldt voor 3rd party cookies, plugins standaard uitgeschakeld.
Want dat soort dingen heb je toch niet nodig als je bij 99% van de onbekende sites even wat bepaalde informatie wilt weten wat vaak vooral alleen stukjes tekst is.
Verder boeit het me erg weinig als daardoor het uiterlijk in de war geschopt wordt, gebruik ook regelmatig zat Google cache.
En het gros daarvan wordt ook gewoon in incognito gedaan, geen meuk hoeven opslaan wat niet nodig is.

Terug naar de jaren 90 graag, sites met knoppen zonder poespas .

Ik ken heel wat mensen die zelfs met lynx informatie zoeken. Toegegeven vaak bv. wikipedia of howtos of stackoverflow. Maar als je met zo'n textbrowser een beetje kan werken, dan werkt dat tien tot twintig keer sneller en handiger dan met de muis alles weg te moeten klikken en afgeleid worden door alle zooi die de advertisers nu weer naar je kop gooien.

Zij die de informatie op het web gebruiken voor hun technische job, hebben echt geen of weinig behoefte aan de consumententroep die het web veelal geworden is. Gelukkig zijn de meeste bronnen van technische informatie, op het web, wel nog eenvoudig en to the point. Dat is omdat het over de informatie gaat, en niet over de flashy flippy floppy flup prentjes en menuutjes (waar technische mensen veelal totaal geen boodschap aan hebben).

Kun je dan nog gewoon browsen? Half internet is javascript

Hij kijkt alleen de Tweakers frontpage

Maar volgens mij kun je hier toch ook niet reageren zonder Javascript?

Lijkt me sterk eerlijk gezegt, er zijn aardig wat websites die compleet afhankelijk zijn van JavaScipt.

Ik kom ook al jaren mijn huis niet meer uit.
En heb een alumiumhoedje op.

Third party javascript bedoel je waarschijnlijk. First party dan houd je geen website meer over.

Nee dat is niet hoe het werkt. Je hebt duidelijk geen idee waar je het over hebt. Bijna iedere verandering aan de DOM heb je javascript voor nodig. Je kan aardig ver komen met CSS conditionals, maar je zult nooit logica kunnen inbouwen zonder client-side scripting.

Je moet op een andere manier websites gaan ontwerpen inderdaad, en sommige dingen zal je anders moeten inrichten, maar je kan wel degelijk logica inbouwen en benodigde code serverside draaien, en naar de client toe enkel HTML/CSS serveren.

(los van zeer cpu/gpu intensieve sites als webgames enzo, maar dan is het sowieso zinniger uit performance oogpunt om native apps te gaan ontwikkelen)

Niet alleen dat, zo'n beetje iedere video website moet dan de prullenbak in. Daarbij kun je echt niet alle code server-side draaien. Er zijn hele download clienten geimplementeerd als websites, zelfs peer to peer file sharing. Dat kan dan allemaal niet meer, onder het mom van veiligheid. En dan als antwoord aarop heb jij native apps? Want dat is wel veilig? Dan heb je helemaal geen controle meer na het starten van de app.

Daarvoor is nou juist de <video> tag bij HTML5 gekomen, icm HTTP Live Streaming heb ik prima video websites draaien.

Het grote verschil is dat apps voordat het naar de clients uitgerold worden getest door Google/Microsoft/Apple/etc, bij websites wordt totaal wildvreemde code zonder pardon uitgevoerd. Het hele concept van rijke webapps is vanuit security oogpunt inderdaad een drama, daar moeten we m.i. zo snel mogelijk vanaf.

[Reactie gewijzigd door Dreamvoid op 5 augustus 2016 19:15]

De video tag zonder javascript is anders vrij zielig te noemen, geen media extensions enzo. En niet echt lekkere kwaliteitswissel en dergelijke. De gebruikerservaring zou echt vershrikkelijk naar beneden gaan.

En dat die code van apps gecontroleerd wordt, nou ook alleen maar op bekende malware (patronen), niet gewoon op fouten of andere "domme" dingen. Het 1 is echt niet veiliger dan de ander.

HTTP Live Streaming kan gewoon adaptive bitrate doen hoor, geen regel Javascript voor nodig.

In je browser kan de gemiddelde user niet controleren (buiten draconische maatregelen als ghostery/noscript) of de code van de daadwerkelijke site afkomt, of dat die geinjecteerd is door 3rd party ads, etc. Bij een app weet je dat alle code afkomstig is van de publisher, en in elk geval door een audit heen geweest is. Natuurlijk is dat veiliger dan gewoon alle code klakkeloos uitvoeren wat er maar voor de kiezen komt.

[Reactie gewijzigd door Dreamvoid op 5 augustus 2016 22:59]

Het verschil wel dat native toch een stuk dichter bij de PC staat dan de javascript in de browser. Javascript is nu toch echt een stuk waterdichter dan de meeste app omgevingen (Android, macOS en Windows zijn goeie voorbeelden). Met de android native code (NDK) kun je vrij veel met een toestel.

Dat valt nog wel tegen, inmiddels hebben browsers toegang tot GPS, local storage, webcams, microfoon, etc. Je moet maar hopen dat de JS runtime waterdicht is, maar de geschiedenis geeft weinig hoop.

Inmiddels kan je met JS bijna net zoveel als ActiveX destijds - niemand leert in de tech wereld van het verleden.

Als ik naar de sites kijk waar ik 95 procent van de tijd op zit, daar zie ik niks waar JS echt nodig was geweest. Neem nou Tweakers.net, ik kan best leven met een reload na het plaatsen van een comment (er is nu sowieso al geen live updating van de comments), bij GoT moet dat ook al.

Of Facebook, ik kan ook prima leven met een statische Facebook (zoals m.facebook.com), als ik het dynamisch wil open ik wel de app (die is sowieso sneller).

[Reactie gewijzigd door Dreamvoid op 5 augustus 2016 23:31]

Werkt dit nou ook als je geen Java hebt geïnstalleerd? Want dan is het probleem ineens een stuk minder groot

Dit gaat om Javascript, heeft niets met Java te maken.

Javascript is geen onderdeel van Java, ook al doet de naam iets anders vermoeden. Javascript zit in de browser zelf gebakken.

nee, Java is niet JavaScript...compleet iets anders

Java is iets anders dan JavaScript. Het gaat over JavaScript en dat is altijd ingebakken in de browser. Je kan het uitzetten, maar dan werken veel sites niet meer.

Het gaat om JavaScript niet om Java. Als je JavaScript uit zet heb je er geen last van, maar dan functioneren veel sites weer slecht.

Behalve de naamgeving is er geen enkele relatie tussen Java en Javascript...... Ze hebben helemaal niets met elkaar te maken.

Om antwoord op je vraag te geven dus: Ja, dit werkt ook als je geen Java geïnstalleerd hebt aangezien Java hier geen enkele invloed op heeft.

Java en Javascript hebben helemaal niets met elkaar te maken

Javascript =! java, klein maar belangrijk verschil.
(hoewel iedereen in de basis imho geen java of flash meer geinstalleerd hoort te hebben, zijn er helaas nog steeds aantal sites die java verplichten.. zelfs grote jongens als DNB en ING).

[Reactie gewijzigd door SinergyX op 4 augustus 2016 13:32]

Java != Java (Browser) Applet.
Er is werkelijk niets mis met Java zelf. Veel servers gebruiken java onder de kap om dynamische websites te serveren (inclusief Tweakers).
Daarnaast zijn er ook tal van desktop programma die Java nodig hebben. Je moet Java zien als tegenhanger van .net
Tevens worden native apps voor android ook in Java geschreven.

[Reactie gewijzigd door sir_huxley op 4 augustus 2016 13:47]

Java != Java (Browser) Applet.
Er is werkelijk niets mis met Java zelf. Veel servers gebruiken java onder de kap om dynamische websites te serveren (inclusief Tweakers).
Daarnaast zijn er ook tal van desktop programma die Java nodig hebben. Je moet Java zien als tegenhanger van .net
Tevens worden native apps voor android ook in Java geschreven.

Als ik een tijdmachine had zou ik teruggaan in de tijd en de flapdrol die Javascript zijn naam heeft gegeven een schop geven

Edit: daarvoor zou trouwens niet eens een tijdmachine nodig zijn... Maar ik zou hem wel vriendelijk verzoeken niet zo'n irritant verwarrende naam te kiezen

[Reactie gewijzigd door Neko Koneko op 4 augustus 2016 15:09]

Die naam was bewust, want Javascript was qua syntax en andere zaken geinspireerd door Java, plus Java was toen nog geen paria zoals nu, maar juist erg hip.

Nee de syntax en andere zaken waren helemaal niet op Java geïnspireerd, maar vooral op Scheme. Het zou eerst Mocha of LiveScript gaan heten.
De enige reden om Java in de naam te gebruiken was omdat dat moest van de marketing peeps van Netscape.

Huh? ING heeft bij mij geen Java nodig volgens mij?

IBP/Wholesale zakelijke kant wel

Pfff, das niet bepaald standaard. En dat is toch gewoon bedrijfslaptop. Wat kan jou dat schelen

Wat dacht je van oudere HP switches... Darn, ze waren tot voor kort ook allemaal unsigned. Het was zo jammer dat je de web-management wel uit moest zetten bijna.

[Reactie gewijzigd door EraYaN op 5 augustus 2016 16:59]

Ja, want zowat het enige wat Java en javascript gemeen hebben is het woordje "java".

Javascript zit standaard in elke moderne browser ingebakken, en als het uitgeschakeld wordt gaan veel websites niet meer goed werken.

javascript en java zijn compleet verschillende dingen, dus nee dat werkt niet. een add-on zoals no-script installeren die alle javascript componenten uitschakeld werkt echter wel.

link naar noscript

Zonder me te laten hinderen door kennis op het gebied van hedendaagse advertentiediensten, is een advertentie embedden op een website niet per definitie onveilig? Ik bedoel, als ik een pagina bezoek waar medische gegevens op staan, of wat voor gegevens dan ook, en iemand heeft daar een statistiekenscript of advertentiescript op draaien, dan kunnen deze scripts toch bij belangrijke data?

[Reactie gewijzigd door yade op 4 augustus 2016 15:39]

In de basis niet (encrypted data), maar afhankelijk van de website zelf, is potentieel alles mogelijk.

Was dat trouwens niet bij 1 van die zorgverzekeraars (iedergeval CZ), waar gewoon trackingcookies in je declaratieomgeving zitten?

Als ze het goed doen: ja. Overigens wordt het meestal middels iframes ingeladen en volgens mij kunnen die niet zomaar op de content van de pagina met de iframe lezen?

Meestal zijn dat 'friendly' iframes die met script gegenereerd worden en waarbij de inhoud eenvoudig toegang heeft tot de 'parent'-pagina. Dit wordt zo gedaan om uitingen zoals floor-ads en pop-overs ook mogelijk te maken.

en iemand heeft daar een statistiekenscript of advertentiescript op draaien, dan kunnen deze scripts toch bij belangrijke data?

Goede vraag, maar gelukkig is het antwoord 'nee'.

Zo zijn cookies van belangrijke sites vaak encrypted, en geven bovendien browsers niet de data van server A aan server B, ook al staan die gemengd op een pagina.

Dat kan inderdaad liggen aan de siteconfiguratie, omdat nog lang niet alle sites alleen httponly cookies gebruiken. En wat zou nou naast het gebruiken van https ook de cookies apart te versleutelen i.p.v. een lange willekeurige string gebruiken als cookie?

[Reactie gewijzigd door Anoniem: 801137 op 5 augustus 2016 03:05]

Als het antwoord nee is, hoe werkt Google Analytics dan?

Als een pagina gevoelige informatie toont dan kan het boze advertentie script hier toch gewoon bij en met een request doorspelen naar een externe site?

[Reactie gewijzigd door yade op 5 augustus 2016 10:19]

GA werkt doordat de developer de gegevens zelf aan de API geeft, veelal in de vorm van functie aanroepen. En de rest is allemaal zelf te achterhalen (DOM tijden en dergelijke).

Third-party cookies zouden gewoon standaard geblokkeerd moeten worden. Als bezoeker van een website heb je er eigenlijk nooit voordeel van, maar wel vaak nadeel.

Eigenlijk kun je dus gewoon geen client-side scripting toestaan op je machine. Zelfs met high-level talen kun je door gebruik te maken van timing en eigenschappen van het OS (zero pages, coalescing, compressie, etc) en de omgeving altijd wel data oogsten waar je niet bij zou moeten kunnen. Ook virtual machines zouden op zo'n manier data uit hun host kunnen oogsten, dus ook dat levert geen oplossing op de lange termijn.

Dat is inderdaad de oplossing, maar webdevelopers zijn nog blijven hangen in de mindset van Flash, Silverlight en JavaScript. Een moderne websites kan je prima met enkel HTML/CSS maken, en als je wat code wilt draaien, kan je het serverside doen.

Qua dataverkeer en CPU gebruik kun je tegenwoordig beter een plaatje van de gerenderde website als PNG opsturen, da's veel minder data dan wat alle css, javascript enzo nodig heeft om een standaard nieuwspagina te renderen.

Inderdaad, maar als je een website hebt bent, en de keus hebt tussen:
- leg de de cpu cycles, geheugengebruik en security risico bij de gebruiker
- doe alles serverside waar je voor RAM, CPU en extra dataverkeer moet betalen
dan is de keus (helaas) snel gemaakt.

Waarom zijn Google en Microsoft wel ingelicht en Mozilla niet? Is Firefox hier niet vatbaar voor?

"Volgens Van Goethem is de exploit op dit moment enkel tegen te houden door third-party-cookies te blokkeren."

Met andere woorden, ik ben al jaren veilig voor deze exploit. Er is geen enkele functionele reden voor een gebruiker om third party cookies toe te staan, deze schaden alleen maar de privacy.

Pikoe: Je kunt niet meer reageren zonder javascript

Nou, ja eigenlijk dus wel.

[Reactie gewijzigd door Webgnome op 4 augustus 2016 13:53]

Er is geen enkele functionele reden voor een gebruiker om third party cookies toe te staan, deze schaden alleen maar de privacy.

Er zijn heel veel legitieme toepassingen die wanneer ze binnen een iframe draaien nog steeds cookies nodig hebben. Bijv. als session token of om op een bepaalde account ingelogd te blijven.

En dat strekt verder dan enkel social media integratie.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 14:12]

Veel software die third-party cookies blokkeren houden wel rekening met social media cookies.

Veel software die third-party cookies blokkeren houden wel rekening met social media cookies.

Juist die sign-in cookies kunnen nu dus via HEIST gestolen worden om bijv. iemands Facebook account over te nemen.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 15:00]