Pen Testing dell'applicazione ASP.NET con Backtrack

5

Abbiamo sviluppato un'applicazione Enterprise basata su ASP.NET che verrà presto rilasciata. Ora, siamo preoccupati per gli aspetti di sicurezza dell'applicazione. Ho esaminato Backtrack 5 e visitato molti siti web anche sui test delle penne, ma non è stato di grande aiuto. Desidero testare l'applicazione sviluppata per le vulnerabilità della sicurezza utilizzando backtrack.

La mia domanda è: come posso testare la mia applicazione utilizzando tutte le funzionalità di Backtrack?

    
posta N.p Subedi 24.05.2013 - 13:08
fonte

1 risposta

7

Collegati sono alcuni video che possono darti un vantaggio: " Esercitazioni sul test della penna per applicazioni Web " tuttavia, l'attivazione di uno o due strumenti in un'applicazione non è un meccanismo affidabile per garantire la sicurezza. Dal momento che hai affermato: "abbiamo sviluppato un'applicazione Enterprise basata su ASP.NET", il tuo miglior risultato è lavorare usando dire Agile o altri CAS di TEST basati su SDLC e creare i tuoi casi di ERRORE. Link: " Sicurezza del software, uso improprio, Iniezione di errori "

Il ragionamento / razionale dietro questo commento è, tu (la società, gli sviluppatori, ecc.) sono quelli che hanno fatto l'applicazione. Sai (hai documentato) come dovrebbe funzionare e cosa NON dovrebbe fare. È possibile creare attacchi "appositamente mirati" contro la propria applicazione che possono produrre risultati migliori.

Il problema con gli strumenti sono, sono pre-programmati con "conosciuti". Gli attacchi e gli assalitori si evolvono tutti. Quindi affidarsi a uno strumento può lasciarti vulnerabile se l'autore dello strumento non fosse a conoscenza di una nuova minaccia. Questo è stato il problema con JAVA di recente dove c'erano problemi, Oracle avrebbe sandbox, un utente malintenzionato lo avrebbe interrotto di nuovo, lo avrebbero corretto, e un altro utente avrebbe interrotto di nuovo anche quello.

Per qualcosa di simile a questo (test delle applicazioni), è una cosa molto ampia. È possibile utilizzare fuzzer, strumenti di rete e un buffet di tutto e di tutto, e ancora sbagliare. Vale la pena iniziare da zero:

What does my tool do (test case)
How can someone abuse that my tool is supposed to do? (misuse/abuse case)

per esempio:.

Test Case 1: Application takes input from user (a name)
Misuse Case 1: Rogue user tries to enter something other than a name (unicode, hex, etc.)

A CURA

Ho deciso di ripubblicarlo perché vedo la risposta "assumi un professionista". Mentre ciò sarebbe una cosa migliore da fare poiché i "professionisti" tendono ad essere meglio equipaggiati ed esperti per affrontare questo, anche loro possono fallire. Un approccio basato su SDLC dovrebbe essere in prima linea nello sviluppo di codice sicuro. Test contro (assunzione di un professionista) questa pratica SDLC dovrebbe venire secondaria. C'è una differenza enorme nei test di penetrazione e sicurezza delle applicazioni. Vedi: " Scrittura del codice protetto "

    
risposta data 24.05.2013 - 15:46
fonte

Leggi altre domande sui tag