Riguardo allo scripting cross-site?

5

La mia applicazione ha un modulo di gestione utenti che utilizza campi come username, nome, email-id, password, ... Ho provato a eseguire la scansione di questi campi e compilare JavaScript dannoso per testare lo scripting cross-site come anil<script>alert(1);</alert> . I dati modificati sono memorizzati nel database, ma quando aggiorno la pagina, non vedo alcun messaggio popup. Come posso assicurarmi di non essere vulnerabile per Cross Site Scripting?

    
posta lakshmi Prudhvi 01.07.2013 - 14:23
fonte

4 risposte

10

Purtroppo i test per Cross-Site Scripting non sono completamente semplici. A seconda di dove viene restituito l'input, potrebbe essere necessario utilizzare un numero di vettori diversi per testarlo completamente.

Se vuoi utilizzare uno strumento automatico per rivedere il tuo sito, qualcosa come arachni potrebbe essere una buona idea, o un rutto scanner di pro se ne hai accesso.

Da una prospettiva manuale, puoi avere un'idea della gamma di possibili vettori dall'elenco html5sec

    
risposta data 01.07.2013 - 15:24
fonte
8

Ciò che stai facendo dipende da due cose che accadono

  1. Sei in grado di caricare javascript nel datastore in cui tale javascript verrà visualizzato da un utente.
  2. Quando viene eseguito il rendering di tale JavaScript dal browser dell'utente,

Gli sviluppatori dovrebbero controllare l'input per cose cattive, assicurarsi che l'input sia codificato in html e rifiutare le cose cattive come il markup. D'altra parte lo sviluppatore dovrebbe assicurarsi che tutto ciò che è stato fatto nel database venga reso innocuo.

Il fatto che tu sia in grado di ottenere javascript nel database mi dice che gli sviluppatori non hanno fatto un buon lavoro di controllo dell'input e hanno bisogno di risolverlo . Non ho mai incontrato qualcuno che abbia tag html nel loro nome :)

Il fatto che non venga eseguito sull'altro lato mi dice che il framework che usano probabilmente codifica l'output in modo da renderlo innocuo nella maggior parte dei casi. Sono disposto a scommettere se davvero provi a fare qualcosa per poter codificare che sei javascript in un modo che puoi far funzionare. Devi assicurarti di controllare l'input ogni e ogni . Gli strumenti automatici sono buoni e tutti, ma sono solo un punto di partenza.

Spero che questo aiuti!

    
risposta data 01.07.2013 - 15:42
fonte
1

Esistono tre approcci di base per i test di sicurezza, come per qualsiasi altro test. Questa è la struttura che ho messo insieme per la società Fortune 500 in cui sono responsabile della definizione della strategia di test di sicurezza. Questo è basato su pratiche di test standard QE / QA, solo ampliate per affrontare le funzionalità di "sicurezza".

  1. Assumi esperti. Sono molto costosi e generalmente non testano l'intero prodotto. Oppure, se testano l'intero prodotto, è assurdamente costoso.

  2. Test automatici, utilizzando scanner. Questo ti copre per la più basilare delle vulnerabilità, ma gli scanner sono stupidi e mancano un lotto .

  3. Verifica del corretto funzionamento del prodotto con unità, integrazione e test di sistema. I codificatori codificano correttamente l'output per le varie posizioni in cui si verifica l'XSS (javascript, html, css, urls, ecc.)? Hai una struttura dell'interfaccia utente? Il framework UI utilizza correttamente gli encoder in tutte le posizioni in cui è scritto l'output (inclusi i normali messaggi di output e di errore)? Il framework UI è chiamato in modo coerente in tutta l'applicazione?

risposta data 01.07.2013 - 18:11
fonte
-1

Puoi testare le vulnerabilità XSS da solo. Prima di tutto capisci che ci sono 3 tipi di attacchi XSS

  • XSS persistente
  • XSS non persistente
  • Vulnerabilità basata su Dom

Puoi controllare la wiki OWASP per ulteriori informazioni

Se non sei pronto per leggere, puoi provare alcuni strumenti disponibili online come Xsser

    
risposta data 01.07.2013 - 19:43
fonte

Leggi altre domande sui tag