Chiarimento su protezioni CSRF e Content Security Policy (CSP) per script PHP

[giostrumenti]

Ciao a tutti,

Sto sviluppando uno strumento per la generazione di palette di colori. Trattandosi di uno strumento che gestisce input e output in PHP, mi stavo chiedendo sulle misure di sicurezza necessarie.

In particolare, vorrei sapere se la piattaforma Altervista implementa già di default delle protezioni a livello server per:

Protezione CSRF : È necessario che io generi e convalidi manualmente i token nelle sessioni PHP per ogni form, o esiste un filtro globale della piattaforma?

Content Security Policy: Gli header di sicurezza vengono gestiti/imposti da Altervista o devo configurarli io tramite il file .htaccess o direttamente via PHP con la funzione header()?

Vorrei evitare di scrivere codice ridondante se queste misure sono già attive a livello di sistema, ma allo stesso tempo non voglio lasciare lo script vulnerabile.

Grazie in anticipo

[alemoppo]

AlterVista supporta normalmente PHP (incluse sessioni con session_start() e $_SESSION).

Per quanto riguarda però la sicurezza, non ci sono protezioni automatiche a livello applicativo: la protezione CSRF va implementata nel codice, così come eventuali header di sicurezza (es. CSP), che non vengono impostati automaticamente. Se ti servono, puoi impostarli tramite header().

Ciao!

[giostrumenti]

AlterVista supporta normalmente PHP (incluse sessioni con session_start() e $_SESSION).

Per quanto riguarda però la sicurezza, non ci sono protezioni automatiche a livello applicativo: la protezione CSRF va implementata nel codice, così come eventuali header di sicurezza (es. CSP), che non vengono impostati automaticamente. Se ti servono, puoi impostarli tramite header().

Ciao!

Grazie mille per il chiarimento.

A questo punto, per mantenere il codice PHP più pulito e non dover scrivere le intestazioni in ogni script, pensavo di gestire gli header di sicurezza (come la CSP, X-Frame-Options, ecc.) direttamente tramite il file .htaccess.

AlterVista permette l'uso della direttiva Header set (modulo mod_headers)? In questo modo potrei applicare una protezione globale a livello di directory per tutti i tool che svilupperò, senza appesantire i singoli file .php.

[alemoppo]

Le direttive .htaccess disponibili sono elencate qui.
Il modulo mod_headers non è disponibile, quindi va usato tramite header(). Come protezione globale puoi includere un file PHP in tutti gli script, in ogni caso non è una modifica significativa che apporta più pesantezza alle richieste.

Ciao!

[giostrumenti]

Le direttive .htaccess disponibili sono elencate qui.
Il modulo mod_headers non è disponibile, quindi va usato tramite header(). Come protezione globale puoi includere un file PHP in tutti gli script, in ogni caso non è una modifica significativa che apporta più pesantezza alle richieste.

Ciao!

Seguirò il consiglio: creerò un file da includere in tutti i miei script per gestire centralmente gli header e la sessione.

A questo punto, per non lasciare nulla al caso prima del lancio pubblico, quali ritenete siano le priorità assolute da gestire via PHP su Altervista per evitare i vettori di attacco più comuni (oltre a CSRF e CSP)?

[dreadnaut]

A questo punto, per non lasciare nulla al caso prima del lancio pubblico, quali ritenete siano le priorità assolute da gestire via PHP su Altervista per evitare i vettori di attacco più comuni (oltre a CSRF e CSP)?

I vettori di attacco dipendono dalle funzionalità che implementi, e dai rischi per il tuo sistema od i tuoi utenti.

Una content security policy è utile se i tuoi utenti possono inserire contenuti nelle pagine viste da altri. Le richieste da altri siti sono un problema se impersonare un utente può fare danni.

Se stai generando una serie di colori basandoti su alcuni parametri... forse non sono necessarie?

Detto questo, non vorrei over-semplificare. Se ci dai più dettagli su quello che fa il sito possiamo essere più precisi. (in particolare: database? utenze? dati lato server?)

Nota: proteggersi da CSRF via token è (quasi) obsoleto, ora che c'è l'header sec-fetch-site. Vedi ad esempio: https://blog.miguelgrinberg.com/post...en-form-fields

[giostrumenti]

I vettori di attacco dipendono dalle funzionalità che implementi, e dai rischi per il tuo sistema od i tuoi utenti.

Una content security policy è utile se i tuoi utenti possono inserire contenuti nelle pagine viste da altri. Le richieste da altri siti sono un problema se impersonare un utente può fare danni.

