# 10 - Migliorie sicurezza post analisi performance

## Piano iniziale sintetico

1. Consolidare le evidenze gia presenti in `02_app`, `03_db`, `04_git`, `05_php`, `06_mysql`, `07_differenze_cross_app`, `08_migliorie_app`, `09_migliorie_performance` e `cross_app_capability_registry`.
2. Mappare perimetro e superfici esposte: login, menu/permessi, form dinamici, griglie, export, sessioni, costanti runtime e manutenzione CRUGE.
3. Tradurre le evidenze in rischi di sicurezza concreti, evitando ipotesi non dimostrate dal corpus locale.
4. Ordinare le proposte per priorita, impatto, costo e rischio regressione.
5. Chiudere con checklist di validazione, limiti e assunzioni da verificare con il team.

## Contesto e perimetro analisi sicurezza

`yii-framework-base` e il layer framework condiviso della suite Sophia. Non e una verticale di business, quindi l'analisi di sicurezza riguarda soprattutto superfici tecniche trasversali:

- autenticazione e autorizzazione CRUGE
- sessioni e cookie
- menu e pulsanti condizionati da ruoli
- rendering di form, griglie ed export
- costanti runtime e configurazione
- gestione errori e dati esposti in debug

Le evidenze usate sono solo quelle gia consolidate nel corpus locale, in particolare:

- `structure_and_functions.md`
- `sophia_customizations.md`
- `cruge_rbac_authentication.md`
- `configuration_and_environments.md`
- `menu_and_permissions_management.md`
- `costants_management.md`
- `export_management.md`
- `07_differenze_cross_app.md`
- `08_migliorie_app.md`
- `09_migliorie_performance.md`

Non sono stati introdotti nuovi dati runtime o verifiche esterne. Le conclusioni sotto sono quindi evidence-based rispetto al materiale disponibile, non una pen-test analysis.

## Threat Map

| Area | Superficie | Rischio principale | Evidenza base |
|---|---|---|---|
| Autenticazione | CRUGE, login, redirect post-login, stato account | brute force, policy password non verificata, gestione account debole | `cruge_rbac_authentication.md`, `configuration_and_environments.md` |
| Sessioni e cookie | `CHttpSession`, session timeout, cache-control | session fixation, cookie non esplicitati, stato incoerente su browser back | `structure_and_functions.md`, `sophia_customizations.md` |
| RBAC e menu | `GetAbilitazioni(...)`, `hasAnyRole(...)`, controller di abilitazione | autorizzazioni incoerenti tra menu, action e pulsanti | `menu_and_permissions_management.md`, `cruge_rbac_authentication.md` |
| Form e input | `CHtml`, `RenderSettings`, model validation | XSS riflesso/stored se output o filtri non escapati | `structure_and_functions.md`, `forms_fields_management.md` |
| Griglie e export | `CGridView`, `CGridColumn`, `EExcelBehavior`, `EExcelView` | esposizione dati sensibili, output non normalizzato, formula injection da export | `structure_and_functions.md`, `export_management.md` |
| Costanti runtime | `frm_sys_costanti`, `frm_sys_costanti_applicazione` | configurazioni sensibili gestite via DB, surface ampia di impatto | `costants_management.md` |
| Error handling | `CErrorHandler`, `framework/views/exception.php` | leak informativi in debug o logging troppo verboso | `structure_and_functions.md` |
| Integrazioni/config | `config_frm.php`, environment files, mailer, DB | segreti in chiaro, differenze ambiente non tracciate, TLS non verificato | `configuration_and_environments.md` |

## Vulnerabilita e rischi identificati

### 1. Autenticazione e policy account non completamente verificabili dal corpus

**Evidenza**

- CRUGE governa autenticazione, account, RBAC, sessione e redirect post-login.
- Sono documentati `availableAuthModes = array('username','email')`, `useEncryptedPassword = true`, `hash = 'md5'`, `allowUserAlways = false`, `afterSessionExpiredUrl`.
- Il corpus non mostra verifiche aggiuntive su rate limit, lockout, MFA o reset password.

**Rischio**

- se la policy di login resta minimale, l'app espone account amministrativi a brute force o password deboli;
- l'uso di `md5` come hash documentato e un segnale di legacy forte, anche se il comportamento effettivo va confermato sul codice runtime;
- l'assenza di evidenza su lockout o throttling mantiene il rischio medio-alto.

**Correlazione tecnica**

- menu e aree admin dipendono da CRUGE e dai ruoli applicativi;
- un compromesso auth impatta tutta la governance del framework.

### 2. Session management e cookie hardening non esplicitati

**Evidenza**

- `CHttpSession` e documentato come punto di apertura, chiusura, timeout e cookie params.
- La customizzazione Sophia aggiunge `Cache-Control: no cache` per il browser back.
- Sono presenti riferimenti a sessione in manutenzione, filtri e runtime, ma non una matrice completa dei flag cookie.

**Rischio**

