diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -487,6 +487,7 @@ - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) + - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index 90b934c0c..fbbbab9c2 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -2,53 +2,60 @@ {{#include ../banners/hacktricks-training.md}} -## Cross-Site Request Forgery (CSRF) Spiegato +## Cross-Site Request Forgery (CSRF) Spiegata -**Cross-Site Request Forgery (CSRF)** è un tipo di vulnerabilità di sicurezza presente nelle applicazioni web. Permette ad un attacker di eseguire azioni per conto di utenti ignari sfruttando le loro sessioni autenticate. L'attacco viene eseguito quando un utente, che ha effettuato il login sulla piattaforma della vittima, visita un sito malevolo. Questo sito poi genera richieste verso l'account della vittima tramite metodi come l'esecuzione di JavaScript, l'invio di form o il recupero di immagini. +**Cross-Site Request Forgery (CSRF)** è un tipo di vulnerabilità di sicurezza presente nelle applicazioni web. Permette agli attaccanti di eseguire azioni per conto di utenti ignari sfruttando le loro sessioni autenticate. L'attacco viene eseguito quando un utente, autenticato sulla piattaforma della vittima, visita un sito malevolo. Questo sito poi invia richieste all'account della vittima tramite metodi come l'esecuzione di JavaScript, l'invio di form o il caricamento di immagini. -### Requisiti per un attacco CSRF +### Prerequisiti per un attacco CSRF Per sfruttare una vulnerabilità CSRF, devono essere soddisfatte diverse condizioni: -1. **Identificare un'azione di valore**: l'attacker deve trovare un'azione che valga la pena sfruttare, come cambiare la password dell'utente, l'email o elevare privilegi. -2. **Gestione della sessione**: la sessione dell'utente dovrebbe essere gestita esclusivamente tramite cookies o l'HTTP Basic Authentication header, poiché altri header non possono essere manipolati per questo scopo. -3. **Assenza di parametri imprevedibili**: la richiesta non dovrebbe contenere parametri imprevedibili, poiché questi possono impedire l'attacco. +1. **Identify a Valuable Action**: l'attaccante deve trovare un'azione da sfruttare, come cambiare la password dell'utente, l'email o elevare i privilegi. +2. **Session Management**: la sessione dell'utente dovrebbe essere gestita esclusivamente tramite cookie o tramite l'header HTTP Basic Authentication, poiché altri header non possono essere manipolati per questo scopo. +3. **Absence of Unpredictable Parameters**: la richiesta non dovrebbe contenere parametri imprevedibili, poiché possono impedire l'attacco. -### Controllo rapido +### Quick Check -Puoi catturare la richiesta con Burp e verificare le protezioni CSRF; per testarla dal browser puoi cliccare su **Copy as fetch** e controllare la richiesta: +Puoi **catturare la richiesta in Burp** e verificare le protezioni CSRF; per testare dal browser puoi cliccare su **Copy as fetch** e controllare la richiesta:
-### Difese contro CSRF +### Defending Against CSRF -Possono essere implementate diverse contromisure per proteggere dagli attacchi CSRF: +Possono essere implementate diverse contromisure per proteggersi dagli attacchi CSRF: - [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Questo attributo impedisce al browser di inviare i cookie insieme alle richieste cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). -- [**Cross-origin resource sharing**](cors-bypass.md): La CORS policy del sito vittima può influenzare la fattibilità dell'attacco, specialmente se l'attacco richiede di leggere la risposta dal sito vittima. [Learn about CORS bypass](cors-bypass.md). -- **Verifica dell'utente**: richiedere la password dell'utente o la risoluzione di un captcha può confermare l'intenzione dell'utente. -- **Controllo dei Referrer o Origin Headers**: validare questi header può aiutare a garantire che le richieste provengano da fonti fidate. Tuttavia, un craft accurato degli URL può bypassare controlli mal implementati, come: - - Usare `http://mal.net?orig=http://example.com` (l'URL termina con l'URL trusted) - - Usare `http://example.com.mal.net` (l'URL inizia con l'URL trusted) -- **Modificare i nomi dei parametri**: alterare i nomi dei parametri nelle richieste POST o GET può aiutare a prevenire attacchi automatizzati. -- **CSRF Tokens**: incorporare un CSRF token unico per ogni sessione e richiedere questo token nelle richieste successive può mitigare significativamente il rischio di CSRF. L'efficacia del token può essere aumentata imponendo CORS. +- [**Cross-origin resource sharing**](cors-bypass.md): La policy CORS del sito vittima può influenzare la fattibilità dell'attacco, specialmente se l'attacco richiede la lettura della risposta dal sito vittima. [Learn about CORS bypass](cors-bypass.md). +- **User Verification**: Richiedere la password dell'utente o la risoluzione di un captcha può confermare l'intento dell'utente. +- **Checking Referrer or Origin Headers**: La validazione di questi header può aiutare a garantire che le richieste provengano da fonti fidate. Tuttavia, la creazione attenta di URL può bypassare controlli implementati male, come ad esempio: + - Using `http://mal.net?orig=http://example.com` (l'URL termina con l'URL attendibile) + - Using `http://example.com.mal.net` (l'URL inizia con l'URL attendibile) +- **Modifying Parameter Names**: Modificare i nomi dei parametri nelle richieste POST o GET può aiutare a prevenire attacchi automatizzati. +- **CSRF Tokens**: Integrare un token CSRF unico per ogni sessione e richiedere questo token nelle richieste successive può mitigare significativamente il rischio di CSRF. L'efficacia del token può essere aumentata facendo rispettare CORS. Comprendere e implementare queste difese è cruciale per mantenere la sicurezza e l'integrità delle applicazioni web. -## Bypass delle difese +#### Trappole comuni nelle difese + +- SameSite pitfalls: `SameSite=Lax` permette ancora navigazioni cross-site top-level come link e form GET, quindi molti CSRF basati su GET rimangono possibili. Vedi la matrice dei cookie in [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite). +- Header checks: Valida `Origin` quando presente; se sia `Origin` che `Referer` sono assenti, fallire chiudendo. Non affidarsi a confronti per substring/regex di `Referer` che possono essere bypassati con domini somiglianti o URL appositamente creati, e nota il trucco di soppressione `meta name="referrer" content="never"`. +- Method overrides: Tratta i metodi sovrascritti (`_method` o override headers) come operazioni che modificano lo stato ed applica CSRF sul metodo effettivo, non solo su POST. +- Login flows: Applica protezioni CSRF anche al login; altrimenti, il login CSRF permette la forzatura della ri-autenticazione in account controllati dall'attaccante, che può essere concatenata con stored XSS. + +## Defences Bypass ### From POST to GET (method-conditioned CSRF validation bypass) -Alcune applicazioni applicano la validazione CSRF solo su POST mentre la saltano per altri verbi. Un anti-pattern comune in PHP sembra: +Alcune applicazioni applicano la validazione CSRF solo su POST mentre la saltano per altri verbi. Un anti-pattern comune in PHP appare così: ```php public function csrf_check($fatal = true) { if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF // ... validate __csrf_token here ... } ``` -Se l'endpoint vulnerabile accetta anche parametri da $_REQUEST, puoi rieseguire la stessa action come richiesta GET e omettere completamente il CSRF token. Questo converte un'azione disponibile solo via POST in un'azione GET che riesce senza token. +Se l'endpoint vulnerabile accetta anche parametri da $_REQUEST, puoi rieseguire la stessa azione come richiesta GET e omettere completamente il token CSRF. Questo converte un'azione POST-only in una azione GET che ha successo senza token. -Example: +Esempio: - Original POST with token (intended): @@ -65,48 +72,88 @@ __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}] HTTP/1.1 ``` -Notes: -- Questo schema appare frequentemente insieme a reflected XSS quando le risposte vengono servite come text/html invece che application/json. -- Abbinarlo a XSS riduce notevolmente le barriere di sfruttamento perché puoi consegnare un singolo link GET che innesca il percorso di codice vulnerabile e evita completamente i controlli CSRF. +Note: +- Questo pattern appare frequentemente insieme a reflected XSS quando le risposte sono servite in modo errato come text/html invece di application/json. +- Abbinato a XSS, questo riduce notevolmente le barriere allo sfruttamento perché puoi fornire un unico link GET che attiva il percorso di codice vulnerabile ed evita completamente i controlli CSRF. ### Mancanza del token -Le applicazioni potrebbero implementare un meccanismo per **validare i token** quando sono presenti. Tuttavia, si verifica una vulnerabilità se la validazione viene saltata del tutto quando il token è assente. Gli attaccanti possono sfruttare questo **rimuovendo il parametro** che trasporta il token, non solo il suo valore. Questo permette loro di eludere il processo di validazione e condurre efficacemente un Cross-Site Request Forgery (CSRF) attack. +Le applicazioni potrebbero implementare un meccanismo per **validare i token** quando sono presenti. Tuttavia, si crea una vulnerabilità se la validazione viene del tutto saltata quando il token è assente. Gli attaccanti possono sfruttare questo rimuovendo il **parametro** che trasporta il token, non solo il suo valore. Questo permette loro di eludere il processo di validazione e condurre efficacemente un attacco Cross-Site Request Forgery (CSRF). -### CSRF token is not tied to the user session +Inoltre, alcune implementazioni verificano solo che il parametro esista ma non ne validano il contenuto, quindi un **valore token vuoto è accettato**. In tal caso, basta inviare la richiesta con `csrf=`: +```http +POST /admin/users/role HTTP/2 +Host: example.com +Content-Type: application/x-www-form-urlencoded -Le applicazioni che **non legano i CSRF token alle sessioni utente** rappresentano un significativo **rischio per la sicurezza**. Questi sistemi verificano i token contro un **pool globale** invece di assicurarsi che ogni token sia vincolato alla sessione di origine. +username=guest&role=admin&csrf= +``` +PoC minimale con invio automatico (nasconde la navigazione con history.pushState): +```html + + +
+ + + + +
+ + + +``` +### Il CSRF token non è legato alla sessione utente + +Le applicazioni che **non legano i CSRF token alle sessioni utente** presentano un significativo **rischio per la sicurezza**. Questi sistemi verificano i token rispetto a un **pool globale** invece di assicurare che ogni token sia vincolato alla sessione che l'ha generato. Ecco come gli attaccanti lo sfruttano: -1. **Authenticate** usando il proprio account. -2. **Obtain a valid CSRF token** dal pool globale. -3. **Use this token** in un attacco CSRF contro una vittima. +1. **Autenticarsi** usando il proprio account. +2. **Ottenere un CSRF token valido** dal pool globale. +3. **Usare questo token** in una CSRF attack contro una vittima. Questa vulnerabilità permette agli attaccanti di effettuare richieste non autorizzate per conto della vittima, sfruttando il **meccanismo di validazione dei token inadeguato** dell'applicazione. -### Method bypass +### Bypass del metodo -Se la richiesta sta usando un metodo "**strano**" **method**, verifica se la **funzionalità di override del metodo** è attiva. Ad esempio, se sta **usando un PUT** puoi provare a **usare un POST** e **inviare**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ +Se la richiesta sta usando un metodo "**strano**", verifica se funziona la funzionalità di **method override**. Per esempio, se sta usando un metodo **PUT/DELETE/PATCH** puoi provare a usare un **POST** e inviare un override, es. `https://example.com/my/dear/api/val/num?_method=PUT`. -Questo può funzionare anche inviando il **parametro \_method all'interno di una richiesta POST** o usando gli **headers**: +Questo può funzionare anche inviando il parametro **`_method` nel corpo di un POST** o usando header di override: -- _X-HTTP-Method_ -- _X-HTTP-Method-Override_ -- _X-Method-Override_ +- `X-HTTP-Method` +- `X-HTTP-Method-Override` +- `X-Method-Override` +Comune in framework come **Laravel**, **Symfony**, **Express** e altri. Gli sviluppatori a volte saltano il controllo CSRF sui verbi non-POST assumendo che i browser non possano emetterli; con gli override puoi comunque raggiungere quegli handler via POST. + +Esempio di richiesta e PoC HTML: +```http +POST /users/delete HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded + +username=admin&_method=DELETE +``` + +```html +
+ + + +
+``` ### Custom header token bypass -Se la richiesta aggiunge un **custom header** con un **token** come **metodo di protezione CSRF**, allora: +Se la richiesta aggiunge un **custom header** con un **token** alla richiesta come **metodo di protezione CSRF**, allora: -- Testa la richiesta senza il **Customized Token** e senza l'header. -- Testa la richiesta con un token di **esatta stessa lunghezza ma diverso**. +- Testa la richiesta senza il **Customized Token e anche header.** +- Testa la richiesta con esattamente la **stessa lunghezza ma token diverso**. ### CSRF token is verified by a cookie -Le applicazioni possono implementare la protezione CSRF duplicando il token sia in un cookie che in un parametro della richiesta o impostando un cookie CSRF e verificando se il token inviato al backend corrisponde al cookie. L'applicazione valida le richieste controllando se il token nel parametro della richiesta corrisponde al valore nel cookie. +Le applicazioni possono implementare la protezione CSRF duplicando il token sia in un cookie sia in un parametro di richiesta oppure impostando un CSRF cookie e verificando se il token inviato nel backend corrisponde al cookie. L'applicazione valida le richieste controllando se il token nel parametro di richiesta corrisponde al valore nel cookie. -Tuttavia, questo metodo è vulnerabile agli attacchi CSRF se il sito web ha delle falle che permettono a un attaccante di impostare un cookie CSRF nel browser della vittima, come una vulnerabilità CRLF. L'attaccante può sfruttare ciò caricando un'immagine ingannevole che imposta il cookie, seguita dall'avvio dell'attacco CSRF. +Tuttavia, questo metodo è vulnerabile ad attacchi CSRF se il sito ha falle che permettono a un attacker di impostare un CSRF cookie nel browser della vittima, come una vulnerabilità CRLF. L'attacker può sfruttare questo caricando un'immagine ingannevole che imposti il cookie, seguito dall'avvio dell'attacco CSRF. Di seguito un esempio di come un attacco potrebbe essere strutturato: ```html @@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" /> ``` > [!TIP] -> Nota che se il **csrf token è correlato con il session cookie questo attacco non funzionerà** perché dovrai impostare la sessione della vittima sulla tua e quindi finirai per attaccare te stesso. +> Nota che se il **csrf token è correlato con il session cookie questo attacco non funzionerà** perché dovrai impostare alla vittima la tua sessione e, di conseguenza, ti attaccherai da solo. -### Cambiamento del Content-Type +### Modifica del Content-Type -Secondo [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), per **evitare le preflight** requests usando il metodo **POST**, questi sono i valori Content-Type ammessi: +Secondo [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), per **evitare le richieste preflight** usando il metodo **POST** questi sono i valori di Content-Type consentiti: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** -Tuttavia, nota che la **logica del server può variare** a seconda del **Content-Type** usato, quindi dovresti provare i valori menzionati e altri come **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ +Tuttavia, nota che la **logica del server può variare** a seconda del **Content-Type** utilizzato, quindi dovresti provare i valori menzionati e altri come **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ -Esempio (da [here](https://brycec.me/posts/corctf_2021_challenges)) di inviare dati JSON come text/plain: +Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain: ```html @@ -162,32 +209,32 @@ form.submit() ``` -### Bypassare le richieste preflight per i dati JSON +### Bypassare le richieste preflight per dati JSON -Quando si tenta di inviare dati JSON tramite una richiesta POST, usare `Content-Type: application/json` in un form HTML non è direttamente possibile. Allo stesso modo, utilizzare `XMLHttpRequest` per inviare questo tipo di contenuto avvia una richiesta preflight. Tuttavia, esistono strategie per aggirare potenzialmente questa limitazione e verificare se il server elabora i dati JSON indipendentemente dal Content-Type: +Quando si tenta di inviare dati JSON tramite una richiesta POST, usare `Content-Type: application/json` in un form HTML non è direttamente possibile. Analogamente, utilizzare `XMLHttpRequest` per inviare questo content type avvia una richiesta preflight. Tuttavia, esistono strategie per potenzialmente aggirare questa limitazione e verificare se il server elabora i dati JSON indipendentemente dal Content-Type: -1. **Usare tipi di Content-Type alternativi**: Utilizzare `Content-Type: text/plain` o `Content-Type: application/x-www-form-urlencoded` impostando `enctype="text/plain"` nel form. Questo approccio verifica se il backend utilizza i dati indipendentemente dal Content-Type. -2. **Modificare il Content-Type**: Per evitare una richiesta preflight e al contempo far riconoscere al server il contenuto come JSON, puoi inviare i dati con `Content-Type: text/plain; application/json`. Questo non innesca una richiesta preflight ma potrebbe essere elaborato correttamente dal server se è configurato per accettare `application/json`. -3. **Utilizzo di file SWF/Flash**: Un metodo meno comune ma praticabile consiste nell'usare un file SWF per aggirare tali restrizioni. Per una comprensione approfondita di questa tecnica, fai riferimento a [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). +1. **Use Alternative Content Types**: Impiega `Content-Type: text/plain` o `Content-Type: application/x-www-form-urlencoded` impostando `enctype="text/plain"` nel form. Questo approccio testa se il backend utilizza i dati a prescindere dal Content-Type. +2. **Modify Content Type**: Per evitare una richiesta preflight assicurando però che il server riconosca il contenuto come JSON, puoi inviare i dati con `Content-Type: text/plain; application/json`. Questo non attiva una preflight ma potrebbe essere elaborato correttamente dal server se è configurato per accettare `application/json`. +3. **SWF Flash File Utilization**: Un metodo meno comune ma fattibile consiste nell'usare un file SWF flash per aggirare tali restrizioni. Per una comprensione approfondita di questa tecnica, consulta [questo post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). -### Bypass controllo Referrer / Origin +### Bypass del controllo Referrer / Origin -**Evitare l'header Referrer** +**Evita l'header Referrer** -Le applicazioni possono validare l'header 'Referer' solo quando è presente. Per impedire che il browser invii questo header, può essere utilizzato il seguente meta tag HTML: +Le applicazioni possono validare l'header 'Referer' solo quando è presente. Per impedire a un browser di inviare questo header, il seguente meta tag HTML può essere usato: ```xml ``` Questo assicura che l'header 'Referer' venga omesso, potenzialmente bypassando i controlli di validazione in alcune applicazioni. -**Regexp bypasses** +**Bypass con regexp** {{#ref}} ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -Per impostare il nome di dominio del server nell'URL che il Referrer invierà all'interno dei parametri puoi fare: +Per impostare il nome di dominio del server nell'URL che il Referrer sta per inviare all'interno dei parametri puoi fare: ```html @@ -216,25 +263,60 @@ document.forms[0].submit() ``` -### **Bypass del metodo HEAD** +### **HEAD method bypass** -La prima parte di [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) spiega che [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), un router, è configurato per **handle HEAD requests as GET requests** senza corpo di risposta — una soluzione comune non unica di Oak. Invece di un handler specifico che si occupa delle HEAD reqs, queste vengono semplicemente **passate al GET handler ma l'app rimuove il corpo della risposta**. +La prima parte di [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) spiega che [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), un router è impostato per **handle HEAD requests as GET requests** senza corpo della risposta - una soluzione alternativa comune che non è unica di Oak. Invece di un handler specifico che si occupa delle richieste HEAD, queste vengono semplicemente passate all'handler GET ma l'app rimuove il corpo della risposta. -Quindi, se una GET request è limitata, puoi semplicemente **inviare una HEAD request che verrà processata come una GET request**. +Quindi, se una richiesta GET è limitata, puoi semplicemente **send a HEAD request that will be processed as a GET request**. -## **Esempi di Exploit** +## **Esempi di exploit** +### Stored CSRF via user-generated HTML + +Quando rich-text editors o HTML injection sono consentiti, puoi persistere un fetch passivo che colpisce un endpoint GET vulnerabile. Qualsiasi utente che visualizza il contenuto eseguirà automaticamente la richiesta con i propri cookie. + +- Se l'app utilizza un token CSRF globale che non è legato alla sessione utente, lo stesso token potrebbe funzionare per tutti gli utenti, rendendo lo stored CSRF affidabile tra le vittime. + +Esempio minimo che cambia l'email del visualizzatore quando viene caricato: +```html + +``` +### Login CSRF concatenato con stored XSS + +Login CSRF da solo può avere un impatto basso, ma concatenarlo con uno stored XSS autenticato diventa potente: costringere la vittima ad autenticarsi in un account controllato dall'attaccante; una volta in quel contesto, uno stored XSS in una pagina autenticata viene eseguito e può rubare token, dirottare la sessione o elevare privilegi. + +- Assicurati che l'endpoint di login sia suscettibile a CSRF (nessun token per sessione o verifica dell'Origin) e che non ci siano meccanismi che richiedano interazione utente. +- Dopo il login forzato, naviga automaticamente a una pagina contenente il payload stored XSS dell'attaccante. + +PoC minimale di login-CSRF: +```html + + +
+ + + +
+ + + +``` ### **Esfiltrazione CSRF Token** -Se un **CSRF token** viene usato come **difesa** puoi provare a **esfiltrarlo** sfruttando una vulnerabilità [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) o una vulnerabilità di [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). +Se un **CSRF token** viene usato come **difence** puoi provare a **esfiltrarlo** sfruttando una vulnerabilità [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) o una vulnerabilità [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). -### **GET using HTML tags** +### **GET usando HTML tags** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` -Altri tag HTML5 che possono essere utilizzati per inviare automaticamente una richiesta GET sono: +Altri tag HTML5 che possono essere usati per inviare automaticamente una GET request sono: ```html @@ -263,7 +345,7 @@ background: url("..."); ``` -### Richiesta GET da form +### Richiesta GET tramite form ```html @@ -281,7 +363,7 @@ document.forms[0].submit() ``` -### Richiesta POST del form +### Richiesta POST di un modulo ```html @@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit ``` -### Richiesta Form POST tramite iframe +### Richiesta POST di un form tramite iframe ```html