Sono consapevole che le richieste HTTP GET vengono inviate al server Web utilizzando la coppia nome / valore stringa di query nell'URL. Ciò significa che si è in grado di passare dati personalizzati al server web. Ad esempio http://some_site.com.br/some-page.asp?name=custom_data .
Ci sono altri tipi di richieste HTTP che vengono inviate in questo modo nell'URL? Per quanto ne so, per esempio le richieste HTTP POST hanno dati personalizzati nel payload.
Come afferma @Philipp, qualsiasi URI può avere una stringa di query, indipendentemente dal metodo HTTP (GET, POST, PUT, ...) con cui viene usato.
Le RFC in generale non discutono esplicitamente le stringhe di query, anche quando discutiamo di metodi come GET dove ci aspettiamo di vederli. Una menzione esplicita rara è in RFC 2068 :
some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part)
Potresti voler seguire i link da RFC 7237 , che elenca un numero di metodi HTTP non tradizionali, per vedere se qualcuno descrive esplicitamente la loro gestione dei parametri della stringa di query; Ne ho controllati alcuni e non ho trovato alcuna discussione esplicita.
Ora, tutto ciò detto, ci sono un paio di problemi di sicurezza che si legano a questa imprecisione.
Uso inappropriato
Ci sono momenti in cui i parametri della stringa di query non sono appropriati, ad esempio, prendi in considerazione RFC 2616 :
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead.
Questo è buono ... ma le stringhe di query sono non proibite sulle richieste POST, semplicemente non attese . A quanto pare, alcuni server Web (Tomcat, ad esempio, e programmi PHP che utilizzano $_REQUEST ) prenderà tranquillamente tutti i parametri su un POST, sia che si trovino nella stringa della query o nel corpo, e li rendano accessibili all'applicazione come parametri di input. Ho visto un caso in cui una forma POST funzionava abbastanza agevolmente alimentando parametri di stringa di query per mesi prima che qualcuno si rendesse conto che ciò stava accadendo (e che le informazioni sensibili venivano registrate che non dovrebbero).
Cache-busting
Una cosa che alcune applicazioni faranno è aggiungi una stringa di query fasulla alle richieste per assicurarti che ottengano contenuti nuovi e non memorizzati nella cache . Poiché il server di solito ignora le stringhe di query che non si aspettano, questo di solito può essere fatto tranquillamente dall'applicazione client.
L'eccezione si verifica quando controlli stretti sono in atto, come un firewall di applicazioni Web, che considerano le stringhe di query sconosciute o impreviste come segni di una scansione o di un attacco dannoso. Se il WAF sa che /foo/bar non dovrebbe avere parametri di stringa di query, e una richiesta arriva per /foo/bar?_fresh=20150819 , il WAF potrebbe bloccare quella richiesta.
In breve, la scioltezza che consente le stringhe di query in luoghi e gli URI non previsti significa che il rafforzamento dei controlli di sicurezza può bloccare la funzionalità come effetto collaterale.
Ambiguità generale
Questo è in realtà un superset degli altri problemi, ma la mancanza di regole ben definite su quando una stringa di query può o non può essere usata significa che vengono introdotti problemi di sicurezza. Poiché ogni server può scegliere di gestire le stringhe di query in posizioni strane in modo diverso, il professionista della sicurezza non può predire il modello di minaccia senza test per vedere come funzionano le cose nella loro configurazione - e anche allora tale test è solitamente incompleto (ad esempio, è difficile pensare di ogni cosa pazzesca che un utente malintenzionato potrebbe fare con le stringhe di query). Se ci fossero regole rigide e veloci ("le stringhe di query non sono permesse sulle richieste POST") sarebbe più semplice.
Le famose linee guida di Jon Postel per i protocolli Internet:
Be liberal in what you accept, and conservative in what you send
Va bene per l'interoperabilità, ma è dannoso per la sicurezza. Più un sistema liberale cerca di accettare gli input, maggiore è la probabilità che vengano introdotti problemi di sicurezza. E nel caso di stringhe di query in metodi HTTP, le RFC finiscono per lasciare ambiguità che richiede interpretazioni di sistema molto liberali.
Secondo RFC 3986 - Identificatore di risorse uniformi gli componente di query è consentito per qualsiasi URI indipendentemente dal protocollo utilizzato. Ciò significa che non è consentito solo per qualsiasi metodo HTTP (quello che chiami "tipo di richiesta"), ma anche per qualsiasi altro protocollo che utilizza URI, come ad esempio ftp.
Leggi altre domande sui tag http web-application