Furthermore, as a user, I don’t have any way of knowing which parts of this page are trustworthy and which are not. As a consequence, attacker-injected script on this page could ask for a password, and a reasonable person would probably type it. I groaned at spending 20 minutes mocking this up, but it turned out that I don’t even have to… the original HTTP page itself can ask for the password!
(...)
There’s no way for the user to know whether this is a legitimate password prompt which will securely handle the user’s password, or a fake injected by an attacker on the network.
Amíg külső scriptet lehet behívni az oldalra, és az lényegtelen, hogy titkosítatlan vagy titkosított protokollon keresztül érkezett, annak hozzáférése van az oldal tartalmához. Így nyugodtan injektálhatnak egy jelszóbekérő formot, ami a támadó https oldalára küld minden adatot.
Erre megoldás lehet minden harmadik féltől származó tartalom tiltása/validálása, vagy például iframe-be kéne betölteni mindent.
Még jobban belegondolva, ez a probléma nem is igazán oldható meg. Esetleg meta tag-ekben fel lehetne sorolni, hogy milyen url-ekre lehet küldeni erről a lapról adatokat, de ez is macerás, mert csak nyers html-ben lenne szabad elfogadni, dinamikusan létrehozott tag-eknél nem.
A HTTPS nyilván nem véd meg attól, hogy maga a szerver kártékony kódot küldjön. Egyébként a Content-Security-Policy header pont ilyesmire való (szabályozható, hogy milyen domainekről milyen tartalmak tölthetőek be).
Annyira azért nem nehéz kitalálni, miért van így. A mostani hirdetési modellek többsége működésképtelen vagy jóval drágább lenne.
A validáláson legalábbis azt értem, hogy például a honlapok gazdái vagy egy általuk megbízott szervezet előbb elemezné a hirdetés kódját/viselkedését, és ha megbízható, akkor mondjuk az oldal szolgálhatná ki. Ezzel például a hirdetésblokkolókat is új kihívások elé lehetne állítani.
Az én víziómban egy kattintással jóváhagyásfüggővé tehetném a harmadik féltől származó tartalmakat, és betöltés közben egy panelen áttekinthetném, mit honnan tervez lekérni az oldal, majd egyenként engedélyezhetném.
Én egy másik oldalról közelíteném meg a problémát. Az általános webkiszolgáló mellett egy különálló, erre a célra fenntartott szervert állítanék csatasorba, aminek a reklámok kiszolgálása lenne a feladata (adott doménen). Ha ezt a szabványban rögzítenék, többfelé el lehetne oszlatni a reklám által termelt bevételt és megszűnnének a monopóliumok (ha számításaim helytállóak).
Namármost, mi van akkor, ha a reklám egy jópofa XSS backdoor?
Csak optimistán! Legalább a hackerek jól járnak. :)
Hamis biztonság
(...)
There’s no way for the user to know whether this is a legitimate password prompt which will securely handle the user’s password, or a fake injected by an attacker on the network.
Erre megoldás lehet minden harmadik féltől származó tartalom tiltása/validálása, vagy például iframe-be kéne betölteni mindent.
Who can stop malware? It starts with advertisers
Még jobban belegondolva, ez a probléma nem is igazán oldható meg. Esetleg meta tag-ekben fel lehetne sorolni, hogy milyen url-ekre lehet küldeni erről a lapról adatokat, de ez is macerás, mert csak nyers html-ben lenne szabad elfogadni, dinamikusan létrehozott tag-eknél nem.
A HTTPS nyilván nem véd meg
Content-Security-Policy
header pont ilyesmire való (szabályozható, hogy milyen domainekről milyen tartalmak tölthetőek be).Ez nagyon jó.
Erre megoldás lehet minden
Talány, hogy ez miért nem része máig a böngészők alapfunkcionalitásának.
Nem
A validáláson legalábbis azt értem, hogy például a honlapok gazdái vagy egy általuk megbízott szervezet előbb elemezné a hirdetés kódját/viselkedését, és ha megbízható, akkor mondjuk az oldal szolgálhatná ki. Ezzel például a hirdetésblokkolókat is új kihívások elé lehetne állítani.
Az én víziómban egy
Túl techie, nagyjából
Én egy másik oldalról
Namármost, mi van akkor, ha a reklám egy jópofa XSS backdoor?
Csak optimistán! Legalább a hackerek jól járnak. :)