Diskusia – Obrana proti útoku XSS v PHP

ini_set("session.cookie_httponly", 1);

A co brání útočníkovi podvrhnout hlavičky HTTP?

header('Strict-Transport-Security: max-age=63072000');

A pokud chceš na subdomény tak přidáš parametr includeSubDoma­ins.

Tady jde o to, že tu cookie potom nevidíš z JavaScriptu. A když uděláš z injektovaného skriptu AJAX request na jinou doménu, tak se tam nepošle, protože to není ta doména ze které byla uložena. Jak jsi to myslel? Nenapadá mě způsob jak ji ze skriptu načíst.

ale co když požadavek neposílá webový prohlížeč ale aplikace v C# přestrojena za prohlížeč?

To bys ji musel dostat k tomu administrátorovi. Tady jde o to, že přes XSS dostaneš nějaký skript k němu a on ti odešle jeho cookies.

V každém případě:

ini_set("sessi­on.cookie_httpon­ly", 1);

není dostatečná obrana proti session hijackingu.
____
Mírně opožděná reakce, omlouvám se, dlouho jsem tu nebyl.

Ahoj, samozřejmě že ne. Ale direktivy jako session.cooki­e_secure asi moc lidí používat nebude, protože slouží jen pro https.

Dále session.use_on­ly_cookies, které je již zapnuto od 5.3.0, takže se o to nemá cenu starat.

V případě, že by ti někdo chtěl ukrást session, využil by právě session.cooki­e_httponly direktivy.

Samozřejmě je dobré také regenerovat session. Nicméně je třeba implementovat časovač.

Dále můžeš využít session.use_stric­t_mode direktivu, ale ta je relativně zbytečná, pokud regeneruješ session.

Jako poslední používám vlastní názvy pro session. Nicméně, nedočetl jsem se, že by toho někdo někdy využil pro krádež session

Tím jsem chtěl říct, že session hijacking je zase jiné téma než XSS a obsáhlo by jistě několik článků

session.cooki­e_secure pokud vím slouží pro to, aby cookie nebyla viditelná, pokud se jedná o spojení http. Čili jakožto obrana proti session hijackingu neslouží. Možná si jen nedokážu představit jak to myslíš.

Měl jsem na mysli XMLHttpRequest a metodu getAllResponse­Headers, ale tohle je celkem známá chyba takže ji už asi ošetřili.

V případě http spojení vždy hrozí MITM, proto se využívá ohlídání IP adresy
(IP adresa při přihlášení by měla být shodná s IP ze které chodí všechny požadavky), kde je problém pokud se uživateli tato adresa během relace mění (znám takové případy -> nic neobvyklého).
Nebo hlavička User-agent, tady je ale problém, kdy je na scéně omezený počet prohlížečů a útočníkovy nedělá až taký problém zkusit se kterým se do systému dostane

Pokud máš nastaveno session.cooki­e_secure, tak se ti session přenesou pouze přes HTTPS, jinak ne. Můžeš si to zkusit na webu pouze s HTTP. Stále to považuji za jakousi ochranu session proti odcizení.

Jistě, v HTTP hrozí sniffování paketů, ale to je zase jiný problém, který můžeš vyřešit pomocí HTTPS, HSTS nebo preload listu.

To jsme odbočili už docela hodně od XSS
Pokud bych se chtěl držet XSS, tak mi v článku dost chybí zmínění o CSP.

jn... Mám v plánu si zažádat o redaktorské práva na odborné články zaměřených na webovou bezpečnost. U článku o Clickjackingu bych se o něm zmínil v souvislosti s FRAME-ANCESTORS.
__________
Možná by to ode mě bylo i sprosté, ale chtěl bych zdejší články o PHP - Bazpečnosti mírně poupravit. Ale na to bych se musel domluvit s autorem, netušíš jestli je ještě aktivní?