- senza evidenza esplicita di `Secure`, `HttpOnly` e `SameSite`, il profilo cookie resta da rafforzare;
- `regenerateID()` e citato come funzione disponibile, ma non e documentato come obbligo operativo su login e step sensibili;
- il back browser su pagine protette puo riusare stati obsoleti o amplificare exposure di dati già renderizzati.

### 3. Autorizzazioni distribuite tra menu, action e pulsanti

**Evidenza**

- `GetAbilitazioni(...)` decide visibilita menu e pulsanti;
- `hasAnyRole(...)` e `Yii::app()->user->isSuperAdmin` sono usati insieme a costanti di ruolo;
- la documentazione mostra governance centralizzata, ma non un audit completo tra menu, controller/action e model per tutte le feature.

**Rischio**

- una differenza di implementazione tra visibilita UI e controllo server-side puo generare bypass logico o IDOR applicativi;
- se una action resta raggiungibile ma il pulsante e nascosto, il controllo front-end non basta.

**Correlazione tecnica**

- la catena reale e `AbilitazioniFrm -> AbilitazioniApp -> AbilitazioniCli` e helper globali;
- il rischio e soprattutto di consistenza, non di assenza totale di RBAC.

### 4. Esposizione dati in griglie, filtri e export

**Evidenza**

- `CGridView`, `CGridColumn` e `RenderSettings` costruiscono rendering dinamico;
- `export_management.md` mostra export manuali con colonne selezionate e `toExcel()`;
- il corpus insiste su filtri sessione e su output ricco, ma non su policy di minimizzazione dati.

**Rischio**

- output non escapato nei contenuti di celle, label o valori derivati puo introdurre XSS se la pipeline di rendering e unescaped;
- export di dataset completi puo esporre campi non necessari o sensibili;
- i file esportati possono contenere dati grezzi, inclusi valori che in Excel potrebbero diventare formule.

### 5. Costanti runtime come superficie di governance ampia

**Evidenza**

- `frm_sys_costanti` e `frm_sys_costanti_applicazione` generano `define()` runtime;
- la modifica di una costante puo influire su routing, menu, workflow, ruoli e query;
- le costanti hanno portata trasversale e impatto immediato sul comportamento dell'app.

**Rischio**

- un errore di configurazione o una modifica non controllata puo alterare il perimetro di visibilita o di esecuzione senza cambio codice;
- la superficie di attacco include chi puo intervenire sui dati di governance.

### 6. Error handling e logging con rischio di leak informativi

**Evidenza**

- `CErrorHandler` e `framework/views/exception.php` sono il punto di fallback;
- la customizzazione Sophia logga i dettagli dell'eccezione su file;
- il corpus distingue debug e produzione, ma non descrive policy di minimizzazione output.

**Rischio**

- stack trace, file path, query o dettagli di errore possono finire al browser o nei log con eccesso di informazione;
- il rischio e alto in ambienti non strettamente segregati.

### 7. Integrazioni e configurazione ambiente con segreti e differenze non uniformate

**Evidenza**

- `configuration_and_environments.md` mostra `config_frm.php`, `config_app.php`, `config_client.php` e file per ambiente;
- sono documentati DB diversi per dev/demo/test/preprod/prod;
- il corpus non mostra un inventario dedicato di segreti, TLS o policy di rotazione credenziali.

**Rischio**

- credenziali o endpoint sensibili possono essere distribuiti in config o environment in modo non uniforme;
- il rischio non e provato da un leak specifico, ma dalla mancanza di evidenza di hardening documentato.

## Scheda remediation per rischio

### R-01 - Rafforzare la policy di autenticazione CRUGE

- **Severita**: alta
- **Probabilita**: media
- **Impatto**: alto
- **Costo**: medio
- **Rischio regressione**: medio

**Proposta**

- verificare e documentare policy password, lockout e throttling;
- confermare il comportamento reale dell'hash legacy e il percorso di migrazione;
- distinguere chiaramente login ordinario, sessione scaduta e account bloccato.

**Perche ora**

- l'autenticazione e la base di tutto il perimetro admin.

### R-02 - Standardizzare cookie e session hardening

- **Severita**: alta
- **Probabilita**: media
- **Impatto**: alto
- **Costo**: basso-medio
- **Rischio regressione**: basso

**Proposta**

- documentare e validare `Secure`, `HttpOnly` e `SameSite` per i cookie di sessione;
- richiedere `regenerateID()` sui flussi sensibili;
- mantenere il `Cache-Control` custom come protezione del browser back.

### R-03 - Allineare enforcement RBAC tra UI e server

- **Severita**: alta
- **Probabilita**: media
- **Impatto**: alto
- **Costo**: medio
- **Rischio regressione**: medio

**Proposta**

- verificare che ogni action sensibile abbia controllo server-side oltre al menu;
- mappare menu -> controller/action -> model per le aree admin piu critiche;
- centralizzare i casi speciali nel controller di abilitazione, non in view sparse.

### R-04 - Ridurre esposizione dati in grid ed export

- **Severita**: alta
- **Probabilita**: media
- **Impatto**: alto
- **Costo**: medio
- **Rischio regressione**: medio

**Proposta**

- applicare minimizzazione esplicita delle colonne esportate;
- rivedere escaping e rendering dei dati derivati;
- introdurre una checklist per campi sensibili, formule e valori calcolati negli export.

