torchiachristian/vulnscanWeb-Schwachstellenscanner in Python: SQL-Injection, XSS , Path Traversal, Security-Header. Crawler, Flask-Dashboard, Bericht als PDF.
Web-Schwachstellenscanner. Er crawlt eine Website, findet Formulare und Parameter und testet sie gegen SQL-Injection, reflektiertes XSS, Path Traversal und fehlende Sicherheitsheader. Er erzeugt einen Bericht im Terminal, ein PDF und hat ein Flask-Dashboard.
Lernprojekt. Ich habe es geschrieben, um zu verstehen, wie diese
Angriffe in der Praxis funktionieren, nachdem ich die Theorie studiert hatte. Der Code ist mit
KI-Unterstützung generiert und das erkläre ich: Was ich gemacht habe, ist das Testen und
die Korrektur der Falsch-Positive, die in
docs/DESIGN_NOTES.md dokumentiert sind.
Nur bei eigenen Anwendungen oder mit schriftlicher Genehmigung. Das Scannen von Websites Dritter ohne Erlaubnis ist in den meisten Rechtsordnungen illegal.
Was er NICHT macht, obwohl die Payloads in den Dateien sind: time-based SQL-Injection und Stored XSS. Time-based erfordert das Messen der Latenz gegen eine Baseline und erzeugt auf verrauschten Netzwerken zu leicht Falsch-Positive; Stored erfordert das Senden auf eine Seite und das Verifizieren auf einer anderen, was der aktuelle Crawler nicht macht. Solange es den Code nicht gibt, zähle ich sie nicht zu den Features.
git clone https://github.com/torchiachristian/VulnScan
cd VulnScan
pip install -r requirements.txt
python3 src/database.py
# 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
# DVWA in docker
docker run -p 80:80 vulnerables/web-dvwa
# credenziali admin/password, livello di sicurezza "Low"
Oder OWASP Juice Shop. Im Repo gibt es außerdem zwei minimale Flask-Apps in
tests/: eine absichtlich verwundbare und eine sichere, die verwendet werden, um zu überprüfen, dass das
Tool die echten Schwachstellen findet, ohne falsche zu erfinden.
Die erste Version des boolean-basierten Detektors funktionierte so:
if len(response_true.text) != len(response_false.text):
# -> SQL Injection, Critical
Ein einziges Byte Unterschied zwischen der Antwort auf die wahre Bedingung und der auf die falsche Bedingung genügte, um eine kritische SQL-Injection zu melden.
Das Problem ist, dass zwei identische Anfragen an dieselbe Seite fast nie dieselbe Antwort liefern: CSRF-Token, Zeitstempel, Besucherzähler, Banner. Ich habe eine Flask-App ohne jede Datenbank und mit stets escaptem Input geschrieben, mit einem zufälligen Token darin, wie es jede Website hat, und das Tool hat darin Folgendes gefunden:
[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.
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
Der Crawler behandelt keine Authentifizierung, daher sieht er nur den öffentlichen Teil einer Anwendung. Es gibt kein Rate Limiting: Gegen eine echte Website muss er mit Vorsicht verwendet werden. Die Payloads sind generisch und belegen keine WAF-Bypässe. Das boolean-basierte Verfahren bleibt die fragilere Heuristik der beiden SQL-Techniken, und deshalb enthält der Bericht immer das gemessene Rauschen und den verwendeten Schwellenwert, sodass die Leserschaft urteilen kann.
MIT. Verwende es ethisch.