Ik gebruik al enige tijd HTTPS , wel betalend maar ik ben dus al safe voor de nieuwe updates

Een anders mooi alternatief is om CloudFlare te gebruiken, deze geven je site gelijk een CDN en helpen dus om je verbinding sneller te maken.

Uiteindelijk blijft een betaald certificaat wel het beste, dus als je serieus over je website bent doe je daar uiteindelijk nog het beste aan

Citaat van Laura

Volgens Barnes kan een aanvaller in een dergelijk geval via JavaScript het wachtwoord stelen voordat de gebruiker op inloggen klikt.

Ik ben benieuwd hoe dat dan in zijn werk gaat. Waarschijnlijk heb je dan al hele andere problemen (XSS)? Is hier een bron van? Als dit namelijk zo makkelijk is als wordt gesuggereerd, hoe verklaar je dan dat niet alle sites met dergelijke functionaliteit inmiddels over zijn naar HTTPS? Dit neigt toch een beetje naar paniekzaaierij.

Citaat van Laura

Waarom gebruik jij nog geen ssl certificaat?

Ik zou dit nog wel een leuke toevoeging vinden voor mijn homepage. Maar deze heeft enkel een uniek subdomein en zit ook op shared hosting. Waarschijnlijk gaat dat niet vliegen dan.

@FangorN
Ook shared hosting kan SSL op de domeinnaam krijgen, tegenwoordig is een eigen IP-adres niet meer nodig voor SSL.

@Laura
Ben ook wel benieuwt naar de bron van de JavaScript wachtwoord verhaal...

Citaat van Laura

Via XSS kun je het wachtwoord stelen.
Bv: browsers die automatisch het wachtwoord voor je invullen.
Dit kan dan worden afgevangen of bv onversleuteld verzonden eerst naar de hacker?

Hoe helpt HTTPS als je website / webapplicatie zelf vatbaar is voor XSS? XSS is volgens mij meestal "client side", de "hack" vindt meestal in je browser plaats en de te stelen data wordt vervolgens via een ander pad weggesluisd. Dit loopt helemaal buiten HTTPS om. Indien XSS mogelijk is is dit een lek in de site zelf.

HTTPS beveiligt enkel het ontvangen en versturen van data van en naar je webserver via encryptie. Daarbuiten gelden nog steeds de aloude regels.

Het is ook niet alsof je met het gebruik van HTTPS de rest van de beveiligingsvoorzieningen overboord kan gooien. Bij beveiliging lijkt het mij onverstandig om al je geld op één paard in te zetten. Het is beter om het risico te spreiden door gebruikmaking van lagen.

Volgens mij is XSS voor een heel groot deel uit te bannen door de toepassing van output escaping. Een noodzakelijke voorwaarde voor het correct werken hiervan is dat je character encoderingen van je documenten en je data op orde zijn.

Dit zijn aparte voorzieningen die je zult moeten treffen, en staan helemaal los van HTTPS die nogmaals, enkel zorg draagt voor een veilige verzending en ontvangst van data, maar dat zorgt er dus niet voor dat de data zèlf veilig is (in het gebruik), daar moet je andere maatregelen voor treffen.

Citaat van Laura

Via XSS kun je het wachtwoord stelen.
Bv: browsers die automatisch het wachtwoord voor je invullen.
Dit kan dan worden afgevangen of bv onversleuteld verzonden eerst naar de hacker?

Zie nog steeds geen bronvermelding, ben wel benieuwt naar het complete verhaal.