Differenza nella compilazione e nell'esecuzione del linguaggio Web

Qui sembra che ci sia un po 'di confusione, comincerò chiarendo alcune cose.

When I say XSS I simply mean unsanitized and unescaped code being passed to the server.

Questo potrebbe essere ciò che intendi, ma non è quello che chiunque altro intende. XSS è l'iniezione e l'esecuzione di javascript nel browser. Questo javascript iniettato può provenire dal server (memorizzato) o dallo stesso browser (riflesso).

...you could also have a piece of information included in a web page which also contains valid PHP code such as <php phpinfo(); ?>. The server parses over this code and executes it as valid PHP...

No, non è corretto. Ci vuole molto di più che includere PHP in una richiesta HTTP per iniettare il codice sul lato server. Se quello che stavi dicendo fosse vero, sarebbe un disastro per la sicurezza.

Per rispondere alle tue domande:

...at what stage does the code have to be within the page before the browser will treat it as valid code for the language?

Direi che se fa parte di un attacco non verrebbe incluso nella pagina. Se qualcuno sta tentando di attaccare un sito Web, molto probabilmente lo farà dal livello di richiesta HTTP utilizzando un proxy HTTP. Questo va oltre lo scopo di una pagina.

L'inserimento del codice sul server richiede alcune vulnerabilità specifiche nel codice. Dai un questo articolo una lettura per avere un'idea di come accadrebbe in PHP.

Could you have a XSS vulnerability turn into code execution because someone injects PHP code instead and the server parses it?

No - l'iniezione del codice lato server e l'XSS sono due cose completamente diverse. Una vulnerabilità XSS non diventa l'iniezione del codice lato server solo perché fornisci PHP.

Would this be different for something like a stored XSS* vulnerability vs say a reflected XSS vulnerability?

Non capisco davvero cosa stai chiedendo qui, ma la risposta è probabilmente sì. L'iniezione del codice lato server e l'XSS sono totalmente diversi.

Is there any difference between other languages such as aspx / asp with relation to PHP vs something like Javascript?

Di nuovo non sei proprio sicuro di cosa intendi. Ci sono ovviamente differenze tra queste lingue.

Mi concentrerei sull'apprendimento della differenza tra l'XSS e l'iniezione del codice lato server - Penso che una solida conoscenza di questi concetti possa chiarire la confusione.

Buona fortuna!

HTTP è un protocollo stateless, questo significa che le interazioni tra server e client sono brevi e ripetitive.

un client / browser può OTTENERE un documento dal server, se il server ha quel documento in PHP, lo eseguirà e invierà l'HTML risultante al client / browser, quindi non vedrà mai il PHP. Se la pagina HTML risultante contiene un modulo per i dati utente, il client può eseguire il POST di nuovo modulo per l'elaborazione. Questa è la vurnerability di esecuzione di codice / input non pubblicizzata.

XSS è una bestia diversa, se l'HTML che il client ha ricevuto contiene un riferimento, per esempio, a una foto di un gatto divertente che si trova sul sito di qualcun altro, il client lo preleverà felicemente da quell'altro sito. Ora, se l'altro sito fosse abbastanza malvagio da trasformare le sue immagini di gatti divertenti in nefandi script JavaScript (che a differenza di PHP e ASP * non vengono eseguiti sul server ma sul client), allora questi script potrebbero passare dal loro sito originale e esegui il codice come se provenisse dal sito che stavi visitando.

Combinare i due input non adsititi con XSS sarebbe certamente possibile, gli script degli altri siti potrebbero modificare i dati inviati al server e, se il server non lo disinfettasse, potrebbe eseguire quei dati di post! Qualunque sia il server che viene eseguito, viene restituito al client come risposta, che non ha mai nemmeno saputo che stava succedendo.

PHP / ASP rimane sul server e crea pagine Web per il client. Il DOM è generato qui. Il client utilizza il DOM HTML generato, ma può includere JavaScript eseguibile che modifica il DOM. Tutto ciò che viene postato viene gestito nuovamente da PHP.

Il codice interpretato è solo testo, quindi da solo è completamente innocuo. Ha bisogno di un altro programma per riconoscerlo e quindi effettivamente fare qualcosa con esso. Pertanto, se invii il codice a un browser, è innocuo a meno che il browser non lo riconosca.

PHP è un linguaggio specifico che richiede l'esecuzione di un interprete specifico. Senza un interprete PHP, è solo testo. Quindi se il tuo server non ha un interprete PHP installato, il PHP dannoso è solo un innocuo documento in chiaro.

Allo stesso modo, se il codice PHP viene inviato al browser, il browser non può fare nulla con esso. I browser non riconoscono il codice PHP. I browser riconoscono JavaScript e eseguiranno il codice javascript se è incluso correttamente. Ma non possono fare nulla con PHP. Potresti anche aver scritto il tuo codice PHP dannoso in Klingon per tutto il bene che farà.

Il codice ASPX esegue anche il lato server (richiede ASP.NET per l'esecuzione), ma Microsoft, in un tentativo fuorviante di rendere le cose "semplici" offusca un po 'i limiti, consentendo di incorporare runat="server" nei tuoi elementi HTML , che il framework del server acquisisce e esegue alcune trasformazioni aggiuntive prima di inviare i risultati al client. Ma tipicamente c'è un confine luminoso tra codice lato client e codice lato server, e tipicamente (escluso node.js) l'aren lato client e lato server 'anche scritto nella stessa lingua, perché nessuno ^[**] esegue javascript sui loro server.

L'unica cosa che ha una logica sul browser web è javascript. Tutto il resto viene eseguito sul lato server. L'HTML stesso è dichiarativo, quindi non fa nulla in sé, oltre a dichiararsi. Transizioni fantasiose, l'audio è uno sforzo continuo per includere la funzionalità come specifica sul w3c.

Solo a parte, l'esistenza del javascript lato server era già lì prima che il nodo venisse realizzato.