Come ridurre l'attraversamento della directory quando l'input fornito dall'utente è un caso aziendale obbligatorio?

2

Ho un'istanza in cui abbiamo un'applicazione che richiede la possibilità di impostare comandi sftp che sono specificati dagli utenti amministrativi. Sono configurati attraverso il front-end dell'applicazione. Veracode ha identificato correttamente un attacco di directory trasversale qui.

Lavoro per un'azienda B2B, e questo processo sftp è per i nostri clienti per inviare / ricevere file specificando strutture di directory sul proprio sistema.

La connessione viene gestita tramite un'API e la libreria corrente scappa correttamente i dati come input (cioè se invio "../ & rm *" viene trattato come una directory su "cd". Il file di destinazione essere copiati è controllato esplicitamente dal sistema - ma ciò non significa che sia sempre il caso.

Ma a parte la blacklist di certi percorsi di directory come "../" mi sono perso riguardo ad altre strategie a livello di applicazione che posso usare per prevenire questo attacco.

Informazioni aggiuntive

Potrei avere problemi di comunicazione: il problema è che la nostra applicazione viene eseguita sui nostri server come propria istanza. Le carceri di Chroot vanno bene per noi, ma per quanto riguarda il server del cliente? La logica aziendale è che depositeremo i file su una directory su un sistema che specificano. Non abbiamo alcun controllo su questo, e dovrebbero avere la flessibilità per essere in grado di specificare con precisione quale directory vogliono che la nostra applicazione depositi i propri file.

Non mi piacciono gli approcci alla lista nera perché non sai mai cosa ti sei perso. E in teoria, questo processo potrebbe essere impostato per puntare a una casella di Windows invece di una casella unix, e quindi ci sono due serie di regole della lista nera che devi improvvisamente codificare per - per non parlare del rilevamento dell'ambiente sul server remoto.

    
posta avgvstvs 21.03.2014 - 17:52
fonte

2 risposte

2
  1. recluse di chroot. Ogni client deve connettersi a una gerarchia di directory che non può essere attraversata a a) il sistema o b) altri client.
  2. Convalida dell'input. Sì, dovresti mettere in blacklist cose come ../, $, *, ecc. Se hai il controllo sull'API, puoi fare ancora meglio, come test dell'esistenza della directory prima di provare a passarlo su cd. Come la programmazione difensiva va, questa non è scienza missilistica, quindi sì, c'è un po 'di fatica, ma è la cosa giusta da fare.
risposta data 21.03.2014 - 19:49
fonte
1

La seguente logica tipicamente protegge contro l'attraversamento di directory:

  • la directory / nomefile dovrebbe essere espansa al suo assoluto + percorso canonico che risolve ../ e così via, vedi getCanonicalPath
  • confronta il percorso con una whitelist dei percorsi consentiti

Nessuna lista nera coinvolta.

Non sono sicuro di comprendere appieno il tuo caso o la tua preoccupazione specifica, ma quanto sopra tende a funzionare per un gran numero di casi d'uso.

    
risposta data 21.03.2014 - 20:42
fonte