Guida completa ai codici di stato HTTP: la serie 400

I problemi con un client user-agent possono andare dalla richiesta di risorse non più disponibili (per un URI digitato male) fino al server che reagisce a richieste che corrispondono alla firma di un attacco.

Il più comune è il 404. 404 Not Found viene restituito quando un client richiede una risorsa che il web server non riesce a trovare:

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/vgadNRN.jpg (unchanged, 945x534); alt: Google 404 Documento non trovato; caption: 404 Documento non trovato digitando male un URL

Esaminiamo un po' più in dettaglio i codici di risposta della serie 400 più comuni e interessanti.

400 Bad Request

400 Bad Request è (di solito) il risultato di uno user-agent che invia nella richiesta qualcosa che il web server non è riuscito a elaborare. Generiamo un 400 Bad Request per capire cosa può causare questo errore.

Faremo alla vecchia maniera su Linux e useremo uno strumento chiamato netcat. Netcat serve a inviare dati grezzi sui socket. Dopotutto le richieste HTTP/1.1 sono proprio questo: testo grezzo.

Prima inviamo una richiesta HEAD legittima a Google:

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/MAUd94u.jpg (unchanged, 906x332); alt: Richiesta HEAD da netcat; caption: Il web server ha risposto con 200.

Forziamo un 400 Bad Request:

• image (aligncenter): src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged, 700x400); alt: Richiesta malformata forzata che genera un 400

Abbiamo inviato di proposito una richiesta che il server non poteva capire. Guardiamo il metodo di richiesta usato:

$ nc www.google.com 80
BAD / HTTP/1,1
Host: www.google.com

Il web server non ha potuto elaborare il metodo: BAD

È improbabile che un browser moderno invii richieste malformate come quella mostrata sopra. Ma se usate un'applicazione HTTP sviluppata su misura, come un web scraper, è ora di fare debug.

Questi passaggi risolvono la maggior parte degli errori 400 comuni.

1. Controllate l'URL

Se avete cliccato un link, è del tutto possibile che l'autore della pagina abbia fatto un errore di battitura. Esaminate l'intero URL prestando particolare attenzione al percorso, al nome del documento e alla query string.

2. Cancellate tutti i cookie e la cache

Cancellare cookie e cache risolve molti errori 400, ed è un buon primo passo anche per molti altri codici di stato 400.

1. cancellate tutti i cookie e la cronologia di navigazione
2. riprovate la richiesta

In Chrome, Edge e Firefox l'opzione si trova nelle impostazioni del browser sotto Privacy, di solito chiamata «Cancella dati di navigazione»; i nomi dei menu variano con la versione. Spesso basta cancellare i cookie del solo sito interessato.

Cancellare tutti i cookie e la cronologia garantisce che qualsiasi cosa in cache e/o corrotta (come i cookie) sia sparita. Questo spesso risolve un 400 Bad Request.

3. Dimensione del file caricato

Il problema potrebbe benissimo essere uno script di back-end, il caricamento di un file troppo grande o di un file con un media type non corretto.

1. Se il 400 Bad Request si presenta durante il caricamento di un file, provate con un file più piccolo.
2. Assicuratevi che il tipo di file sia accettato.
3. Se caricate un'immagine, provate sia il formato jpeg che il png.
4. Se caricate un documento, il testo semplice e i formati office comuni sono di solito consentiti.

4. Header malformati

Header malformati sarebbero un problema di livello piuttosto basso, e potrebbero benissimo indicare una colpa dell'applicazione web stessa.

Gli strumenti per sviluppatori integrati in ogni browser moderno (la scheda Network) permettono di osservare l'intera transazione HTTP alla ricerca di qualcosa di anomalo.

5. Aggiornate il browser e disabilitate i plugin

Se il browser non è aggiornato, potrebbe benissimo inviare header e richieste antiquati.

Provate anche a rimuovere o disabilitare tutti i plugin e le estensioni. Anche provare la stessa richiesta in un altro browser aiuta a isolare i problemi.

6. Provate a disconnettervi

Se usate un'applicazione web con autenticazione utente e sessioni, provate a disconnettervi e poi a cancellare la cache del browser.

(hr)

401 Unauthorized

Il 401 Unauthorized viene restituito quando un web server richiede credenziali per un documento protetto.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/3DUV4qt-e1513087231705.jpg (unchanged, 700x479); alt: Autorizzazione richiesta; caption: La risposta HTTP sarà 200 una volta fornite credenziali valide

403 Forbidden

Il 403 Forbidden è di solito una di quattro cose:

• i listing delle directory non sono consentiti
• l'utente attualmente autenticato non ha permessi sufficienti
• il processo del web server ha permessi inadeguati
• l'indirizzo richiedente è stato bandito

Listing delle directory non consentito

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/U48hysZ.jpg (unchanged, 703x368); alt: HTTP 403 Forbidden; caption: Mostra 403 Forbidden quando si tenta di accedere al listing di una directory

Qui il web server non consente i listing delle directory agli utenti non autenticati. La correzione più semplice è mettere un file index nella directory. Altrimenti, i listing per gli utenti non autenticati dovranno essere abilitati esplicitamente.

L'utente autenticato non ha i permessi