Se stai generando una serie di colori basandoti su alcuni parametri... forse non sono necessarie?

Detto questo, non vorrei over-semplificare. Se ci dai più dettagli su quello che fa il sito possiamo essere più precisi. (in particolare: database? utenze? dati lato server?)

Nota: proteggersi da CSRF via token è (quasi) obsoleto, ora che c'è l'header sec-fetch-site. Vedi ad esempio: https://blog.miguelgrinberg.com/post...en-form-fields

In pratica, dispongo di vari strumenti, tra cui un convertitore di colori, un compressore di immagini e un generatore di password si tratta di tool piuttosto semplici. Vorrei quindi capire quante linee di codice (o protocolli) di sicurezza dovrei implementare in ognuno di essi per garantire una buona base di protezione

[dreadnaut]

Se ho capito bene a) niente utenti a cui rubare dati, e b) niente database da danneggiare?

In questo caso, suggerirei due cose:

- protezione da CSRF via sec-fetch-site (vedi sopra)
- protezione da denial-of-service: assicurati che i tool non possano 'accumulare' dati e riempire lo spazio web (e.g., se hai una directory temporanea, svuotala automaticamente)

[giostrumenti]

Se ho capito bene a) niente utenti a cui rubare dati, e b) niente database da danneggiare?

In questo caso, suggerirei due cose:

- protezione da CSRF via sec-fetch-site (vedi sopra)
- protezione da denial-of-service: assicurati che i tool non possano 'accumulare' dati e riempire lo spazio web (e.g., se hai una directory temporanea, svuotala automaticamente)

In realtà devo rettificare: pur non avendo un sistema di registrazione utenti (quindi niente email/password), il database è attivo e ospita tabelle per un calendario di impegni, una rubrica contatti e un gestore di coordinate geografiche.
​Quindi non ci siano profili personali, c'è il rischio che un malintenzionato possa iniettare codice per svuotare le tabelle o leggere i dati inseriti da altri.
​A questo punto, oltre alla protezione CSRF e alla gestione dello spazio web per i file temporanei, quali precauzioni suggerite per blindare le query SQL su Altervista? È sufficiente affidarsi interamente a PDO con i Prepared Statements per dormire sonni tranquilli contro le SQL Injection?

[dreadnaut]

Si, prepared statement per le query, facendo attenzione a validare i nomi delle colonne se hai ORDER BY dinamici. Questo copre l'input.

(e se ti interessa, ti vendo anche pigroSQL )

Per l'output, è saggio usare htmlspecialchars() o simile per stringhe inserite (in precedenza) dagli utenti, così da evitare script injection / XSS. Se ti appoggi ad una libreria per i template, di solito lo fa per te.

[giostrumenti]

Si, prepared statement per le query, facendo attenzione a validare i nomi delle colonne se hai ORDER BY dinamici. Questo copre l'input.

(e se ti interessa, ti vendo anche pigroSQL )

Per l'output, è saggio usare htmlspecialchars() o simile per stringhe inserite (in precedenza) dagli utenti, così da evitare script injection / XSS. Se ti appoggi ad una libreria per i template, di solito lo fa per te.

grazie per le dritte sugli ORDER BY dinamici e l'importanza di htmlspecialchars() per l'output.

A questo punto, per procedere allo sviluppo in modo sistematico, ho stilato questa checklist di protocolli da implementare nel mio file di sicurezza globale e nei singoli tool. Vi sembra completa o aggiungereste altro per blindare ulteriormente lo spazio su Altervista?

1) Connessione DB: Passaggio totale a PDO con Prepared Statements per ogni query.

2) Validazione Input: Uso di whitelist per nomi colonne/tabelle e filter_var() per tipi dato specifici (email, int, float).

3) Protezione XSS: Applicazione sistematica di htmlspecialchars() su ogni stringa stampata a video che provenga dal DB o da input utente.

4) Sicurezza Sessioni: Configurazione session_set_cookie_params con flag httponly e samesite => Lax.

5) Header di Sicurezza: Inserimento via PHP di X-Frame-Options: DENY e una Content-Security-Policy di base.

6) Gestione Risorse: Script di pulizia automatica (cron o all'avvio) per le cartelle temporanee dei tool di compressione immagini.

C'è qualche altro protocollo o limite specifico di Altervista (magari lato permessi file o upload) di cui dovrei tenere conto?

[dreadnaut]

Mi sembra un'ottima lista, e non mi viene in mente altro ✅

[giostrumenti]

Mi sembra un'ottima lista, e non mi viene in mente altro ✅

Su 18 strumenti finirò non so quando..