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)