door Erik van Straten, "het hierbij om zogenaamde "SSL-strip" aanvallen. Dat werkt als volgt. Om te beginnen moet een aanvaller toegang tot het netwerk tussen jouw computer/tablet/smartphone en de server van de bank hebben en zich tussen die verbinding weten te forceren."
• Wat is dan het
verschil in de werking van een pc die besmet is met een geavanceerde
banking trojan en een transactie aanpast na het moment dat deze goedgekeurd en wel naar de bank wordt verzonden door de klant?
Banking trojans met een dergelijke aanpak, het tussentijds aanpassen van de verzonden transactie, bestaan al lange tijd.
Dat probleem lijkt me altijd nog vele malen groter dan de kans op wifi misbruik. Niet alleen omdat wifi misbruik in deze variant relatief 'nieuw' is maar ook omdat inmiddels de meeste mensen met 'apps' bankieren die voor dit misbruik niet gevoelig zijn.
Hobbeltje voor malware is altijd nog dat je een pc eerst moet besmetten, de praktijk leert dat dat nog steeds in veel gevallen lukt.
Daarnaast heeft het gebruik van malware de nodige voordelen. Het bereik van malware is vele malen groter met het voordeel dat men zich veilig kan bevinden in een 'Safe H
(e)aven' buiten Europese arm der wet.
Op een terras gaan zitten of op een andere Hot
($hot)Spot een apparaat plaatsen is niet zonder 'kraag-vat-'risico.
Tel uit de winstvoordelen voor malwaremakers bij het gebruik van een banking trojan.
-> Tenzij?
Wordt de werking van banking trojans die tusentijds transacties aanpassen mogelijk ook geblokkeerd met het door banken instellen van de HSTS header?
Dan zou een belangrijk bestaand en veel voorkomend malware probleem daarmee eindelijk / voorlopig ook zijn opgelost.
-> Waarom hebben banken die HSTS Header niet al jaren geleden ingesteld vanaf het moment dat diverse browsers dat gingen ondersteunen?
Waren Internet Explorer of Safari implementatie uitstel en het bijbehorende 'grote' marktaandeel nog het probleem om HSTS te implementeren?
Dan had men op zijn minst dit al wel kunnen instellen voor Mozilla en Chrome browser varianten op basis van gedetecteerde browserheaders.
Detectie op browserheaders vindt namelijk al plaats door banken sites, experimenteer maar met wat verschillende useragent strings, oudere en nieuwere en je ziet welke door banken wel of niet worden geaccepteerd.
(Schade-schande-kennis, kom je achter als alleen de nieuwste van de nieuwste browserversies worden geaccepteerd met als gevolg geblokkeerde Long Term Support browser versies, of al te strak 'ingeregelde' browsermerkgerichtheid).
• Overigens, internationaal is al eerder geconstateerd dat ook grote internationale banken HSTS tot op dat moment nog niet hadden geïmplementeerd.
https://scotthelme.co.uk/hsts-the-missing-link-in-tls/
HSTS – The missing link in Transport Layer Security
Posted on November 30, 2013 by Scott Helme
"Out of interest I decided to check a selection of websites for high street banks and see if any had yet implemented a HSTS Policy. Having checked Barlcays, Halifax, HSBC, Nationwide, Natwest, RBS, Santander and Yorkshire Bank I was disappointed to find that none had yet implemented a HSTS Policy and some of them even have a dedicated online banking domain name."
+ 8 screenshot voorbeelden van code• Niet vergeten, de discussie gaat begrijpelijk heel terecht over banken, het overschaduwt wel de opmerking van 'de Winter' dat vele andere toepassingen ook kwetsbaar zijn voor misbruik.
Hopelijk wordt daar ook aandacht aan besteedt door betrokken partijen, alle https verbindingen voortaan standaard met HSTS header en een waarschuwing van je browser wanneer dat protocol niet wordt gebruikt?
Misschien kunnen browser makers op die manier gebruik van HSTS stimuleren, past de markt zich uiteindelijk aan omdat klanten over waarschuwingen bij services 'gaan zeuren'.
Als het geld dreigt te kosten zijn veranderingen verassend snel geïmplementeerd, dat is weer eens bewezen.