Trova vulnerabilità nei web server: 30+ hardening check

Le config Apache e Nginx sembrano semplici, sono compositive. Una direttiva può apparire al top-level, dentro un <VirtualHost> Apache, dentro un server { } Nginx, dentro una <Location> o una location { }: il significato cambia con lo scope. Header di sicurezza dichiarati nello scope sbagliato sono presenti formalmente ma non si applicano alla pagina che dovevano proteggere. Cipher modern dichiarati al top-level vengono sovrascritti da una direttiva legacy in un vhost specifico. Il regex grep non vede queste sottigliezze: il parsing AST sì, e questa versione del linter è basata su un parser AST proper scritto in vanilla JS (~750 LOC complessive) che produce un albero navigabile di blocchi e direttive con line number.

Cosa controlla in concreto. Il linter applica oltre 30 check su 5 famiglie. SSL/TLS: protocolli obsoleti (SSLv2, SSLv3, TLSv1, TLSv1.1) e modern (TLSv1.2, TLSv1.3), cipher weak (RC4, 3DES, EXPORT, NULL) vs cipher strong, presenza di forward secrecy (ECDHE/DHE), AEAD (GCM, ChaCha20-Poly1305), OCSP stapling. Header di sicurezza con value validator: la differenza con i linter regex-based e\' qui. CSP con unsafe-inline in script-src = praticamente disabilitata, segnala medium; CSP con wildcard *, unsafe-eval, mancanza di report-uri: tutti finding distinti. HSTS con max-age < 6 mesi: medium. HSTS senza includeSubDomains: low. HSTS senza preload: info. Information disclosure: ServerTokens / server_tokens verbose, autoindex on, /server-status e /nginx_status non restricted. Availability e hardening: listen 80 senza redirect a HTTPS, rate limiting su endpoint di autenticazione (/login, /auth, /register), HTTP/2 abilitato, mod_security WAF presente. Override semantici Nginx: il caso classico in cui un add_header dentro una location azzera silenziosamente tutti gli add_header del server parent per quella location, lasciando la pagina senza HSTS/CSP/X-Frame.

Differenza fra linter context-aware e linter regex-based. Il linter precedente di questo tool faceva regex grep su tutto il testo della config: /Strict-Transport-Security/i.test(text). Risultato: HSTS dichiarato dentro <Location /admin> contava come HSTS presente, anche se l'header era ovviamente non emesso al di fuori di /admin. Falso negativo grave. Stesso problema con add_header Nginx: la presenza nel testo non implica applicazione alla request. Lo stesso vale per protocolli e cipher: una direttiva valida in un vhost non implica che valga per tutti gli altri. Il parser AST risolve in radice questi problemi: ogni finding ha contesto preciso (in quale blocco, a quale linea, con quali argomenti).

Privacy operativa. Una config server rivela la struttura completa di un'infrastruttura: hostname, certificati, percorsi del filesystem, backend interni, eventuali proxy cache, eventuali path admin nascosti. Caricarla a un servizio terzo per un audit preliminare e\' un vettore di leak: la config esce dal perimetro, raggiunge un endpoint esterno, viene processata e magari loggata. Qui non parte nessuna richiesta di rete con i dati della config: parser e regole girano interamente nel browser. Verificabile aprendo il pannello Network di DevTools durante il lint.

Quando il triage statico è il livello giusto. Casi tipici. (a) Code review di un Pull Request che modifica la config Nginx prima del merge: il linter copre il 70-80% dei pattern di hardening e segnala in modo deterministico. (b) Audit pre-go-live di un nuovo VPS: la config DevOps appena scritta passa il triage prima del deploy in produzione. (c) Self-check periodico: la config che gira da due anni in produzione viene re-lintata per intercettare regressioni introdotte da modifiche puntuali. (d) Pre-engagement audit di un cliente che chiede una review della propria config: trenta secondi di lint danno la lista dei findings da approfondire con esercizio di hardening serio.

Limite di scope. Il linter analizza il testo della config: non interroga lo stato runtime del server, non risolve Include / include verso file esterni, non valuta certificati X.509 in scadenza, non verifica che il backend dietro un proxy_pass risponda davvero in HTTPS, non controlla i log per attacchi attivi. Per quegli aspetti servono assessment manuali, scanner online (SSLLabs, Mozilla Observatory) e monitoring CVE in continuo. Il linter è un triage rapido, non un sostituto.

Il linter è strutturato in tre layer indipendenti: parser AST, rules context-aware, value validators. Tutti girano in vanilla JS nel browser, zero dipendenze.

Parser AST (~750 LOC totali). Due moduli separati: apache-config-parser.js (~400 LOC, line-based con XML-like tags <VirtualHost>, supporto continuation con backslash, case-insensitive matching) e nginx-config-parser.js (~350 LOC, recursive descent con tokenizzazione esplicita di {, }, ;, quoted strings, comments). Output: AST con nodi directive (nome + args + line) e block (nome + args + children + line). Helper API: findAll, findDirectives, findBlocks, walkContexts (visitor con ancestor chain), findInScope (children diretti). Validato da 26 fixture inline (12 nginx + 14 apache, eseguibili manualmente da console: NginxConfigParser.runFixtures() / ApacheConfigParser.runFixtures()).

