a szerzőnek láthatólag fogalma sincs róla, mi az a path traversal (a weboldaltól független fájlok, pl. a /etc/passwd elérése ../ és hasonló trükkök használatával, ha a weboldal egy request paraméterként kapott útvonal alapján tölt be egy fájlt), és a CSRF-et se érti igazán. (Vagy én nem értem, hogy mit jelent az, hogy "You could even use ... a script on another server to do the POST request from the back-end." A CSRF lényege pont az, hogy a te gépedről megy el a request, ezért a süti-alapú biztonsági modell nem tudja megkülönböztetni a valóban általad kezdeményezett requestektől.)
A script az oldalba van beágyazva, de egy távoli szerverről van betöltve, mivel a böngészők egyenlőre nem tesznek igazán különbséget a script forrását tekintve - ez remélhetőleg változik a HTML5 vagy az ezt övező technológiák bevezetésével. És a te böngésződ küldi el az üzenetet AJAX POST vagy bármilyen hasonló módon, úgy, hogy ugye hozzáfér a sütijeidhez.
Ennek XSS-nél van értelme, de CSRF-nél nincs, mert azt eleve a támadó kontrollja alatt álló honlapról indítják, ahol olyan formában ágyazza be a scriptet, amilyenben kedve tartja. Ráadásul a cikk a backendről indított POST-ról beszél, ha jól értem, aminek meg aztán végképp nincs sok értelme.
via @Poetro
Nem rossz, de...
Script
script
az oldalba van beágyazva, de egy távoli szerverről van betöltve, mivel a böngészők egyenlőre nem tesznek igazán különbséget ascript
forrását tekintve - ez remélhetőleg változik a HTML5 vagy az ezt övező technológiák bevezetésével. És a te böngésződ küldi el az üzenetet AJAX POST vagy bármilyen hasonló módon, úgy, hogy ugye hozzáfér a sütijeidhez.Ennek XSS-nél van értelme, de