ModSecurity: CRS 20, protocol violations, versione 1.5 | ALTRI capitoli | |||
Questa è la versione ver.1.5 del file
La prima direttiva imposta le azioni di default da attivare nel caso di un riscontro positivo. Conosciamo già il significato di ciascuna azione: nella fase 2 ( buffering ed analisi del Request Body ), non bloccare la transazione (
L'influenza di questa direttiva dura fino alla successiva direttiva
Questa regola 960911, Core ModSecurity Rule Set ver.1.5, è molto simile alla regola 960911, Core ModSecurity Rule Set ver.2.2.3 ( già vista alla pagina ModSecurity: CRS 20, protocol violations, Regola 960911, ma contiene alcune sostanziali differenze:
SecRule 960011 - REQUEST_METHOD: catena di regole La prima catena di regole è composta da due sole regole (
Quindi: questa catena verifica se il metodo HTTP usato per inviare la richiesta è un metodo GET o HEAD:
per poi controllare che, se la richiesta usa il metodo GET o HEAD, non sia presente un BODY:
L'azione di flusso:
dice a ModSecurity che la regola corrente è legata alla regola immediatamente successiva. Quindi, se la regola corrente ha dato esito negativo ( nel nostro caso, se il metodo HTTP utilizzato è POST o CONNECT, per esempio ), la regola immediatamente successiva deve essere saltata. Se, invece, la regola corrente ha dato esito positivo ( nel nostro caso, se il metodo HTTP utilizzato è GET o HEAD ), si deve passare alla regola immediatamente successiva. In una catena di regole, può esserci una sola azione di tipo "disruptive" (
allora, esegui le azioni previste, compresa l'azione di tipo "disruptive" ( la presenza di un header HTTP
verranno eseguite durante l'esecuzione della regola che le contiene ( in caso di riscontro positivo ). Le azioni di tipo
seguono le stesse regole delle azioni di tipo "disruptive": devono essere impostate una sola volta, all'interno di una catena di regole, e vengono eseguite solo al riscontro positivo dell'ultima regola appartenente alla catena. Ricordate che alcuni di questi metadati li ritroverete nel messaggio di errore del vostro server ( error log ). Una catena di regole si chiude quando una regola appartenente alla catena corrente non contiene l'azione
il cui ID è quello della catena di appartenenza: 960011. SecRule 960012 - REQUEST_METHOD: catena di regole
Anche questa seconda catena di regole è composta da sole due direttive
che verifica una eguaglianza. SecRule 960013 - REQUEST_HEADERS:Transfer-Encoding
Questa regola respinge (
In questo esempio, abbiamo un server che invia, al client, una risposta, il cui BODY viene suddiviso in due chunk di dati:
di cui il primo ha una lunghezza di 26 ottetti ( 1A in notazione esadecimale ), mentre il secondo ha una lunghezza di 16 ottetti ( 10 in notazione esadecimale ). L'ultimo chunk ha una lunghezza pari a zero ottetti, che indica, ovviamente, la fine del messaggio. Se la risposta venisse inviata senza effettuare alcun Transfer-Encoding, avremmo:
Dicevo, prima, che, in realtà, non è vero che ModSecurity non supporta l'invio di dati frammentati. A questo proposito, è interessante leggere quello che scriveva Ivan Ristic ( l'autore di ModSecurity ), nel mese di dicembre 2009, a proposito del file che stiamo analizzando (
|
||||
ModSecurity: CRS 20, protocol violations, versione 1.5 | Le guide di .bit: contenuto originale |