Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
skipfish — Scanner di sicurezza per applicazioni web creato da lcamtuf per google - Mirror non ufficiale | Kitploit
Strumenti/GitHubGitHub/spinkham/skipfish
RicognizioneScanner di VulnerabilitàScanner di Vulnerabilità WebAnalisi Dinamica (Sandboxing)Sfruttamento di Applicazioni WebRaccolta InformazioniSicurezza WebFuzzingPenetration TestingCrawler
GitHubspinkham/skipfish
8721665113 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →

skipfish

Scanner di sicurezza per applicazioni web creato da lcamtuf per google - Mirror non ufficiale

Vedi RepositorySito web
Condividi

skipfish - strumento di scansione della sicurezza delle applicazioni web

http://code.google.com/p/skipfish/

  • Scritto e mantenuto da:

    Michal Zalewski [email protected] Niels Heinen [email protected] Sebastian Roschke [email protected]

  • Copyright 2009 - 2012 Google Inc, tutti i diritti riservati.

  • Rilasciato secondo i termini e le condizioni della Apache License, versione 2.0.


  1. Cos'è skipfish?

Skipfish è uno strumento attivo di ricognizione per la sicurezza delle applicazioni web. Prepara una mappa interattiva del sito preso di mira effettuando una scansione ricorsiva e sonde basate su dizionari. La mappa risultante viene poi annotata con l'output di una serie di controlli di sicurezza attivi (ma, si spera, non disturbanti). Il rapporto finale generato dallo strumento è pensato per servire come base per valutazioni professionali della sicurezza delle applicazioni web.


  1. Perché dovrei interessarmi proprio a questo strumento?

