Un errore 403 proibito si verifica più frequentemente quando i nostri sistemi di sicurezza stanno proteggendo il tuo sito. Molto spesso, il nostro firewall per applicazioni Web (chiamato Mod Security o modsec) protegge il tuo sito Web da tentativi di hacking automatizzati.
Tuttavia, in alcuni casi, le azioni legittime possono essere erroneamente identificate come un attacco e la tua azione verrà bloccata. Questo è chiamato un falso positivo. Ecco alcuni scenari comuni in cui ciò accade:
- Utilizzando qualsiasi costruttore di siti Web, potrebbe non riuscire a salvare le modifiche
- Se utilizzi il tema/builder Divi per WordPress, indicherà qualcosa come "Errore durante il salvataggio della pagina", quindi fornirà un elenco di potenziali cause.
- Quando aggiungi codice javascript o PHP tramite il pannello di amministrazione del tuo sito web (e non Plesk File Manager o FTP).
Se ricevi un errore 403 proibito che non corrisponde a una delle azioni di cui sopra, ti consigliamo di consultare prima la nostra guida generale alla risoluzione degli errori 403.
Questo può accadere apparentemente all'improvviso perché le nostre regole firewall vengono aggiornate settimanalmente; aggiungendo potenzialmente nuove regole ogni settimana che potrebbero influire sul funzionamento del tuo sito. Tieni presente che è molto probabile che le regole influiscano sull'invio dati al server, ad esempio quando invii un modulo o aggiorni i dati nel back-end del tuo sito.
Come trovare e interpretare i log del firewall
Il primo passo è controllare i log del server per scoprire perché sta fornendo un tale errore. Consulta la nostra guida su come utilizzare il file manager Plesk per analizzare i log del tuo sito web.
Poiché il nostro firewall per applicazioni web aiuta a bloccare gli attacchi comuni, potresti vedere molte voci ModSecurity nel registro . È importante identificare le voci di registro che direttamente corrisponda all'azione che stai intraprendendo, altrimenti finirai per indebolire il firewall e non risolvere il problema allo stesso tempo.
Gli errori relativi al firewall saranno simili a questo:
ModSecurity: Access denied with code 403 (phase 2).
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas.
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"]
[id "212770"] [rev "4"]
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"]
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}]
[severity "CRITICAL"] [hostname "customerdomain.tld"]
[uri "/specific_uri_requested/"] La nostra voce di registro di esempio sopra è un falso positivo che si è verificato durante l'invio di un modulo Gravity Forms con un'immagine allegata.
Abbiamo ritagliato un po' di gobbledygook e lo abbiamo sostituito con {{{{snipped}}}} per renderlo un po' più leggibile. Abbiamo anche reso alcune parti in grassetto per indicare ciò che è più rilevante per noi.
Leggendo le sezioni in grassetto in ordine, questo errore indica che il firewall ha trovato:
- L'accesso è stato negato con un errore proibito (codice 403 ) (Nota:se non vedi 'codice 403' o 'Accesso negato', allora la voce di registro ModSecurity che stai guardando non è rilevante:passa a quella successiva. Alcune voci sono per il debug o informazioni generali, non sono tutti per il blocco.)
- Un qualche tipo di script (javascript, livescript , ecc.)
- Utilizzando l'ID regola 212770
- Che considerava un attacco XSS (Cross Site Scripting)
- Quando inviava un'immagine in formato base64 codificato (data:image/png;base64 )
- Con gravità "CRITICA" (Nota se vedi una gravità di DEBUG o WARNING, non è probabile che siano responsabili di un errore 403 visibile)
- Sull'URI /specific_uri_requested/
Il firewall sta diventando piuttosto nervoso per questo! Comprensibile:è uno script casuale con dati dall'aspetto strano...
Poiché sappiamo che il problema si verifica quando un utente legittimo invia un Gravity Form e c'è effettivamente un'immagine coinvolta, questo è probabilmente un caso d'uso legittimo e quindi l'errore è un falso positivo.
Apri un ticket se hai bisogno di aiuto per l'interpretazione! Assicurati di includere la voce di registro in modo che possiamo analizzarla rapidamente per te.
Di seguito troverai due modi per aggirare questi errori:1) disabilitare il firewall (consigliato solo in casi selezionati) e 2) escludere le regole particolari che generano il falso positivo.
Soluzione 1 (temporanea):sviluppo? Disabilita Firewall
Se stai attualmente sviluppando il sito, è meglio semplicemente disabilitare completamente il firewall, poiché è probabile che ti imbatti in una serie di ostacoli quando invii il codice al server tramite HTTP (ad es. Salvando una modifica CSS) all'interno di WordPress.
Ricordati di riattivare il firewall quando hai finito di modificare il sito, altrimenti il tuo sito non sarà protetto da un gran numero di attacchi comuni.
Ecco come disabilitarlo:
- In Plesk, torna a "Siti web e domini" o "Domini" e fai clic sul dominio.
- Fai clic su "Web Application Firewall".
- In "Modalità firewall applicazione Web" scegli "Off".
Nota:se scegli "Solo rilevamento", il nostro firewall a livello TCP rileverà comunque le voci di registro e istituirà ban temporanei. Off è meglio durante lo sviluppo. - Fai clic su OK o Applica per salvare.
Al termine dello sviluppo, riattiva il firewall seguendo gli stessi passaggi, ma scegliendo "On" anziché "Off".
Soluzione 2 (permanente):esclusione delle regole ModSec
Se gli utenti del tuo sito intraprendono la stessa azione che hai fatto tu che ha attivato il 403 su base regolare, disabilitare completamente il firewall non funzionerà!
Invece, andiamo avanti ed escludiamo questa regola dal firewall per il dominio. Nel nostro esempio sopra, abbiamo identificato l'ID regola di sicurezza 212770, ma il tuo sarà sicuramente diverso. Scansiona la voce del registro finché non trovi l'ID, sarà simile a questo:[id “212770”] poi…
- In Plesk, torna a "Siti Web e domini"
- Fai clic su "Web Application Firewall".
- In "Disattiva regole di sicurezza" inserisci il numero ID che hai trovato nel registro (di solito uno per riga, se ne hai più di uno).
- Fai clic su OK o Applica per salvare.
Ora prova a eseguire l'azione che ha causato il problema in precedenza.
Se il problema NON è stato risolto e ricevi ancora un errore 403, è probabile che l'azione abbia attivato più regole del firewall. Ripeti il processo sopra finché non hai trovato ed escluso tutti gli ID regola che causano problemi. Tieni presente che se sono presenti più ID regola che causano questo errore, è probabile che siano molto simili, quindi osserva attentamente quando controlli le ultime voci di registro per assicurarti che quelle che vedi siano leggermente diverse da quelle che hai già escluso.
Il massimo che abbiamo dovuto escludere in una sola seduta è 5, quindi c'è una buona probabilità che tu risolva il problema in appena 2 o 3 esclusioni.
Risoluzione dei problemi
Se escludi una serie di regole, raggiungi un errore come questo che non ha un ID associato:
ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).
Ciò significa che dovrai aumentare quei limiti. Se disponi dell'accesso amministrativo a Plesk, puoi inserire quanto segue in Strumenti e impostazioni> ModSecurity> scheda Impostazioni> Direttive personalizzate:
SecResponseBodyLimit 546870912SecRequestBodyInMemoryLimit 546870912
Se non disponi dell'accesso amministrativo a Plesk e sei ospitato da noi, apri un ticket e ci penseremo noi!