Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
VulnScan — Scanner di vulnerabilità web in Python: SQL injection, XSS , path traversal, security headers. Crawler, dashboard Flask, report in un PDF | Kitploit
도구/GitHubGitHub/torchiachristian/vulnscan
Static AnalysisVulnerability ScannersWeb Vulnerability ScannersCode AnalysisWeb SecurityPenetration TestingLearning & EducationCrawler
GitHubtorchiachristian/vulnscan

VulnScan

Scanner di vulnerabilità web in Python: SQL injection, XSS , path traversal, security headers. Crawler, dashboard Flask, report in un PDF

저장소 보기
281개월 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
요청한 언어로 콘텐츠를 사용할 수 없습니다. 영어 버전을 표시합니다.

VulnScan

Scanner di vulnerabilita' web. Fa il crawling di un sito, trova form e parametri, e li prova contro SQL injection, XSS riflesso, path traversal e header di sicurezza mancanti. Produce un report a terminale, un PDF e ha una dashboard Flask.

Progetto di apprendimento. L'ho scritto per capire come funzionano quegli attacchi lato pratico, dopo aver studiato la teoria. Il codice e' generato con assistenza AI e lo dichiaro: quello che ho fatto io e' il testing e la correzione dei falsi positivi, che sono documentati in docs/DESIGN_NOTES.md.

Solo su applicazioni tue o con autorizzazione scritta. Scansionare siti di terzi senza permesso e' illegale nella maggior parte delle giurisdizioni.

Cosa rileva

  • SQL Injection, error-based e boolean-based blind
  • XSS riflesso
  • Path traversal
  • Header di sicurezza mancanti (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
  • Crawler che scopre pagine e form
  • Report PDF e dashboard web

Quello che NON fa, anche se i payload sono nei file: SQL injection time-based e XSS stored. Il time-based richiede di misurare la latenza contro una baseline e su rete rumorosa produce falsi positivi troppo facilmente; lo stored richiede di inviare su una pagina e verificare su un'altra, cosa che il crawler attuale non fa. Finche' non c'e' il codice non li dichiaro tra le feature.

Installazione

root@kitploit:~
git clone https://github.com/torchiachristian/VulnScan
cd VulnScan
pip install -r requirements.txt
python3 src/database.py

Uso

root@kitploit:~
# scansione base
python3 src/scanner.py http://localhost:8080

# con report PDF
python3 src/scanner.py http://localhost:8080 --pdf report.pdf

# dashboard web su http://127.0.0.1:5000
python3 src/web/app.py

Dove provarlo

root@kitploit:~
# DVWA in docker
docker run -p 80:80 vulnerables/web-dvwa
# credenziali admin/password, livello di sicurezza "Low"

Oppure OWASP Juice Shop. Nel repo ci sono anche due app Flask minime in tests/: una volutamente vulnerabile e una sicura, usate per verificare che il tool trovi le vulnerabilita' vere senza inventarne di finte.

Il falso positivo che ho trovato testando

La prima versione del detector boolean-based faceva cosi':

root@kitploit:~
if len(response_true.text) != len(response_false.text):
    # -> SQL Injection, Critical

Bastava un byte di differenza tra la risposta alla condizione vera e quella alla condizione falsa per dichiarare una SQL injection critica.

Il problema e' che due richieste identiche alla stessa pagina quasi mai danno la stessa risposta: token CSRF, timestamp, contatori di visite, banner. Ho scritto un'app Flask senza nessun database e con l'input sempre escapato, con dentro un token casuale come ne ha qualsiasi sito, e il tool ci ha trovato questo:

root@kitploit:~
[6] SQL Injection (Critical)
    Evidence: Response length difference: 268 vs 300

Una SQL injection su un'applicazione che non ha un database. Due richieste identiche alla stessa pagina davano 262 e 241 byte, quindi il controllo scattava anche senza payload.

Adesso il detector misura prima quanto varia la pagina da sola a parita' di input, poi considera una differenza solo se supera quel rumore di un margine e se il risultato e' coerente su piu' tentativi, sempre nello stesso verso. Se la pagina e' troppo instabile per misurare restituisce niente invece di indovinare.

Sulla stessa app sicura ora non segnala piu' nulla, e su un'app con una SQL injection vera continua a trovarla.

Struttura

root@kitploit:~
src/
├── crawler/web_crawler.py       scoperta di pagine e form
├── detectors/
│   ├── http_utils.py            costruzione richieste e misura del rumore
│   ├── sql_injection.py         error-based e boolean-based
│   ├── xss.py                   XSS riflesso
│   ├── path_traversal.py        directory traversal
│   └── security_headers.py      header mancanti
├── reporting/pdf_generator.py   report PDF
├── web/app.py                   dashboard Flask
├── scanner.py                   pipeline principale
└── database.py                  SQLite
payloads/                        payload per tipo di attacco
tests/                           app di prova (vulnerabile e sicura) + test

Limiti

Il crawler non gestisce autenticazione, quindi vede solo la parte pubblica di un'applicazione. Non c'e' rate limiting: contro un sito vero va usato con cautela. I payload sono generici e non provano bypass di WAF. Il boolean-based resta l'euristica piu' fragile delle due tecniche SQL e per questo il report riporta sempre il rumore misurato e la soglia usata, cosi' chi legge puo' valutare.

Licenza

MIT. Usalo in modo etico.

도구 다운로드