Il metodo migliore in questa situazione è creare un gruppo per tutti gli utenti che devono accedere a una risorsa. Date a questo gruppo i permessi necessari a livello di file system. Poi aggiungete al gruppo gli utenti autorizzati.

Il processo del web server non ha permessi sufficienti

• image (aligncenter): src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged, 460x167); alt: Accesso negato

Non riusciamo ad accedere alla pagina test.php nella webroot in /var/www/html. Su RHEL e i suoi derivati (Oracle Linux, AlmaLinux, Rocky Linux) ci sono due cose da controllare: i permessi classici dei file e il contesto SELinux.

Primo, controllate proprietà e permessi:

# ls -ld /var/www/html/
drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/

La directory appartiene all'utente root e al gruppo root senza alcun accesso per gli altri, quindi il processo del web server (utente apache per Apache httpd, nginx per nginx) non può leggerla. Date al gruppo del web server l'accesso in lettura, senza scrittura:

# chgrp -R apache /var/www/html
# chmod 750 /var/www/html
# chmod 640 /var/www/html/test.php
# ls -ld /var/www/html/
drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/
# ls -l /var/www/html/test.php
-rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.php

Secondo, controllate il contesto SELinux. I file spostati nella webroot da altrove conservano la vecchia etichetta, e SELinux blocca allora il web server anche quando i permessi sono corretti:

# ls -Z /var/www/html/test.php
# restorecon -Rv /var/www/html

Il contenuto sotto /var/www/html dovrebbe avere il tipo httpd_sys_content_t. Correggete l'etichetta con restorecon; non disabilitate mai SELinux per far sparire un 403.

Come buona pratica di sicurezza, il gruppo del web server non dovrebbe avere permessi di scrittura su file e cartelle. Dove un content management system deve scrivere (una cartella uploads, per esempio), concedete l'accesso in scrittura solo a quella cartella, e su RHEL assegnatele il tipo SELinux httpd_sys_rw_content_t.

Negare i permessi di scrittura su file e cartelle può offrire un livello di sicurezza in più nel caso in cui una falla dell'applicazione web venga sfruttata da un attaccante per modificare contenuti, eliminare file o aggiungerne.

In un ambiente di staging, mettete gli sviluppatori nel gruppo del web server e date a quel gruppo l'accesso in scrittura; tenete la produzione in sola lettura.

Un altro scenario comune per uno stato 403 Forbidden può essere un indirizzo IP o un intervallo di IP bandito in un file .htaccess dall'amministratore del server.

404 Not Found

404 Not Found significa che il web server non ha trovato la risorsa richiesta. Quando si incontra un errore 404 si possono fare alcune cose:

• controllare l'ortografia di host, dominio, percorso e documento
• controllare maiuscole e minuscole di file e percorso. I web server Linux e Unix (se non configurati diversamente) di solito distinguono le maiuscole, con la tradizione di usare tutto minuscolo per ciascuno.
• usare Google per trovare un URL alternativo alla risorsa
• provare una copia archiviata della pagina nella Wayback Machine dell'Internet Archive

Usare gli operatori di ricerca avanzata di Google

• image (aligncenter): src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged, 700x511); alt: Google, trovare tutti i file PDF

Una query come quella sopra, con operatori come site: e filetype:, spesso trova un documento il cui vecchio link ora restituisce un 404.

Se la pagina è stata rimossa, la Wayback Machine dell'Internet Archive potrebbe conservarne ancora una copia più vecchia.

405 Method Not Allowed

Un 405 Method Not Allowed viene presentato quando si tenta un metodo di richiesta non consentito dal web server.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/L9cGnEG-e1513087376858.jpg (unchanged, 700x322); alt: Richiesta non consentita a Google; caption: Richiesta OPTIONS non consentita

406 Not Acceptable

Il 406 Not Acceptable viene restituito quando il server non può fornire la risorsa in nessuno dei content type, encoding, lingue o set di caratteri che il client dichiara di accettare.

Per risolvere un 406, guardate gli header della richiesta negli strumenti per sviluppatori del browser (scheda Network).

I valori degli header inviati dal client da esaminare includono:

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

I browser moderni lo provocano raramente. Se il vostro lo fa, provate ad aggiornarlo a una versione più recente.

407 Proxy Authentication Required

407 Proxy Authentication Required di solito significa che lo user-agent deve fornire credenziali per accedere a un proxy server.

• image (aligncenter): src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged, 567x331); alt: Fornire le credenziali del proxy in Linux

408 Request Timeout

Il 408 significa che il server ha atteso troppo a lungo che il client finisse di inviare la sua richiesta; di solito indica una connessione client lenta o instabile, più che un problema del server.

429 Too Many Requests

Il 429 di solito significa che sul server è attivo il rate limiting. Il rate limiting consente solo un certo numero di richieste in un intervallo di tempo stabilito.

Quando ricevete 429 Too Many Requests, rallentate. Il server può inviare un header Retry-After che dice quanto attendere prima di riprovare; i client e gli script ben educati lo rispettano e si fermano.

451 Unavailable for Legal Reasons

Il 451 viene restituito quando il server è legalmente tenuto a bloccare l'accesso a una risorsa, per esempio dopo un'ordinanza del tribunale.