Strategia di parametrizzazione per l'iniezione di caratteri pericolosi [chiuso]

Question

Strategia di parametrizzazione per l'iniezione di caratteri pericolosi [chiuso]

#1 da (2 voti)
#2 da (1 voti)

-2

Ho un campo di testo di input per accettare l'ID email. Se l'ID email non è inserito dall'utente, Ho una convalida lato client utilizzando Java Script per visualizzare il messaggio di errore che si legge come "Si prega di inserire un ID e-mail valido". Il codice è come,

if(EmailIdIsNull)
{
   error = "Please enter valid email id";
   //Submit this error message to the form
}

Questo modo di gestire il controllo è vulnerabile all'iniezione di caratteri pericolosi. Ad es., È stato modificato "Immettere l'ID e-mail valido" su "%22@27%3ECIMG+SRC%3D.html%22%3E"

La soluzione per questo è stata data come,

"If available, use structured mechanisms that automatically enforce the separation 
between data and code. These mechanisms may be able to provide the relevant quoting,
encoding and validation automatically, instead of relying on the developer to provide
this capability at every point where output is generated"

Sto cercando una spiegazione della soluzione di cui sopra. Inoltre, come si può applicare sopra la soluzione nel mio caso per quanto riguarda il controllo lato client di ID e-mail?

xss csrf injection

posta Vikas V 09.08.2013 - 11:34

fonte

2 risposte

Leggi altre domande sui tag xss csrf injection

I dati della carta di credito su questo sito Web sono considerati sicuri? [chiuso] Come risolvere questo errore in IE: "Il certificato di sicurezza presentato da questo sito Web è stato rilasciato per un indirizzo di un sito Web diverso." [chiuso]

score 2 · Answer 1

Prima di tutto, dovresti mai fare affidamento sul codice lato client per qualsiasi tipo di convalida. È ridicolmente banale ignorare qualsiasi convalida sul lato client.

Al contrario, dovresti sempre disinfettare e sfuggire a qualsiasi input sul lato server. Certo, puoi eseguire la convalida sul lato client per garantire una buona esperienza utente, ma sempre convalidare anche sul tuo server.

Presumo che l'indirizzo email sarà scritto su un database da qualche parte. In tal caso, utilizzare le query parametrizzate anziché SQL dinamico. Questo ti proteggerà dagli attacchi SQL injection. Si dovrebbe sfuggire ai dati quando si esegue l'output per evitare attacchi XSS. XSS e Injection SQL i cheatsheets di prevenzione da OWASP sono utili riferimenti qui.

score 1 · Answer 2

Le query parametrizzate o le istruzioni preparate sono un esempio di "meccanismi che applicano automaticamente la separazione tra dati e codice".

Il problema quando non ci sono separazione tra dati e codice è che i dati introdotti da un utente possono essere iniettati nel codice e può manipolare l'applicazione in modi non pensati dal programmatore.

Per altri meccanismi che "forniscono automaticamente quotazione, codifica e convalida rilevanti" puoi cercare informazioni su OWASP ESAPI o Java Spring Security Framework .

La raccomandazione di non "affidarsi allo sviluppatore per fornire questa capacità in ogni punto in cui l'output è generato" è perché se si fa affidamento su un umano probabilmente si avranno degli errori. Se utilizzi un'API centralizzata che impedisce ai programmatori di perdere una convalida dell'input, sarai più sicuro.