Chrome krijgt waarschuwingsfunctie als webformulier onbeveiligd wordt verstuurd

Chrome krijgt vanaf de M86-build een waarschuwingsfunctie als gebruikers een webformulier willen invullen en versturen op een beveiligde https-pagina, terwijl het formulier op onbeveiligde wijze wordt verstuurd.

Google noemt dit mixed forms, waarbij formulieren op https-websites niet conform de https-standaard worden verstuurd. Het bedrijf stelt dat dit een risico met zich meebrengt voor de beveiliging en privacy van de internetgebruiker, bijvoorbeeld omdat de ingevulde informatie zichtbaar kan zijn voor derden, zodat kwaadwillenden gevoelige informatie kunnen inzien of aanpassen.

Om dit te voorkomen, zal Chrome een functie krijgen om deze risico's voor het voetlicht te brengen. Zo wordt de autofill-optie uitgeschakeld bij mixed forms en krijgen gebruikers bij het invullen een zichtbare waarschuwing in rode tekst te zien, waarin wordt aangegeven dat het formulier niet beveiligd is. Als de Chrome-gebruiker dan alsnog het formulier wil insturen, volgt er een volledige waarschuwingspagina. Het is vervolgens wel mogelijk om het formulier alsnog in te sturen.

Voorheen werden mixed forms alleen gemarkeerd door het sloticoontje in de adresbalk weg te halen. Volgens Google vonden gebruikers dit niet duidelijk en werden daarmee de risico's niet goed gecommuniceerd.

Reacties (42)

[Lick_A_Brick]

Is er eigenlijk een reden om nog een site zonder HTTPS te draaien? Ik begrijp dat als het er geen data verzonden wordt het ook niet persé nodig is, maar met LetsEncrypt is er toch eigenlijk geen reden meer om je site nog over HTTP te laten lopen?

[Gomez12]

LetsEncrypt is afaik een beetje tegenstrijdig voor sommige(/veel) toepassingen.

Gaat het je om een website dan is LetsEncrypt makkelijk, maar gaat het om een intranet / router-setup-pagina / switch-setup pagina / elke andere interne pagina dan ook, dan is LetsEncrypt weer of een beveiligingsrisico omdat je je firewall ervoor zal open moeten stellen om het automatisch te doen, of het is heel erg veel gedoe omdat de handmatige certificaten qua planning steeds korter gaan worden.

[Redstone]

Nee hoor hoeft niet. Je een wildcard via je dns challange verkrijgen.

[Reactie gewijzigd door Redstone op 22 juli 2024 22:21]

[Gomez12]

Alhoewel ik die niet kende en wel eens ga onderzoeken, zit ik toch alsnog met een zooitje legacy hardware waarbij je certificaten handmatig moet uploaden en daarvoor is qua planning LetsEncrypt ongeschikt.

Daarvoor moet je of de hele boel gaan scripten (is leuk tot 2 jaar terug hadden we nog een device wat we moesten updaten via een vm want die moest een IE met activeX hebben) of kopen of toch maar gewoon de waarschuwing negeren...

[WhatsappHack]

Of gewoon een wildcard certificaatje kopen voor die zaken, even simpel en langer geldig. Al kan je binnenkort enkel nog maar 1-jarige certificaten kopen. Apple en Mozilla gaan certificaten die langer geldig zijn dan 12 maanden + wat dagen *niet* meer accepteren in hun browsers als deze uitgegeven zijn naaaa... Volgens mij 20 augustus 2020, maar (certificate) pin me er niet op vast.

[Zer0]

Leuk, maar wat heb je aan een wildcard certificaat voor een extern domain als je intern geen FQDN's gebruikt?

[b12e]

Dat dus. Mijn vorige werkgever vond het leuk om .lan als TLD te gebruiken voor interne hostnames, dus dc.werkgever.lan, rotterdam.werkgever.lan, intranet.werkgever.lan.

Vraag daar maar eens een cert voor aan 🤦🏻‍♂️

[pe0mot]

Gebeurt vaker.
Ik kom dit bij klanten tegen.
Het is een heel lang verhaal voordat men begrijpt dat dit niet kan.

[Gomez12]

Het kan wel, alleen moet je dan je eigen certificate authority op gaan zetten binnen je AD etc.

Je hebt dan simpelweg geen externe certificate authority die jou kan helpen, je moet het zelf doen.

Wat in theorie ook niet zo erg is, alleen in de praktijk heb ik het meer zien neerkomen op dat men 1x in de 2 jaar maar een nieuwe procedure bedacht om nieuwe certificaten uit te geven, want procedures voor eenmalig gebruik binnen 2 jaar willen nog wel eens achterlopen.

[mrwiggs]

