Vulnerabilita' in modulo Prestashop

[U235]

Se non ho capito male loro cercano di far fare la chiamata ajax dal client del dominio del cliente (il tuo amico) al loro server. Se è così allora è ovvio che non funzionerà l'autenticazione... Ma far processare la richiesta tra server e server faceva schifo?

[Little Hawk]

Se non ho capito male loro cercano di far fare la chiamata ajax dal client del dominio del cliente (il tuo amico) al loro server. Se è così allora è ovvio che non funzionerà l'autenticazione... Ma far processare la richiesta tra server e server faceva schifo?

No, la chiamata al loro web service E' fatta server side. Ma lo script che se ne occupa viene eseguito con un codice prodotto come parametro e puo' essere ovviamente eseguito direttamente anche nel browser se sai dov'e' - che non ci vuole molto a trovarlo - a meno di bloccare appositamente l'esecuzione diretta da quella directory.

Cmq per quanto riguarda la comunicazione tra domini client side, con configurazione opportuna per CORS (Cross-Origin Resource Sharing) e' possibile ovviare alla Same Origin Policy. Per cross-domain communication c'e' anche il vecchio methodo JSONP, pero' e' limitato a GET requests ed e' poco sicuro perche' esegui nella tua app JavaScript proveniente dall'altro dominio, quindi devi fidarti parecchio. Invece e' meglio scambiare dati soltanto con CORS.

Per l'autenticazione poi puoi usare JSON Web Tokens. Dunque, diciamo che vuoi che dominioA esegua requests verso dominioB:

1 - l'app in dominioA, attraverso il browser, fa una 'preflight' request di tipo OPTIONS verso dominioB per verificare se puo' accedere alla risorsa richiesta e con HTTP method voluto (GET, POST, PATCH, PUT, DELETE)

2 - dominioB, opportunamente configurato per CORS, risponde dicendo se la risorsa e' disponibile a dominioA (oppure a tutti con '*') e se una richiesta puo' essere eseguita col metodo HTTP specificato

3 - dominioA esegue la richiesta vera e propria se gli e' consentito

Per l'autenticazione,

1 - dominioA fa una richiesta a dominio B (di solito una POST verso una route tipo /sessions o qualcosa del genere con una API REST) passando username e password come parametri o meglio attraverso gli request headers.

2 - dominioB risponde con un JSON Web Token criptato che contiene informazioni necessarie ad identificare il client nelle richieste successive.

3 - dominioA conserva il JSON Web Token nei suoi cookie oppure nel local storage del browser, e lo appende ad ogni successiva richiesta di solito negli headers.

Questa e' una tecnica molto valida che uso molto e consente di effettuare XMLHttp requests verso l'API di un altro dominio (dico dominio per semplificare perche' in realta' la Same Origin Policy tiene conto anche di HTTP scheme e porta).

Contrariamente a quanto in moltissimi pensano, e' persino possibile la comunicazione cross domain totalmente client side (quindi non "dominioA nel browser e API di dominioB"), ad esempio con una pagina su dominioA contenente una pagina di dominioB in un iframe. Ci sono almeno due trucchetti per lo scambio di dati: il window.name transport e il fragment identifier....

E' un topic molto vasto ed interessante

[MItaly]

Dunque ho seguito il vostro consiglio e ho suggerito al mio amico di contattarli a proposito di quel problema e altro. Ecco cosa gli hanno risposto:

"[...] Tenete conto che come da ABC di Ajax e Sicurezza in ambienti Ajax nessuno dovrebbe venire a conoscenza di URL "sensibili".

Tenete conto che inoltre il fatto che il modulo sia creato in PHP e vi dia accesso al codice non vi autorizza a fare reverse engineering , questo "è molto grave". Possiamo accettare che vogliate un maggiore livello di sicurezza ma non accetteremo altre osservazioni relative al codice che è coperto dai diritti d'autore."

LOL security through obscurity. Questi non sanno neanche cosa significano sicurezza e reverse engineering.

Vi rendete conto di che razza di gente questa e'? Questi si meritano che gli butti giu' i loro sistemi. Che deficienti.

L'istinto dice sputtanamento pubblico istantaneo, la ragione dice "responsible disclosure". Io gli risponderei che una risposta del genere non è accettabile, e che, in linea con le normali pratiche in fatto di sicurezza (inserire come prezzemolo i termini "industry standard" e "recognized best practices"), hanno un mese per patchare la vulnerabilità, dopodiché scatta la disclosure e son cazzi loro, si divertano a vedersela con gli script kiddies di tutto il mondo.

[U235]

...

E' un topic molto vasto ed interessante

Già
Comunque ovviamente intendevo con autenticazione tradizionale interno al dominio. Chiaro che se usi un token o giochini vari fai come ti pare.
In ogni caso perchè stressarsi tanto se lo puoi fare facile facile tra server e server visto che tanto già comunicano così?
Ma la vera domanda è: se non c'è neppure la scusante della "difficoltà" a fare con l'autenticazione, perchè non mettere un controllino anche solo del piffero? poi senza dover nemmeno andare tanto lontano per recuperare quel url, danno anche il sorgente... che cosa vorrebbero nascondere?