Un servizio di creazione di PDF è vulnerabile per l'iniezione di codice dannoso

Naviga le tue risposte
4

Abbiamo una relazione nella nostra applicazione Web che viene mostrata in formato tabellare in HTML. Questo rapporto ha la possibilità di essere scaricato come PDF facendo clic sul pulsante download as PDF . La domanda riguarda il modo in cui questa disposizione per il download di PDF viene implementata. Mi è stato detto di scrivere un servizio di back-end in grado di convertire la stringa HTML grezza in PDF scaricabile. Per convertire l'HTML in PDF utilizziamo la libreria The Flying Saucer per Java. Ora il modo in cui questo dovrebbe funzionare è che otterrò contenuti HTML grezzi come stringhe come: 

<table id="new-table">
    <thead>
        <tr>
            <th class="model">Column 1</th>
            <th class="description">Column 2</th>
            <th class="quantity">Column-3</th>
            <th class="listDollars">Column-4</th>
            <th class="payout">Column-5</th>
    </thead>
    <tbody>
        <tr id="row-H2285" style="background: #FFFFFF;" class="modelRow">
            <td class="model">H2285</td>
            <td class="description">F125</td>
            <td>16</td>
            <td class="list"></td>
            <td class="Percent">... and so on

Dal front-end nei parametri di richiesta e devo convertire questa stringa HTML usando il disco volante e restituire un file PDF. La mia domanda è che c'è un modo in cui un utente malintenzionato può iniettare codice dannoso all'interno di questo contenuto HTML e inviarlo al servizio di back-end? Quale potrebbe essere dannoso per chiunque apra il file PDF?

Ho cercato su Google problemi di sicurezza nella libreria dei dischi volanti ma non ho trovato nulla. Ma ho trovato questa domanda da questo stesso sito su Come iniettare codice dannoso in pdf o jpeg e ce n'è un altro Rilevamento di javascript dannosi in PDF

    
posta Aditya Cherla 20.06.2017 - 12:37
fonte

3 risposte

4

Ho lavorato con molte librerie PDF (non questa esattamente però) principalmente in .NET e se fatte correttamente vanno bene. Se si è preoccupati che l'HTML del client sia rinviato al server ed è stato manipolato, allora un possibile suggerimento è che si esegue il rendering di una versione HTML separata nel back-end in modo specifico per la libreria PDF da utilizzare. Questo non è quindi reso al cliente e non è soggetto alla manipolazione del client.

    
risposta data 20.06.2017 - 13:21
fonte
4

  1. Assicurati che i tuoi servizi web non siano suscettibili alle iniezioni XSS.

  2. Devi trovare i modi per prevenire gli abusi (dal momento che diventano servizi web), ad es. usa il controllo delle chiavi API, per impedire a chiunque di caricare qualsiasi file HTML con javascript dannoso nel tuo generatore di PDF.

risposta data 20.06.2017 - 13:55
fonte
3

Senza rivedere l'intera fonte della libreria in questione e in ogni altro luogo, il PDF potrebbe essere concepito e valutato in base al suo contenuto (caricato su un altro servizio che analizza il contenuto o esegue l'OCR, ecc.), non c'è davvero alcun modo di conoscendo.

La chiave qui è che devi disinfettare gli input utente non appena li ricevi indipendentemente dal fatto che tu creda in questa libreria. Il tuo obiettivo come sviluppatore deve essere, "se qualcuno di cui non mi fido mi dà una stringa potenzialmente esplosiva, anche se posso gestirlo in sicurezza, ho bisogno di disinnescarlo prima che qualcuno che non lo conosca lo faccia esplodere accidentalmente."

Che qualcuno possa essere un altro strumento nella tua pipeline di elaborazione dei dati che valuta felicemente una stringa dannosa o il lettore PDF del cliente. Ad ogni modo, è un daywrecker.

Sfuggi alle tue stringhe! Esistono molti modi per disinfettare l'input dell'utente. Non sono un esperto di Java quindi non li conosco tutti, ma se è il tuo lavoro di giorno, certamente dovresti.

    
risposta data 20.06.2017 - 16:59
fonte

Leggi altre domande sui tag

Quale assemblea dovrei imparare? [chiuso] Come proteggersi dalle backdoor nei router?