### R-05 - Governare le costanti runtime come asset sensibile

- **Severita**: media-alta
- **Probabilita**: media
- **Impatto**: alto
- **Costo**: medio
- **Rischio regressione**: medio

**Proposta**

- classificare le costanti per sensibilita;
- limitare le modifiche ai soli ruoli autorizzati;
- tracciare le variazioni di costanti che influenzano menu, permessi e workflow.

### R-06 - Limitare leak informativi in error handling

- **Severita**: media-alta
- **Probabilita**: media
- **Impatto**: medio-alto
- **Costo**: basso
- **Rischio regressione**: basso

**Proposta**

- distinguere output DEV/PROD in modo netto;
- evitare stack trace o path completi verso il browser in ambienti non debug;
- mantenere il dettaglio solo nei log tecnici protetti.

### R-07 - Formalizzare hardening delle configurazioni ambiente

- **Severita**: media
- **Probabilita**: media
- **Impatto**: medio-alto
- **Costo**: medio
- **Rischio regressione**: basso-medio

**Proposta**

- verificare che segreti e credenziali non siano hardcoded;
- allineare i file environment e il comportamento per ambiente;
- introdurre una checklist di deploy con TLS e variabili sensibili.

## Backlog hardening prioritizzato

| Priorita | Intervento | Impatto | Costo | Rischio | Evidenza base |
|---|---|---|---|---|---|
| P1 | Allineare policy auth CRUGE e documentare lockout/throttling | Alto | Medio | Medio | `cruge_rbac_authentication.md`, `configuration_and_environments.md` |
| P1 | Formalizzare cookie/session hardening e login rotation | Alto | Basso-medio | Basso | `structure_and_functions.md`, `sophia_customizations.md` |
| P1 | Verificare enforcement RBAC server-side su action sensibili | Alto | Medio | Medio | `menu_and_permissions_management.md`, `cruge_rbac_authentication.md` |
| P2 | Minimizzare e validare export di dati sensibili | Alto | Medio | Medio | `export_management.md`, `structure_and_functions.md` |
| P2 | Governare costanti runtime con classificazione e audit | Alto | Medio | Medio | `costants_management.md` |
| P2 | Ridurre leak informativi in error handling | Medio-alto | Basso | Basso | `structure_and_functions.md`, `sophia_customizations.md` |
| P3 | Formalizzare hardening config ambiente e segreti | Medio-alto | Medio | Basso-medio | `configuration_and_environments.md` |

## Piano di validazione post-intervento

1. Verificare il comportamento login con account non privilegiati, account admin e sessione scaduta.
2. Controllare i flag cookie sulla sessione reale dell'app.
3. Testare la corrispondenza tra menu visibile e action effettivamente invocabile.
4. Eseguire un export con dataset contenente campi potenzialmente sensibili e controllare l'output.
5. Provare un errore applicativo in ambiente debug e non debug per confermare la segregazione dei dettagli.
6. Validare che le costanti runtime critiche siano modificabili solo con workflow controllato.

## Checklist verifiche eseguite

- [x] Correlazione menu -> controller/action -> model -> view
- [x] Correlazione autenticazione -> sessione -> autorizzazione
- [x] Evidenze cross-app consolidate riusate
- [x] Rischi front-end, back-end, sessione, configurazione e integrazione coperti
- [x] Proposte con severita, probabilita, impatto, costo e rischio regressione
- [x] Nessun riferimento a path assoluti non necessari

## Assunzioni, limiti e punti da validare col team

### Assunzioni

- Il corpus locale rappresenta la baseline corretta del layer framework.
- I rischi emersi vanno trattati come hardening prioritario, non come incidenti gia confermati.
- Il comportamento reale di hash, cookie e lockout va confermato sul codice runtime.

### Limiti

- Non sono stati eseguiti test runtime, penetration test o scansioni di sicurezza.
- Non abbiamo una mappa completa delle action di tutte le verticali clienti.
- La qualita dell'evidenza dipende dai documenti consolidati presenti nel repository.

### Punti da validare col team

- Quale policy password/lockout e attiva oggi in produzione.
- Se la sessione usa davvero tutti i flag cookie attesi.
- Se esistono action amministrative non ancora censite nella documentazione.
- Se gli export contengono mai dati soggetti a minimizzazione o segregazione.
- Se il team vuole prima chiudere il blocco auth/session o il blocco export/configurazione.

## Scopo
Descrivere obiettivo operativo e risultato atteso.

## Perimetro
Definire modulo, confini funzionali e prerequisiti.

## Flusso
1. Input e contesto.
2. Esecuzione del processo.
3. Output e verifica.

## Componenti
- Controller/servizi.
- Model e tabelle.
- Job/log/integrazioni correlate.

## Failure mode
- Errori ricorrenti.
- Cause tipiche.
- Segnali diagnostici.

## Checklist
- Pre: prerequisiti validati.
- Post: outcome e coerenza dati verificati.

## Criteri di accettazione
Contenuto azionabile, verificabile e coerente con il codice.