quando uscire dall'input dell'utente

Question

quando uscire dall'input dell'utente

#1 da (11 voti)
#2 da (0 voti)

5

Mi chiedo quando è il modo migliore per gestire l'input dell'utente in uscita.

Mi vengono in mente due opzioni

1) L'utente invia i dati al server, noi lo sfuggono e poi li memorizziamo nel database 2) memorizziamo i dati così come sono e li evadiamo quando inviamo i dati all'utente.

Per me sembra molto più facile scappare e quindi salvare i dati nel database, ma supponiamo che qualcuno trovi flusso nel nostro sito Web e riesca a evitare la fuga abbiamo un problema di trovare tutti i dati che abbiamo archiviato nel database senza escape

d'altra parte se archiviamo semplicemente i dati così come sono ma li evitiamo una volta che li inviamo all'utente, anche se qualcuno trova flusso nel nostro sito tutto ciò che dobbiamo fare è correggere un errore poiché il nostro sistema presuppone già che i dati salvati nel database in non sfuggito.

Anche se il secondo approccio sembra più semplice, sembra molto più incline all'errore. Supponiamo di generare HTML sul server e inviarlo all'utente, quindi decidere di passare semplicemente all'invio di contenuti all'utente tramite ajax, è facile dimenticare che è necessario sfuggire a tutti i dati prima di inviarli all'utente o implementare nuove API o qualcosa del genere terzo.

Quindi mi chiedo quale sia il modo preferibile per gestirlo?

web-application attack-prevention

posta D.L 10.03.2013 - 23:15

fonte

2 risposte

Leggi altre domande sui tag web-application attack-prevention

Usando 'sudo vim' per generare una shell L'associazione bcrypt-ruby potrebbe essere vulnerabile?

score 11 · Answer 1

L'input dell'utente è una stringa. Escaping è fatto quando vuoi inserire alcuni caratteri in qualche HTML / SQL / Qualunque codice che insista a interpretare alcuni personaggi in funzionalità speciali. Ad esempio, hai un '<' e vuoi che venga mostrato all'utente come "<", ma se incolli brutalmente la stringa all'interno dell'HTML il browser Web sul lato client guarderà "<" e pensa che inizia qualche tag HTML, invece di rappresentare un semplice '<'.

In generale , vuoi mantenere stringhe come stringhe e delegare qualsiasi codifica o escaping a funzioni specializzate che lo fanno bene. Ad esempio, per SQL, utilizzi istruzioni preparate . Con HTML da un contesto PHP, dovresti usare htmlspecialchars() .

Il punto da notare qui è che il tipo di conversione, codifica o escaping che è necessario eseguire dipende da cosa si sta tentando di fare con la stringa. Se hai bisogno della stringa per inserirla in un codice HTML, utilizzerai le entità HTML (il < per "<" e così via). Se memorizzi nel database la stringa già scappata , allora stai scommettendo che userai la stringa solo includendola in qualche HTML.

Quindi dovresti sforzarti di applicare la codifica / escaping solo dopo l'uso. È più flessibile e semplifica la semantica. All'interno del tuo database, memorizza la stringa come una stringa.

score 0 · Answer 2

EDIT: Luc ha sottolineato nel concetto che sono indebitamente inclinato verso soluzioni ad alte prestazioni. Se, nella tua situazione, le prestazioni non sono un problema, allora è perfettamente accettabile (e preferibile, di fatto) archiviare i dati originali da soli e trasformarli in output. Ciò ti dà la flessibilità di utilizzare i dati, indipendentemente dal fatto che tu abbia bisogno di te senza mantenere le versioni.

Risposta originale qui sotto -------------------------------------------- ----------

In una certa misura, dipende. In primo luogo, la risposta è raramente per memorizzare i dati grezzi e sfuggirli quando li leggi di nuovo.

Le due soluzioni comuni sono:

1) Sfuggi i dati prima di memorizzarli.

2) Memorizza due copie dei dati, una con escape e una raw.

In quasi tutti i sistemi, il rapporto tra letture e scritture sarà pesante, strongmente inclinato verso le letture. Potrebbe essere 10: 1, ma potrebbe essere 10.000: 1. Questo è il motivo per cui desideri archiviare i dati in un formato di escape e analizzarli solo quando lo stai scrivendo, non tutte le volte che vuoi leggerlo.

Il vantaggio di archiviare entrambi i formati è che l'autore originale può modificare il contenuto come previsto, puoi rielaborarlo se vuoi, puoi rivedere i dati originali ... Ti dà una certa flessibilità aggiuntiva a scapito di un po 'di complessità aggiuntiva.

Ovviamente è un po 'semplicistico, perché ad esempio non sto considerando gli effetti del caching sul rapporto lettura / scrittura, ma si spera che trasmetta il concetto generale.