Rules context-aware. Per Apache: ServerTokens / ServerSignature al top-level; per ogni <VirtualHost> separatamente, audit di SSL (SSLProtocol, SSLCipherSuite, SSLUseStapling), HSTS scoped al vhost, header di sicurezza, HTTP/2 (Protocols h2); <Directory /> con AllowOverride All; <Location /server-status> e /server-info con/senza Require restrittivo; presenza di <IfModule mod_security2.c>. Per Nginx: per ogni server { }, audit di SSL (ssl_protocols, ssl_ciphers, ssl_stapling), HSTS scoped al server, header di sicurezza, HTTP/2 (listen ... http2); autoindex on in qualsiasi nested scope; location /nginx_status con/senza allow/deny; rate limiting (limit_req) su location di tipo auth (/login, /auth, /register, /password-reset); add_header override semantica.

Value validators. Tre validator scrivono finding mirati sui valori effettivi degli header. CSP: parsing del valore in direttive (script-src, default-src, report-uri, report-to); 'unsafe-inline' in script-src = medium (XSS protection collassata); 'unsafe-eval' = medium; * wildcard = medium; assenza di report-uri/report-to = info. HSTS: parsing di max-age; mancante = medium; < 6 mesi = medium; assenza di includeSubDomains = low; assenza di preload = info. Forward secrecy: presenza di pattern ECDHE/DHE nei cipher; assenza = medium. HTTP/2: assenza in Protocols h2 Apache o listen ... http2 Nginx = info.

Override semantica Nginx (caso particolare). Nginx ha una regola controintuitiva: se una location contiene anche un solo add_header, TUTTI gli add_header del server parent vengono ignorati per quella location. Risultato pratico: HSTS, X-Frame, CSP dichiarati a livello server NON sono emessi sulla risposta della location specifica. Il linter rileva questa configurazione (server con add_header + location con add_header) e segnala medium con la lista delle location coinvolte. Il fix tipico: ripetere gli header essenziali in ogni location che ha override, oppure riscrivere usando more_set_headers di nginx-headers-more.

Punteggio aggregato 0-100. Calcolato come 100 - somma(severity_weights), con pesi: critical 30, high 15, medium 7, low 3, info 1. Lettura: 80-100 verde (postura ragionevole, eventuale piccolo fine-tuning), 50-79 giallo (interventi pianificabili nelle prossime sprint), 0-49 rosso (debito security significativo, alcuni interventi richiedono mitigation immediata). Il punteggio non misura la qualità del backend dietro la config, solo la postura security visibile dal manifest.

Severity dei finding. critical: vettore confermato che lascia il server vulnerabile a exploit storici (SSLv2/SSLv3 abilitato, cipher weak senza esclusione esplicita). Patch immediata. high: configurazione probabilmente sfruttabile (TLSv1/TLSv1.1 senza esclusione, HSTS mancante su vhost SSL, X-Frame mancante, CSP mancante, /server-status aperto, listen 80 senza redirect). Da affrontare nello sprint corrente. medium: pratica subottimale che riduce la difesa in profondità (forward secrecy assente, CSP con unsafe-inline, HSTS max-age < 6 mesi, autoindex on, AllowOverride All, add_header override semantico, rate limit mancante su auth). Hardening backlog. low: dettaglio che andrebbe sistemato (HSTS senza includeSubDomains, OCSP stapling assente, add_header senza always). info: stato osservazionale (ServerTokens default, HSTS senza preload, HTTP/2 disabilitato, mod_security non visibile, no server block).

Cosa fare in concreto, per priorita\'. (1) Per CRITICAL su SSL/TLS: aggiornare immediatamente SSLProtocol / ssl_protocols a TLSv1.2 TLSv1.3 only e SSLCipherSuite / ssl_ciphers alla raccomandazione Mozilla SSL Configurator (Modern profile per browser recenti, Intermediate per compatibilita\' larga). (2) Per HIGH header missing: aggiungere HSTS (max-age=31536000; includeSubDomains; preload), X-Frame-Options DENY (o frame-ancestors in CSP), CSP coerente con il frontend, X-Content-Type-Options nosniff. (3) Per HIGH /server-status / /nginx_status open: limitare a 127.0.0.1 e/o subnet management. (4) Per HIGH listen 80 no redirect: aggiungere Redirect permanent / https://... Apache o return 301 https://$host$request_uri; Nginx. (5) Per MEDIUM CSP unsafe-inline: refactor del frontend per rimuovere inline script, usare nonce o hash; nei casi residui inevitabili (analytics legacy), accettare il finding ma documentarlo. (6) Per MEDIUM Nginx add_header override: ripetere gli header del server parent in ogni location che ne aggiunge di propri.

Format dei finding. Ogni finding riporta titolo, descrizione del problema, riferimento alla direttiva esatta nella config (con line number quando applicabile), motivazione tecnica, remediation suggerita. Da girare al team con il messaggio operativo: "applicare il fix nel deploy successivo, oppure produrre analisi scritta del perché il vettore non è applicabile alla nostra architettura".