ERR_BLOCKED_BY_XSS_AUDITOR in Google Chome - Come risolvere

Con l'uscita della recente versione 57 del browser Google Chrome la funzionalità di XSS auditing ha subito alcuni importanti miglioramenti, che di certo comporteranno una maggiore protezione per gli utenti più inclini ad essere soggetti ad attacchi di tipo XSS (Cross-Site Scripting - se non sapete di cosa si tratta, leggete qui). Sfortunatamente, questa modifica ha comportato anche il malfunzionamento di alcuni servizi online, che da qualche settimana restituiscono il seguente errore HTTP:

ERR_BLOCKED_BY_XSS_AUDITOR

Il problema è quasi sempre legato alla presenza di un contenuto HTML inviato tramite POST all'interno di una request tramite form o AJAX, tecnica utilizzata da servizi anche molto diffusi nel panorama web moderno - editor WYSIWYG, uploader interattivi, strumenti di real-time editing tipici di molti CMS e così via.

La domanda a questo punto nasce spontanea: come risolvere questo problema e ripristinare il funzionamento del servizio?

Nel caso in cui si tratti di uno strumento sviluppato da terze parti, la cosa migliore da fare è probabilmente segnalare la funzionalità agli sviluppatori e/o controllare se esiste una patch recente in grado di risolvere il problema. Se questo tentativo non si rivela efficace, o se il problema si verifica su uno script o servizio sviluppato da noi, occorre invece rimboccarsi le maniche e darsi da fare per risolvere il problema. E' quanto mi è toccato fare la settimana scorsa, quando mi sono trovato a dover applicare un fix d'urgenza a uno strumento che avevo sviluppato per un amico qualche tempo fa: un viewer di fatture elettroniche in grado di interpretare - e mostrare a schermo - il formato più recente previsto dagli standard della Pubblica Amministrazione, rilasciato al pubblico nel 2016 e già utilizzato da moltissime aziende e professionisti in Italia.

A dare problemi, nello specifico, era la singolare implementazione che avevo ideato per gestire la selezione del file da inviare in upload tramite drag-e-drop, non potendo utilizzare la funzionalità nativa HTML5  poiché incompatibile con IE < 10: per farla breve, lo script utilizza una chiamata AJAX al momento del drop per ottenere il contenuto completo della pagina di destinazione, che poi "restituisce" alla pagina server-side all'interno della POST request di invio, che avviene immediatamente dopo. L'HTML inviato viene quindi restituito come response.

... Lo so, mi rendo conto che non si tratta di una soluzione particolarmente elegante: tuttavia, viste le limitazioni dell'elemento HTML input type="file", unite alle clamorose limitazioni dovute ai criteri di sicurezza predefiniti dei vari browser, si tratta di un workaround che se non altro sortisce l'effetto sperato... Fino a pochi giorni fa, almeno, quando ha improvvisamente incominciato a restituire l'errore di cui sopra.

Dopo una breve ricerca volta a cercare un modo per risolvere il problema mi sono finalmente imbattuto in  questo articolo che, oltre a fare un pò di luce sulla situazione, mi ha spinto verso la giusta direzione. Stando a quanto dice l'autore del post, il modo più semplice ed efficace per risolvere il problema è aggiungere questo header nel response:

Questo può essere ottenuto in vari modi, a seconda della tecnologia server-side utilizzata. Ad esempio:

ASP.NET

Aggiungere questa sezione all'interno del file Web.Config:

In alternativa è possibile aggiungere una istruzione di questo tipo:

all'interno del relativo Controller MVC, pagina ASPX o altro endpoint che si occupa di preparare la response.

PHP

In modo molto simile alla seconda alternativa descritta per ASP.NET è possibile utilizzare la funzione Header nel seguente modo:

... E così via.

Sfortunatamente questo approccio, nel mio caso specifico, non ha sortito alcun effetto. A quel punto ho pensato che avrei potuto effettuare un encoding del contenuto HTML  in un formato meno sospetto per l'XSS Auditor, come ad esempio il sempre valido schema Base64: ho quindi scaricato l'ottimo plugin jQuery-base64 (un grazie sincero all'autore Tao Klerks) e l'ho aggiunto al codice HTML della mia pagina all'interno di un classico elemento <script> all'interno del blocco <head> della pagina. Una volta fatto questo ho potuto procedere all'encoding del mio contenuto HTML subito dopo il POST nel seguente modo:

Le modifiche al codice PHP sono state ancora più semplici, in quanto ho potuto contare sulla funzionalità nativa fornita dal metodo base64_decode nel seguente modo:

... E questo è stato sufficiente per liberarmi dall'errore ERR_BLOCKED_BY_XSS_AUDITOR.

Spero che questo breve resoconto possa essere d'aiuto a quanti si troveranno a dover risolvere lo stesso problema.

Per il momento è tutto: felice sviluppo!