Sono facilmente disponibili numerosi strumenti commerciali e open source con funzionalità analoghe (ad es. Nikto, Nessus); usa quello che preferisci. Detto questo, skipfish cerca di risolvere alcuni dei problemi comuni associati agli scanner di sicurezza web. I vantaggi specifici includono:

  • Alte prestazioni: sono state osservate 500+ richieste al secondo contro target Internet reattivi, 2000+ richieste al secondo su reti LAN / MAN e 7000+ richieste contro istanze locali, con un footprint molto modesto di CPU, rete e memoria. Questo può essere attribuito a:

    • Modello di elaborazione dei dati e I/O di rete completamente asincrono, single-thread e multiplexato, che elimina la gestione della memoria, la pianificazione e le inefficienze IPC presenti in alcuni client multi-thread.

  • Funzionalità avanzate di HTTP/1.1 come richieste di intervallo, compressione dei contenuti e connessioni keep-alive, oltre al forzato limite della dimensione delle risposte, per tenere sotto controllo l'overhead a livello di rete.

  • La cache intelligente delle risposte e le avanzate euristiche sul comportamento dei server vengono utilizzate per ridurre al minimo il traffico non necessario.

  • Implementazione in puro C orientata alle prestazioni, inclusa una pila HTTP personalizzata.

  • Facilità d'uso: skipfish è altamente adattivo e affidabile. Lo scanner offre:

    • Riconoscimento euristico di schemi oscuri di gestione dei parametri basati su percorso e query.

    • Gestione elegante di siti multi-framework in cui determinati percorsi seguono semantica completamente diversa, o sono soggetti a regole di filtraggio differenti.

    • Costruzione automatica della wordlist basata sull'analisi del contenuto del sito.

    • Funzionalità di scansione probabilistica per consentire valutazioni periodiche e con limite di tempo di siti arbitrariamente complessi.

    • Controlli di sicurezza ben progettati: lo strumento ha lo scopo di fornire risultati accurati e significativi:

      • Dizionari artigianali offrono un'ottima copertura e consentono test approfonditi di $keyword.$extension in un lasso di tempo ragionevole.

      • Per rilevare le vulnerabilità, si preferiscono sonde differenziali a tre passaggi rispetto ai controlli tramite firme.

      • La logica in stile ratproxy viene utilizzata per individuare sottili problemi di sicurezza: cross-site request forgery, cross-site script inclusion, contenuti misti, problemi di MIME e incongruenze di charset, direttive di cache errate, ecc.

      • I controlli di sicurezza inclusi sono progettati per gestire scenari complessi: XSS persistenti (percorso, parametri, header), SQL o XML injection ciechi, o shell injection cieca.

      • Firma di contenuti in stile Snort che evidenziano errori del server, fughe di informazioni o applicazioni web potenzialmente pericolose.

      • La post-elaborazione del rapporto riduce drasticamente il rumore causato da eventuali falsi positivi rimanenti o trucchetti del server, identificando modelli ripetitivi.

  • Detto questo, skipfish non è una soluzione magica e potrebbe non essere adatto a determinati scopi. Ad esempio, non soddisfa la maggior parte dei requisiti delineati nel WASC Web Application Security Scanner Evaluation Criteria (alcuni intenzionalmente, altri per necessità); e, a differenza della maggior parte degli altri progetti di questo tipo, non viene fornito con un ampio database di vulnerabilità note per controlli basati su banner.


    1. Interessante! Quali test specifici sono implementati?

    Di seguito è riportato un elenco approssimativo dei controlli di sicurezza offerti dallo strumento.

    • Difetti ad alto rischio (che potrebbero portare al compromissione del sistema):

      • SQL injection lato server (inclusi vettori ciechi, parametri numerici).
      • Sintassi esplicita simile a SQL nei parametri GET o POST.
      • Injection di comandi shell lato server (inclusi vettori ciechi).
      • XML / XPath injection lato server (inclusi vettori ciechi).
      • Vulnerabilità di format string.
      • Vulnerabilità di integer overflow.
      • Percorsi che accettano HTTP PUT.
    • Difetti a rischio medio (che potrebbero portare a compromissione dei dati):

      • Vettori XSS persistenti e riflessi nel corpo del documento (supporto minimale di XSS in JS).
      • Vettori XSS persistenti e riflessi tramite redirect HTTP.
      • Vettori XSS persistenti e riflessi tramite header splitting HTTP.
      • Directory traversal / LFI / RFI (inclusi vettori vincolati).
      • Vari punti di interesse nei file (sorgenti lato server, configurazioni, ecc).
      • Vettori di inclusione di script e CSS forniti dall'attaccante (persistenti e riflessi).
      • Vettori di inclusione di script e CSS esterni non affidabili.
      • Problemi di contenuti misti su risorse script e CSS (opzionale).
      • Moduli password inviati da o verso pagine non SSL (opzionale).
      • Tipi MIME errati o mancanti su elementi renderizzabili.
      • Tipi MIME generici su elementi renderizzabili.
      • Charset errati o mancanti su elementi renderizzabili.
      • Informazioni MIME / charset contrastanti su elementi renderizzabili.
      • Direttive di cache errate su risposte che impostano cookie.
    • Problemi a basso rischio (impatto limitato o bassa specificità):

      • Vettori di bypass del directory listing.
      • Reindirizzamento verso URL forniti dall'attaccante (persistenti e riflessi).
      • Contenuto incorporato fornito dall'attaccante (persistente e riflesso).
      • Contenuto incorporato esterno non affidabile.
      • Contenuti misti su sotto-risorse non scriptabili (opzionale).
      • Invio di moduli HTML da HTTPS a HTTP (opzionale).
      • Credenziali HTTP negli URL.
      • Certificati SSL scaduti o non ancora validi.
      • Moduli HTML senza protezione XSRF.
      • Certificati SSL auto-firmati.
      • Mancata corrispondenza del nome host del certificato SSL.
      • Direttive di cache errate su contenuti meno sensibili.
    • Avvisi interni:

      • Tentativi di recupero di risorse falliti.
      • Limiti di scansione superati.
      • Controlli del comportamento 404 falliti.
      • Rilevato filtraggio IPS.
      • Variazioni di risposta inattese.
      • Nodi di scansione apparentemente classificati male.
    • Voci informative non specifiche:

      • Informazioni generali sul certificato SSL.
      • Cookie HTTP che cambiano in modo significativo.
      • Header Server, Via o X-... che cambiano.
      • Nuove firme 404.
      • Risorse a cui non è possibile accedere.
      • Risorse che richiedono autenticazione HTTP.
      • Link interrotti.
      • Errori del server.
      • Tutti i link esterni non classificati altrimenti (opzionale).
      • Tutte le e-mail esterne (opzionale).
      • Tutti i reindirizzatori URL esterni (opzionale).
      • Link verso protocolli sconosciuti.
      • Campi di modulo che non hanno potuto essere completati automaticamente.
      • Moduli di inserimento password (per brute-force esterno).
      • Moduli di upload file.
      • Altri moduli HTML (non classificati altrimenti).
      • Nomi di file numerici (per brute-force esterno).
      • Link forniti dall'utente altrimenti renderizzati su una pagina.
      • Tipo MIME errato o mancante su contenuti meno significativi.
      • Tipo MIME generico su contenuti meno significativi.
      • Charset errato o mancante su contenuti meno significativi.
      • Informazioni MIME / charset contrastanti su contenuti meno significativi.
      • Convenzioni di passaggio parametri in stile OGNL.

    Oltre a un elenco dei problemi identificati, skipfish fornisce anche panoramiche riassuntive dei tipi di documento e dei tipi di problema trovati; e una mappa interattiva, con i nodi scoperti tramite brute-force indicati in modo distintivo.

    NOTA: Come decisione di design consapevole, skipfish non si lamenterà in modo ridondante di problemi altamente aspecifici, inclusi ma non limitati a:

    • Cookie non httponly o non secure,
    • Moduli non HTTPS o con autocomplete abilitato,
    • Commenti HTML rilevati su una pagina,
    • Divulgazione del percorso del filesystem nei messaggi di errore,
    • Divulgazione della versione del server o del framework,
    • Server che supportano richieste TRACE o OPTIONS,
    • Mera presenza di determinate tecnologie, come WebDAV.

    La maggior parte di questi aspetti è facile da ispezionare in un rapporto, se lo si desidera - ad esempio, tutti i moduli HTML sono elencati separatamente, così come i nuovi cookie o gli header HTTP interessanti - e l'aspettativa è che il revisore possa scegliere di formulare determinate raccomandazioni di design basate su questi dati, dove appropriato. Detto questo, queste occorrenze non vengono evidenziate come uno specifico difetto di sicurezza.


    1. Va bene, voglio provarlo. Cosa devo sapere?

    Prima di tutto, per favore, non essere malvagio. Usa skipfish solo contro servizi che possiedi, o per i quali hai il permesso di testare.

    Tieni presente che tutti i tipi di test di sicurezza possono essere disturbanti. Sebbene lo scanner sia progettato per non effettuare attacchi malevoli, potrebbe accidentalmente interferire con le operazioni del sito. Devi accettare il rischio e pianificare di conseguenza. Esegui lo scanner su istanze di test dove possibile e sii pronto ad affrontare le conseguenze se qualcosa va storto.

    Nota anche che lo strumento è pensato per essere usato da professionisti della sicurezza ed è di natura sperimentale. Potrebbe restituire falsi positivi o non rilevare ovvi problemi di sicurezza - e anche quando funziona perfettamente, non è semplicemente pensato per essere un'applicazione "punta e clicca". Non prendere il suo output per valore assoluto.

    Eseguire lo strumento contro siti demo forniti dai vendor non è un buon modo per valutarlo, poiché di solito approssimano le vulnerabilità in modo molto imperfetto; non abbiamo fatto alcuno sforzo per accogliere questi casi.

    Infine, lo scanner non è semplicemente progettato per gestire server HTTP malintenzionati o con comportamenti anomali - e non offre garanzie di comportamento sicuro (o sensato) in questi casi.


    1. Come si esegue lo scanner?

    Per compilarlo, basta estrarre l'archivio e provare make. È probabile che prima dovrai installare libidn.

    Successivamente, devi leggere le istruzioni fornite in doc/dictionaries.txt per selezionare il file di dizionario giusto e configurarlo correttamente. Questo passaggio ha un impatto profondo sulla qualità dei risultati di scansione in seguito, quindi non saltarlo.

    Una volta selezionato il dizionario, puoi usare -S per caricare quel dizionario e -W per specificare un file inizialmente vuoto per eventuali nuove parole chiave specifiche del sito apprese (che torneranno utili in valutazioni future):

    $ touch new_dict.wl $ ./skipfish -o output_dir -S existing_dictionary.wl -W new_dict.wl
    http://www.example.com/some/starting/path.txt

    Puoi usare -W- se non vuoi memorizzare da nessuna parte le parole chiave apprese automaticamente.

    Nota che puoi fornire più di un URL iniziale, se lo desideri; verranno tutti sottoposti a scansione. È anche possibile leggere gli URL da un file, usando la seguente sintassi:

    $ ./skipfish [...altre opzioni...] @../path/to/url_list.txt

    Lo strumento mostrerà alcune statistiche utili mentre la scansione è in corso. Puoi anche passare a un elenco delle richieste HTTP in volo premendo invio.

    Nell'esempio precedente, skipfish scansionerà l'intero www.example.com (inclusi i servizi su altre porte, se collegati dalla pagina principale) e scriverà un rapporto in output_dir/index.html. Puoi quindi visualizzare questo rapporto con il tuo browser preferito (JavaScript deve essere abilitato; e a causa dei recenti miglioramenti di sicurezza di file:/// in alcuni browser, potresti dover accedere ai risultati via HTTP). Il file index.html è statico; i risultati effettivi sono memorizzati come una gerarchia di file JSON, adatti all'elaborazione automatica o a diversi frontend di presentazione, se necessario. Inoltre, un elenco di tutti gli URL scoperti viene salvato in un singolo file, pivots.txt, per una facile post-elaborazione.

    Un semplice script di accompagnamento, sfscandiff, può essere usato per calcolare un delta tra due scansioni eseguite contro lo stesso target con gli stessi flag. Il rapporto più recente verrà annotato in modo non distruttivo aggiungendo uno sfondo rosso a tutti i nodi nuovi o modificati; e uno sfondo blu a tutti i problemi nuovi o modificati trovati.

    Alcuni siti possono richiedere autenticazione, per la quale il nostro supporto è descritto in doc/authentication.txt. Nella maggior parte dei casi, vorrai usare il metodo di autenticazione tramite modulo, che è in grado di rilevare sessioni interrotte per poter ri-autenticare.

    Una volta autenticato, alcuni URL del sito potrebbero far scadere la tua sessione; puoi contrastarlo in due modi: usando l'opzione -N, che fa sì che lo scanner rifiuti tentativi di impostare o eliminare cookie; oppure con il parametro -X, che impedisce il recupero degli URL corrispondenti:

    $ ./skipfish -X /logout/logout.aspx ...altri parametri...

    L'opzione -X è utile anche per velocizzare le scansioni escludendo /icons/, /doc/, /manuals/ e altre posizioni standard e banali di questo tipo. In generale, puoi usare -X e -I (per fare spider solo sugli URL che corrispondono a una sottostringa) per limitare l'ambito di una scansione come preferisci - inclusa la restrizione a un protocollo e una porta specifici:

    $ ./skipfish -I http://example.com:1234/ ...altri parametri...

    Una funzione correlata, -K, ti permette di specificare nomi di parametri da non sottoporre a fuzzing (utile per applicazioni che mettono gli ID di sessione nell'URL, per ridurre il rumore).

    Un'altra utile opzione di scoping è -D - che ti permette di specificare host o domini aggiuntivi da considerare in scope per il test. Di default, tutti gli host presenti negli URL della riga di comando vengono aggiunti all'elenco - ma puoi usare -D per ampliare queste regole, ad esempio:

    $ ./skipfish -D test2.example.com -o output-dir http://test1.example.com/

    ...oppure, per una corrispondenza con caratteri jolly sul dominio, usa:

    $ ./skipfish -D .example.com -o output-dir http://test1.example.com/

    In alcuni casi, non vuoi effettivamente scansionare un dominio di terze parti, ma ti fidi abbastanza del proprietario di quel dominio da non preoccuparti dell'inclusione di contenuti cross-domain da quella posizione. Per sopprimere gli avvisi, puoi usare l'opzione -B, ad esempio:

    $ ./skipfish -B .google-analytics.com -B .googleapis.com ...altri parametri...

    Di default, skipfish invia header HTTP minimalisti per ridurre la quantità di dati scambiati sulla rete; alcuni siti esaminano le stringhe User-Agent o l'ordine degli header per rifiutare client non supportati, tuttavia. In tal caso, puoi usare -b ie, -b ffox o -b phone per imitare uno dei due browser popolari (o iPhone).

    Quando si tratta di personalizzare le tue richieste HTTP, puoi anche usare l'opzione -H per inserire qualsiasi header aggiuntivo non standard; o -F per definire una mappatura personalizzata tra un host e un IP (bypassando il resolver). Quest'ultima funzionalità è particolarmente utile per servizi non ancora lanciati o legacy.

    Alcuni siti potrebbero essere troppo grandi per essere scansionati in un lasso di tempo ragionevole. Se il sito presenta tarpit ben definiti - ad esempio, 100.000 profili utente quasi identici come parte di un social network - queste posizioni specifiche possono essere escluse con -X o -S. In altri casi, potresti dover ricorrere ad altre impostazioni: -d limita la profondità di scansione a un numero specificato di sottodirectory; -c limita il numero di figli per directory; -x limita il numero totale di discendenti per ramo dell'albero di scansione; e -r limita il numero totale di richieste da inviare in una scansione.

    Un'opzione interessante è disponibile per valutazioni ripetute: -p. Specificando una percentuale tra 1 e 100%, è possibile dire al crawler di seguire meno del 100% di tutti i link e provare meno del 100% di tutte le voci del dizionario. Questo - naturalmente - limita la completezza di una scansione, ma a differenza della maggior parte delle altre impostazioni, lo fa in modo bilanciato e non deterministico. È estremamente utile quando stai impostando valutazioni periodiche della tua infrastruttura con limite di tempo. Un'altra opzione correlata è -q, che imposta il seed casuale iniziale per il crawler a un valore specificato. Questo può essere usato per riprodurre esattamente una scansione precedente per confrontare i risultati. La casualità è usata soprattutto nella modalità -p, ma anche per prendere un paio di altre decisioni di gestione della scansione altrove.

    Alcuni servizi particolarmente complessi (o rotti) possono coinvolgere un numero molto elevato di pagine identiche o quasi identiche. Sebbene queste occorrenze vengano per impostazione predefinita oscurate nel rapporto, occupano comunque un po' di spazio sullo schermo e richiedono tempo per essere elaborate a livello JavaScript. In casi estremi come questi, puoi usare l'opzione -Q per sopprimere del tutto la segnalazione dei nodi duplicati, prima che il rapporto venga scritto. Questo potrebbe darti una comprensione meno completa di come è organizzato il sito, ma non ha alcun impatto sulla copertura dei test.

    In alcune valutazioni rapide, potresti anche non avere alcun interesse a prestare particolare attenzione alla funzionalità desiderata del sito - sperando di esplorare solo segreti non collegati. In tal caso, puoi specificare -P per inibire tutto il parsing HTML. Questo limita la copertura e toglie allo scanner la capacità di apprendere nuove parole chiave guardando l'HTML, ma velocizza notevolmente il test. Un'altra opzione simile che riduce il rischio di effetti persistenti di una scansione è -O, che inibisce tutti i passaggi di parsing e invio dei moduli.

    Alcuni siti che gestiscono dati utente sensibili tengono all'SSL - e a farlo bene. Skipfish può opzionalmente aiutarti a individuare problemi di contenuti misti o scenari di invio di password - usa l'opzione -M per abilitarlo. Lo scanner si lamenterà di situazioni come script http:// caricati su pagine https:// - ma ignorerà scenari a basso rischio come le immagini.

    Allo stesso modo, alcuni siti pignoli potrebbero interessarsi ai casi in cui la memorizzazione nella cache è limitata a livello HTTP/1.1, ma non viene fornita alcuna direttiva di caching esplicita HTTP/1.0; specificando -E nella riga di comando si fa sì che skipfish registri attentamente tutti questi casi.

    In alcune occasioni, potresti voler limitare le richieste al secondo per limitare il carico sul server del target (o possibilmente bypassare la protezione DoS). Il flag -l può essere usato per impostare questo limite e il valore fornito è la quantità massima di richieste al secondo che vuoi che skipfish esegua.

    Le scansioni in genere non dovrebbero richiedere settimane. In molti casi, probabilmente vorrai limitare la durata della scansione in modo che rientri in una determinata finestra di tempo. Questo può essere fatto con il flag -k, che consente di specificare la quantità di ore, minuti e secondi in un formato H:M:S. L'uso di questo flag può influire sulla copertura della scansione se il timeout si verifica prima di testare tutte le pagine.

    Infine, in alcune valutazioni che coinvolgono siti autonomi senza ampio contenuto utente, il revisore potrebbe interessarsi a qualsiasi e-mail esterna o link HTTP visti, anche se non hanno un impatto immediato sulla sicurezza. Usa l'opzione -U per farli registrare.

    La gestione dei dizionari è un argomento speciale e, come accennato, è trattata in maggior dettaglio in doc/dictionaries.txt. Per favore leggi quel file prima di procedere. Alcune delle opzioni rilevanti includono -S e -W (già trattati), -L per sopprimere l'auto-apprendimento, -G per limitare la dimensione del jar delle parole chiave indovinate, -R per eliminare le vecchie voci del dizionario e -Y per inibire il costoso fuzzing di $keyword.$extension.

    Skipfish dispone anche di un meccanismo di completamento automatico dei moduli per massimizzare la copertura della scansione. I valori devono essere non dannosi, poiché non hanno lo scopo di implementare controlli di sicurezza - ma piuttosto di superare la logica di validazione dell'input. Puoi definire regole aggiuntive o sovrascrivere quelle esistenti con l'opzione -T (-T nome_campo_modulo=valore_campo, ad es. -T login=test123 -T password=test321 - anche se nota che -C e -A sono un metodo molto migliore per effettuare il login).C'è anche una manciata di opzioni relative alle prestazioni. Usa -g per impostare il numero massimo di connessioni da mantenere, a livello globale, verso tutti i target (è sensato mantenerlo sotto 50 circa per evitare di sovraccaricare lo stack TCP/IP del tuo sistema o dei dispositivi NAT / firewall nelle vicinanze); e -m per impostare il limite per IP (sperimenta un po': 2-4 è di solito ok per localhost, 4-8 per reti locali, 10-20 per target esterni, 30+ per host molto lenti o senza keep-alive). Puoi anche usare -w per impostare il timeout di I/O (cioè, skipfish attenderà solo per un certo tempo una singola lettura o scrittura), e -t per impostare il timeout complessivo della richiesta, per tenere conto di siti molto lenti o molto veloci.

    Infine, -f controlla il numero massimo di errori HTTP consecutivi che sei disposto a vedere prima di interrompere la scansione; e -s imposta la lunghezza massima di una risposta da recuperare e analizzare (le risposte più lunghe verranno troncate).

    Quando si scansionano siti grandi e ricchi di contenuti multimediali, potresti anche voler specificare -e. Questo impedisce che i documenti binari vengano tenuti in memoria per scopi di reporting e libera molta RAM.

    Un'ulteriore limitazione della frequenza è disponibile tramite strumenti di terze parti in modalità utente come trickle, o tramite traffic shaping a livello di kernel.

    Ah, e le statistiche di scansione in tempo reale possono essere disattivate con -u.


    1. Ma sul serio, come lo si esegue?

    Una scansione standard e autenticata di un sito ben progettato e autonomo (segnala tutti i link esterni, le e-mail, i contenuti misti e i problemi di intestazione della cache), incluso un brute-force moderato:

    $ touch new_dict.wl $ ./skipfish -MEU -S dictionaries/minimal.wl -W new_dict.wl
    -C "AuthCookie=value" -X /logout.aspx -o output_dir
    http://www.example.com/

    Crawl a cinque connessioni, ma senza brute-force; simulando MSIE e fidandosi del contenuto di example.com:

    $ ./skipfish -m 5 -L -W- -o output_dir -b ie -B example.com
    http://www.example.com/

    Solo brute-force pesante (nessuna estrazione di link HTML), limitato a una singola directory e con timeout dopo 5 secondi:

    $ touch new_dict.wl $ ./skipfish -S dictionaries/complete.wl -W new_dict.wl
    -P -I http://www.example.com/dir1/ -o output_dir -t 5 -I
    http://www.example.com/dir1/

    Per un breve elenco di tutte le opzioni della riga di comando, prova ./skipfish -h.


    1. Come interpretare e affrontare i problemi segnalati?

    La maggior parte dei problemi segnalati da skipfish dovrebbe essere autoesplicativa, supponendo che tu abbia una buona padronanza dei fondamenti della sicurezza web. Se hai bisogno di un rapido ripasso su alcuni degli argomenti più complicati, come il MIME sniffing, potresti apprezzare il nostro esaustivo Browser Security Handbook come punto di partenza:

    http://code.google.com/p/browsersec/

    Se hai ancora bisogno di assistenza, ci sono diverse organizzazioni che dedicano uno sforzo considerevole a documentare e spiegare molte delle minacce comuni alla sicurezza web e a consigliare il pubblico su come affrontarle. Ti incoraggio a fare riferimento ai materiali pubblicati da OWASP e Web Application Security Consortium, tra gli altri:

    • http://www.owasp.org/index.php/Category:Principle
    • http://www.owasp.org/index.php/Category:OWASP_Guide_Project
    • http://www.webappsec.org/projects/articles/

    Sebbene sia felice di diagnosticare i problemi dello scanner stesso, purtroppo non posso offrire alcuna assistenza sul funzionamento interno delle applicazioni web di terze parti.


    1. Limitazioni note / lista delle funzionalità desiderate

    Di seguito è riportato un elenco delle funzionalità attualmente mancanti in skipfish. Se desideri migliorare lo strumento contribuendo con codice in una di queste aree, per favore fammi sapere:

    • Controlli per buffer overflow: dopo attenta riflessione, sospetto che non esista un modo affidabile per testare da remoto i buffer overflow. Proprio come la condizione di errore che cerchiamo, anche i controlli adeguati della dimensione del buffer possono causare eccezioni non gestite, messaggi 500, ecc. Tuttavia, mi piacerebbe che qualcuno mi dimostrasse il contrario.

    • Rilevamento XSS JavaScript completo: nel codice sono presenti diversi controlli rudimentali, ma non c'è un vero motore script integrato per valutare le espressioni e l'accesso al DOM.

    • Bug di consumo dei caratteri / iniezione con codifiche a lunghezza variabile: questi problemi sembrano essere in gran parte risolti a livello di browser a questo punto, quindi avevano una priorità molto più bassa al momento della stesura di questo documento.

    • Controlli di sicurezza ed estrazione di link per contenuti di terze parti basati su plugin (Flash, Java, PDF, ecc.).

    • Probe di brute-force su password e su nomi di file numerici.

    • Integrazione con i motori di ricerca (vhost, percorsi iniziali).

    • Decodifica VIEWSTATE.

    • Autenticazione NTLM e digest.

    • Test PHP più specifici (iniezione eval, RFI).

    • Supporto proxy: un supporto proxy HTTP sperimentale è disponibile tramite una direttiva #define in config.h. Aggiungere il supporto per il proxy HTTPS è più complicato ed è ancora in lavorazione.

    • Opzione di ripresa della scansione, migliori informazioni di runtime.

    • Supporto per installazione autonoma (make install).

    • Interfaccia web di pianificazione e gestione.


    1. Ehi! Qualcosa è andato terribilmente storto!

    Non esiste un crawler web così buono che non esista un framework web capace di mandarlo a fuoco prima o poi. Se incontri quello che sembra un comportamento anomalo (ad esempio, una scansione che dura all'infinito e genera troppe richieste, nodi completamente errati nell'output della scansione o crash veri e propri), controlla prima la nostra pagina dei problemi noti:

    http://code.google.com/p/skipfish/wiki/KnownIssues

    Se non trovi una risposta soddisfacente lì, ricompila lo scanner con:

    $ make clean debug

    ...e rieseguilo in questo modo:

    $ ./skipfish [...previous options...] 2>logfile.txt

    Potrai quindi ispezionare logfile.txt per farti un'idea di cosa sia andato storto; se sembra un problema dello scanner, elimina qualsiasi informazione sensibile dal file di log e invialo all'autore.

    Se lo scanner è andato in crash, ricompilalo come indicato sopra e poi digita:

    $ ulimit -c unlimited $ ./skipfish [...previous options...] 2>logfile.txt $ gdb --batch -ex back ./skipfish core

    ...e assicurati di inviare all'autore anche l'output di quest'ultimo comando.


    1. Riconoscimenti e feedback

    Skipfish è reso possibile grazie ai contributi e al prezioso feedback del team di ingegneria della sicurezza informatica di Google.

    Per qualsiasi segnalazione di bug, domanda, suggerimento o dubbio riguardo all'applicazione, è possibile contattare l'autore principale all'indirizzo [email protected].

    Scarica lo strumento