Come convincere il compagno di squadra a utilizzare una whitelist?

Finalmente, ho trovato un PoC per un attacco XSS. Il componente è vulnerabile quando viene chiamato come di seguito:

http://my-server.com/component?origin=javascript:alert%28%27Hello%20world!%27%29

Dimostra che uno script dannoso può potenzialmente essere eseguito quando l'utente fa clic sul link generato dal componente.

Finalmente il nostro compagno di squadra ha accettato di rafforzare il componente.

Invece di una lista bianca, ha scelto di verificare che il valore origin sia un URL valido.

Finché ti affidi alle informazioni degli utenti in arrivo, non sarai mai completamente protetto / sicuro. Qualsiasi cosa può essere falsificata, alterata, modificata; e, successivamente, il tuo componente è ora compromesso.

Se vuoi seguire la strada della fidelizzazione di alcuni , avrebbe senso inserire nella whitelist. Tuttavia, fare un passo avanti potrebbe essere più ideale: emetti token anziché specificare domini (pensa a come Google Analytics utilizza un numero UA-XXX su mysite.com). Spingere l'amministrazione sul proprio web admin e la possibilità di domini difettosi / vulnerabilità della sicurezza è ora la loro responsabilità.

Per elaborare ulteriormente ciò a cui mi riferisco, invece di avere una whitelist, configura un database di token:

tokens
id       # Primary Key
token    # Unique generated token

Quindi, avere una relazione 1: * in cui è possibile definire origini valide per quella chiave:

origins
id       # Primary key
token_id # Forieign Key, tokens.id
origin   # origin (e.g. google.com)

Quindi crea un token per un cliente specifico (chiunque includa il tuo componente nella sua pagina). Ad esempio, supponiamo di avere il token abc123def456 :

<iframe src="http://server.com/component?key=abc123def456"></iframe>

Qui,iltuocomponenteeseguiràunaricercasullatoservercontrolatuatabellatokenseconvalida.Puoiancheaggiungereulterioricontrollicontrol'intestazioneReferer,maquestodipendedate(elarealizzazionediRefererpotrebbecomunqueesserefalsificata).Ilvalorepredefinitodibahviorsarebbeadeny*,quindidovrestimostrareunapaginachedice"Nessuna origine specificata, per favore configura" (o qualcosa del genere).

Successivamente, accedono alla pagina di amministrazione e aggiungono "abc.com". Ora, il widget diventa:

<iframe src="http://server.com/component?key=abc123def456&origin=abc.com"></iframe>

Ora, lato server, stai convalidando la chiave insieme all'origine (contro la tua whitelist compilata nella tabella origins (associata a quella chiave). Se un hacker dovesse tentare di usarlo (o modificarlo) l'origine (rispetto alla chiave) rimbalzerebbe e mostrerebbe una pagina di errore.

Se decidono di non specificare l'origine, puoi anche configurare un'origine predefinita in modo che ogni volta che includi solo /component?key=abc123def456 , si assuma l'origine predefinita.

O qualcosa del genere

Quando sento parlare di whitelist, mi riporta alla storia dei firewall.

Quando i firewall venivano utilizzati per la prima volta, utilizzavano un "accetta tutto per impostazione predefinita eccetto ciò che è nella lista nera". Ciò ha creato MOLTI problemi per i primi firewall e amministratori sys dal momento che dovevano mantenere proattivamente le minacce e aggiungerle alla lista nera.

Quando l'industria ha realizzato il problema e passato al sistema attuale di "bloccare tutto per impostazione predefinita tranne quello che è autorizzato nella whitelist", questo ha drasticamente ridotto il panorama delle minacce e la pressione sui team di amministrazione di sys.

Usa questa analogia di fronte a questo di nuovo. Questo dovrebbe convincere la maggior parte delle persone.