Protezione delle caselle a discesa

È molto importante per te capire che TUTTI gli input degli utenti devono essere disinfettati in un modo o nell'altro, o che si sta aprendo potenzialmente per delle falle nella sicurezza. Qualsiasi input potrebbe significare caselle a discesa o altri dati che si penserebbero statici. Esempi di questo è semplicemente qualsiasi cosa restituita dall'utente come ad esempio:

• Pulsanti di opzione
• Casella a discesa
• Dati provenienti da plug-in come flash, silverlight e così via.
• Semplicemente tutto ciò che viene inviato al client!

Per illustrare meglio questo aspetto, ti incoraggio a scaricare un semplice proxy che ti consentirà di mostrare tutti i dati inviati al tuo server quando invii un modulo. Qui viene mostrata una richiesta POST di esempio:

POST /api/rest HTTP/1.1
Host: api.example.com
User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)
Referer: example.com/admin.php
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Cookie: username=karrax&password=855425718dfe4a50f6f0bbb9335d3c3b&userid=591

dropdownBox=string&staticTextField=string&hiddenElement=string

Tutto ciò che devi fare affidamento sulla tua logica di business proveniente dal lato client deve essere pulito .

Ricorda che questo vale per qualsiasi cosa venga dal lato client. NON PUOI FIDARTI! ... Anche se è semplicemente una stringa che viene restituita al client (ad esempio un nome utente), dovrebbe essere pulita in modo che non sia vulnerabile per lo scripting cross-site e altri vettori di attacco.

Modifica : come sottolineato da @Avid nei commenti, è anche fondamentale sapere che i dati trasmessi attraverso i cookie vengono inviati anche dal lato client, rendendoli vulnerabili alle manomissioni. Questo vale anche per qualsiasi altro campo nelle intestazioni (o qualsiasi cosa proveniente dal client) come il campo utente-referente o referente per nominarne alcuni.

Nell'esempio sopra la richiesta HTTP potrebbe sventare alcuni sistemi di sicurezza se si affidano al campo referrer per autorizzare ad esempio l'utente. L'esempio mostra anche che è il Google Bot che in alcune circostanze può fornire contenuti diversi nella pagina che stai richiedendo ( fonte ).

È necessario implementare alcune regole di business sul server, che include la convalida dell'input sul lato server. Non lasciare mai che il flusso di input del browser entri direttamente nel tuo database.

Se vuoi eseguire una convalida lato client anche ( non invece di! ) sul lato server per migliorare le prestazioni o l'usabilità, allora fallo con tutti i mezzi . Ma se non stai convalidando sul server, in realtà non stai convalidando i dati (come mostrato dal tuo esperimento).

Stai facendo PHP così questa pagina potrebbe avere dei buoni suggerimenti. [I dettagli su come farlo naturalmente dipendono dalla piattaforma del tuo server.]

Torniamo ai primi principi: a cosa stai difendendo?

Se ti stai difendendo da campi non validi inviati alla tua app Web, come tutti gli altri post hanno indicato, un utente malintenzionato non ha bisogno di utilizzare HTML o JS per inviare dati non validi. Possono creare il proprio GET o POST e inviarlo al tuo server (i dati di manomissione del plug-in FF ti permettono di farlo dal browser).

1. Utilizza la convalida del browser per l'usabilità. Questa convalida è facile da aggirare, quindi l'unica ragione per farlo è aumentare la fruibilità del tuo sito aiutando l'utente a inviare valori validi.

2. Convalida lato server, disinfezione, ecc. Tutti i dati inviati devono essere considerati sporchi e un possibile vettore di attacco. Disinfetta i dati inviati prima di usarli per qualsiasi cosa (e usa il tuo DB in modo sicuro - previ SQL injection).