Servizio SaaS "qualificato" con validazione lato client

Ciao a tutti, per puro caso (dovendo iscrivere mio figlio ai servizi di doposcuola) mi sono imbattuto in un sito web di prenotazioni mensa e servizi scolastici che il mio comune di residenza ha reso obbligatorio ma non mi pare fatto “a regola d’arte”.

  • non utilizza SPID ne qualsiasi altra identità federata;
  • l’utente è abilitato immediatamente senza alcuna verifica di email e cellulare;
  • l’informativa privacy GDPR rinvia solo alla responsabilità comune e al suo DPO anche se è evidente che il database è gestito dal fornitore
  • tutti i dati inseriti nei form (e sono molti) sono soggetti solo a validazione lato client (compresi i criteri di complessità della password)
  • non sembra che la password abbia una scadenza predeterminata

Con una piccola indagine scopro che il servizio è qualificato da gennaio nel marketplace di Agid ma come è possibile? Come si può dichiarare conforme OWASP la validazione lato client e nessuna validazione dell’indirizzo email? E’ conforme alle pratiche di sicurezza un sito che risponde “utente sconosciuto” se l’utente è sbagliato mentre risponde “utente e/o password non valida” se l’utente è giusto? Mi pare di capire che la qualificazione su base su dichiarazioni del fornitore, così come in MEPA (dove il servizio è venduto nel bando “BENI”) ma come fare per fare effettuare controlli?

Amefad

3 Mi Piace

La validazione è fatta su autodichiarazioni spesso validate solo “burocraticamente”:
il risultato è quello da te evidenziato.

1 Mi Piace

Ciao @Amedeo_Fadini,
giusto per curiosità, come sai che la validazione lato client non è accompagnata da una parallela validazione lato server?

l’informativa privacy GDPR rinvia solo alla responsabilità comune e al suo DPO anche se è evidente che il database è gestito dal fornitore

Sull’informativa privacy ti devo dire che anche il nostro DPO considera che questa sia una pratica buona da un punto di vista dell’utente finale. Non sono un esperto, ma un approccio ideale potrebbe essere che la privacy policy dell’Ente contenga regole generali e valide per tutti i servizi erogati da questo e che i vari software/fornitori/servizi si adeguino alla policy generale del comune. Se un ente offre 50 servizi online è sconveniente che lo faccia con 50 regole distinte e dettagliate in 50 privacy policy, che il cittadino dovrebbe spulciare una per una alla ricerca delle microdifferenze tra una e l’altra. E’ piu’ sensato che la Privacy Policy sia una e che sia casomai questa a evidenziare qualche piccola differenza in qualche caso particolare. A me sembra ragionevole, ma capisco che magari il tuo caso era palesemente un altro :slight_smile:

ma come fare per fare effettuare controlli?

Beh, penso che una checklist con i controlli di base che hai fatto anche tu sarebbe già un ottimo inizio, ma come dice @Andrea_Tironi1 io temo invece che i controlli siano piu’ basati sull’aspetto documentale.

Attenzione pero’ su quali aspetti si concentra la qualificazione: si tratta per lo piu’ di aspetti sistemistico-informatici (il cloud dove gira) , disponibilità del servizio, disponibilità di API. C’e’ qualcosa di rispetto del GDPR ma si sa che il GDPR non dà prescrizioni direttamente verificabili ma incentiva solo la responsabilizzazione del titolare del trattamento.

Che il software sia conforme alla normativa o che non la violi è una responsabilità in capo a chi lo compra (autenticazione SPID inclusa, per dirne una).

Ciao @lorello e grazie per gli spunti (era mia intenzione stimolare una discussione piuttosto* che lamentarmi ).

come sai che la validazione lato client non è accompagnata da una parallela validazione lato server?

Ho perso un pochino di tempo disabilitando jquery.validate con qualche riga di javascript e ho registrato con successo alcuni utenti… ho usato codici fiscali di noti politici associati a nomi di supereroi dei fumetti, codici fiscali inventati con codice comune inesistente, password tutte minuscole (qui c’è un controllo lato server sulla lunghezza, registra l’utente con password da 2 caratteri ma poi non lo fa loggare) e ho inviato con successo una domanda di iscrizione alla mensa con TUTTI i campi vuoti che è risultata poi visibile tra quelle “in lavorazione” (questo potrebbe non essere un problema perché non escludo che lo scopo del sistema sia generare un pdf).

Il nome utente è composto dal codice fiscale e se il codice fiscale è già registrato restituisce errore… avendo tempo non credo sia tanto complicato indovinare la password di un altro utente

In questa attività di testing mi resta il dubbio se possa essere considerato reato registrare nomi di fantasia… ma del resto non ci sono disclaimer nella pagina di registrazione.

Sull’informativa privacy ti devo dire che anche il nostro DPO considera che questa sia una pratica buona da un punto di vista dell’utente finale

quel che a me lascia perplesso è come può il DPO dell’ente sottoscrivere che i dati sono adeguatamente protetti se l’ente non ha acesso al database?

Sul controllo documentale, sono sostanzialmente d’accordo, è un modo per risparmiare soldi pubblici, di fatto Agid si riserva di fare verifiche dopo la qualificazione. Ho scritto una segnalazione a Consip tramite lo strumento integrato nel mepa (per il bando “BENI”) e una al difensore civico digitale vediamo come va…


*uso disgiuntivo

PS: visto che e’ un servizio online pubblicato, presente su marketplace e su MEPA, forse si possono fare anche i nomi,no?

uso unico, aggiungerei!

1 Mi Piace

Che il software sia conforme alla normativa o che non la violi è una responsabilità in capo a chi lo compra (autenticazione SPID inclusa, per dirne una).

Ecco questo è il punto… a conti fatti sembra che il prodotto venduto non sia conforme alla scheda di qualificazione… ma se mi metto nei panni del mio comune non vale la pena approfondire i requisiti: il software funziona e i rischi di privacy ci sono dappertutto… sono stati molto disponibili a consentirmi l’iscrizione via PEC e si sono attivati per SPID, è già molto a mio parere.

Beh, se ci sono anche requisiti da circolare SaaS non soddisfatti il discorso cambia. Su quelli il Comune, anche volendo e potendo, a mio avviso non dovrebbe ritornare ma darli per verificati dall’autorita’, cosi’ da impiegare le proprie risorse più produttivamente.

Grazie Amedeo, la tua spiegazione è stata molto utile.
Mi sembri esperto di sicurezza (almeno più di me) quindi do per scontato che all’indirizzo del servizio /.well-known/security.txt tu non abbia trovato recapiti a cui segnalare queste vulnerabilità :frowning:

Il DPO detta le regole a cui il fornitore deve sottostare e queste regole diventano parte integrante del contratto di fornitura… si torna ai documenti lo so, ma l’accesso al database non è pensabile quando si acquista SaaS… dubito che un qualunque DPO di un ente che adotta le Google Apps abbia accesso al database :slightly_smiling_face:
Come nel caso di Google è facile avvenga il contrario: il DPO verifica che le regole di trattamento dei dati del fornitore siano compatibili con quelle proprie.
Nelle aziende private non si fa molto diversamente, nell’azienda dove lavoro per esempio abbiamo escluso qualche servizio che volevamo usare perché fornito da datacenter in paesi che non ci davano sufficienti garanzie.

Sulla responsabilità del Comune io mi pongo un po’ di dubbi: tutto il sistema di qualificazione dovrebbe servire appunto a porre un livello di qualità di base sotto al quale non si può scendere, se non garantisce quel livello minimo è un problema serio, mi sembra davvero strano che si possa imputare una responsabilità all’Ente.