ugrás a tartalomhoz

Using HTTPS Properly

MadBence · 2016. Már. 11. (P), 01.47
A HTTPS helyes használata
 ■
1

Hamis biztonság

Hidvégi Gábor · 2016. Már. 11. (P), 12.08
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.

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.
2

A HTTPS nyilván nem véd meg

MadBence · 2016. Már. 11. (P), 13.16
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).
5

Ez nagyon jó.

Hidvégi Gábor · 2016. Már. 11. (P), 15.54
Ez nagyon jó.
3

Erre megoldás lehet minden

Joó Ádám · 2016. Már. 11. (P), 15.41
Erre megoldás lehet minden harmadik féltől származó tartalom tiltása/validálása


Talány, hogy ez miért nem része máig a böngészők alapfunkcionalitásának.
4

Nem

Hidvégi Gábor · 2016. Már. 11. (P), 15.51
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.
6

Az én víziómban egy

Joó Ádám · 2016. Már. 11. (P), 15.59
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.
7

Túl techie, nagyjából

Hidvégi Gábor · 2016. Már. 11. (P), 16.10
Túl techie, nagyjából hétmilliárd ember nem használná. Egyébként támogatom : )
8

Én egy másik oldalról

visuall · 2016. Nov. 7. (H), 22.56
É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. :)