HTTPS is altijd nodig omdat je de data die je ontvangt ook wilt kunnen vertrouwen.

Er is inderdaad geen reden meer het niet te doen. Behalve deze dan misschien 😉

[Reactie gewijzigd door mrwiggs op 22 juli 2024 22:21]

[Zer0]

Ik gebruik voor diverse interne websites toch echt geen HTTPS, te veel gedoe om een geldig certificaat aan te maken zonder externe FQDN, en ik heb ook geen zin om self-signed certificates te verspreiden.

[pe0mot]

en ik heb ook geen zin om self-signed certificates te verspreiden.

Tja, dan is security dus misschien niet echt je ding

[Zer0]

Tja, dan is security dus misschien niet echt je ding

Het is een deel van mijn verantwoordelijkheden in mijn functie, maar beveiliging is ook weten wanneer het niet nodig is. Prive gebruik ik momenteel 15 Let's Encrypt certificatien, voor spul waar HTTPS belangrijk op is, voor de rest is het niet belangrijk, en doe ik het niet.

[mjz2cool]

In hoeverre garanderen self signed certificates de veiligheid? Bovendien krijg je bij websites die dat gebruiken altijd een melding dat de website onveilig is, en kom je pas na 2 klikken bij je bestemming (bij Chromium based browsers in ieder geval).
Voor een interne website snap ik het wel.

[mrwiggs]

Ik vind het naïef om intern alles te vertrouwen. Tevens zorgt HTTPS er ook voor dat je zeker weet dat je met de juiste server bent verbonden. DNS is nog gemakkelijk te spoofen dus zonder HTTPS weet jij niet of je op de juiste interne website zit.

Als je geen publieke certificaten wilt gebruiken is de handigste oplossing niet losse self-signed certificates! Dit is lastig in beheer en je zult elk individuele certificaat moeten vertrouwen. Het idee is dat je slechts 1 signed root CA genereert en die gebruik je om nieuwe certs te signen. Die root CA zet je in je trust store en klaar is Kees.

[Zer0]

Tja, het is ook zo belangrijk dat ik veilig kan communiceren met een raspberry pi waarmee ik via een webinterface een ledje kan laten branden. Stel je voor dat iemand die data onderschept, of dat ik op een andere "server" terecht kom.

[kodak]

Dat een website HTTPS gebruikt wil niet automatisch betekenen dat je de data kan vertrouwen. Dat is niet het doel van HTTPS. HTTPS kan gebruikers vertrouwen geven wat bij de praktijk past, maar dan moeten ze we genoeg van HTTPS snappen. Alleen HTTPS toepassen verandert dat niet.

[mrwiggs]

Met “vertrouwen” doel ik op het feit dat de informatie die je ontvangt ook echt de informatie is die de website heeft verstuurd (geen man-in-the-middle attack mogelijk).

[WoutervOorschot]

Omdat het significant ingewikkelder is en meer onderhoud vraagt dan op http hosten.

En ja, ik ken letsencrypt, https is voor de gemiddelde tweaker niet moeilijk, maar het is wel een stuk ingewikkelder (en je renewal moet blijven werken) dan een simpele http hosting.

[Gropah]

Met een webserver zoals Caddy is het nauwelijks meer moeite om iets achter HTTPS te draaien. Je kan files hosten achter HTTPS met letterlijk alleen [code]caddy file-server[/] en het is ook helemaal niet moeilijk om spul te proxyen om onbeveiligde services te beveiligen.

[samtoxie]

Je kan heel simpel met iets als certbot het hele proces automatiseren. Slechts 1x en command runnen en klaar

[RoestVrijStaal]

Niet iedere webhoster biedt SSH toegang voor shared hosting of laat staan dat je een applicatie mag draaien die de hoster niet op de server geïnstalleerd heeft.

En voor een simpele website is (het onderhoud van een) VPS/Dedi weer overkill.

[mjz2cool]

Er zijn meerdere hostingbedrijven die dat voor je doen met een paar klikken, inclusief auto renewal. Zowel voor gratis certificaten als betaalde.

[StefanJanssen]

De enige reden is: Extra werk bij het inregelen.

Het is geen goede reden daarintegen.

[samtoxie]

Het is echt ontzettelijk makkelijk tegenwoordig als je website apache of nginx gebruikt.

Even certbot installeren en een simpele command runnen, vervolgens 1 of 2x een vraag van certbot beantwoorden (bijvoorbeeld of je http wilt redirecten naar https) en klaar. Certificaten bij let's encrypt die automatisch voor je vernieuwd worden.

[StefanJanssen]

Met Caddy is het nog makkelijker, je moet namelijk moeite doen het geen HTTPS te laten zijn.

[lepel]

Wij leveren community websites waarbij gebruikers vaak een eigen domein laten doorverwijzen naar een (https) website op onze servers middels een 301 redirect of javascript redirect. Niet via iframe uiteraard. Heb je dan geen ssl certificaat voor jouw domein en typ je “www.mijnwebsite.nl” dan wordt dit ondertussen ook automatisch naar “https://www.mijnwebsite.nl” verwezen, wat dan weer een “onveilig” error geeft.

Soms biedt de registrar geen mogelijkheid een ssl certificaat via let’s encrypt te verzorgen, of je moet dan een hosting pakket afnemen om dat te kunnen.

[Reactie gewijzigd door lepel op 22 juli 2024 22:21]

[PhilipsFan]

Ja, die reden is er. Als je een prutser bent doe je dat.

Ik moest laatst een intakeformulier op de website van m'n fysiotherapeut invullen. Adres, BSN, omschrijving van de klacht. Uiterst gevoelige informatie. Blijkt dat formulier gewoon via http te worden verstuurd, niet https.

Dus ik mopperen bij m'n fysio. Zegt ie dat het prima voor elkaar is want hij heeft er een bedrijf voor ingehuurd. Het wilde er gewoon niet in dat een patient hier blijkbaar meer over wist dan het prutsbedrijf wat hij hiervoor inhuurde...

[Genosha]

Het zou mooier zijn als de submit knop zou worden uitgeschakeld. Op deze manier leert de web developer niets

[RoestVrijStaal]

Hoe wil je dan op je lokale machine ontwikkelen?

Standaard vinden browsers self-signed certificaten vieze dingen. Tenzij jij jouw browser zo configureert dat die het accepteert.

[Mr. Awesome]

Volgens mij is 'localhost' bij zowel Chrome als Firefox een uitzondering als het op HTTPS gaat.

[kodak]

Het uitschakelen van functionaliteit bij de gebruiker heeft effect op de gebruiker. Het kan effect op de web developer hebben maar dan moet wel aan diverse voorwaarden worden voldaan. Het simpelweg uitschakelen van functionaliteit in de browser zorgt er niet zomaar voor dat aan die voorwaarden zal worden voldaan. Dus hoe ga je er met het uitschakelen dan voor zorgen dat de web developer er wel van gaat leren? En ook niet onbelangrijk: hoe voorkom je dat je formulieren onbruikbaar maakt terwijl ze voor de gebruiker hard nodig zijn? De browser kan namelijk niet raden of het formulier nodig is, dat is aan de gebruiker.

[Reactie gewijzigd door kodak op 22 juli 2024 22:21]

[Anton]

Goh, dit had Internet Explorer 3.0 ook al, en Netscape van rond die tijd. Alleen kon je dat met een “do no show this warning again”-vinkje oid eenvoudig uitzetten (wat iedereen dan ook deed)...

[RobinJ1995]

Chrome had het ook al. Enkel de full-page warning en het uitschakelen van aurofill zijn effectief nieuw hier.

[Anton]

Chrome bestond nog niet in 1996

[pirania]

Dat doet Firefox ook al jaren toch?

[Blinkin]

Dat was ook mijn gedachte, zo'n beetje alle browsers dacht ik maar ik ga nu twijfelen. Verbaasd mij in elk geval dat Chrome het niet eerder had.

[mjz2cool]

Schakelt die ook autofill uit en laat deze eerst een aparte pagina zien met een waarschuwing?

[GoT]

Ik snap het artikel niet.
Bedoelen ze ermee dat de <FORM> zelf op een https:// server zit en dat ACTION="" richting een andere URL http:// (zonder s) gaat.
Zo ja, dat is toch niet meer dan logisch dat je een waarschuwing krijgt.

[Kenhas]

dat is toch wat er letterlijk in het artikel staat

versturen op een beveiligde https-pagina, terwijl het formulier op onbeveiligde wijze wordt verstuurd

Dacht eigenlijk dat dit er al lang inzat. In ieder geval iets dat bijvoorbeeld afbeeldingen op een https pagina niet van een http-bron mogen komen

[Reactie gewijzigd door Kenhas op 22 juli 2024 22:21]

[Verwijderd]

Het idee erachter is dat de POST onveilig over HTTP gesubmit wordt. Maar ook al zou het veilig over HTTPS zijn, een gehackte site kan die gegevens prima onderscheppen.

[dutchgio]

HTTPS gaat niet helpen tegen een gehackte website, maar wel tegen een Man in the Middle aanval.
Als je zo'n onbeveiligd formulier invult kan iemand die het verkeer aftapt op bijvoorbeeld een public wifi netwerk de data inzien en inhoud van http websites onderscheppen en aanpassen.