Diferencia en la compilación y ejecución del lenguaje web

Parece que aquí hay un poco de confusión, comenzaré por aclarar algunas cosas.

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

Esto podría ser lo que quieres decir, pero no es lo que nadie más quiere decir. XSS es la inyección y ejecución de javascript en el navegador. Este javascript inyectado puede provenir del servidor (almacenado) o del navegador (reflejado).

...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, eso no es correcto. Se necesita más que solo incluir PHP en una solicitud HTTP para insertar código en el lado del servidor. Si lo que decías fuera verdad, sería un desastre de seguridad.

Para responder a sus preguntas:

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

Yo diría que si es parte de un ataque, no se incluiría en la página en absoluto. Si alguien está intentando atacar un sitio web, lo más probable es que lo haga desde el nivel de solicitud HTTP utilizando un proxy HTTP. Esto está fuera del alcance de una página.

Inyectar código en el servidor requiere algunas vulnerabilidades específicas en el código. Lea este artículo a para obtener una idea de cómo sucedería en PHP.

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

No: la inyección de código del lado del servidor y XSS son dos cosas totalmente diferentes. Una vulnerabilidad XSS no se convierte en inyección de código del lado del servidor solo porque usted proporciona PHP.

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

Realmente no entiendo lo que estás preguntando aquí, pero la respuesta es probablemente sí. La inyección de código del lado del servidor y XSS son totalmente diferentes.

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

De nuevo, no estoy realmente seguro de lo que quieres decir. Obviamente hay diferencias entre estos idiomas.

Me concentraría en aprender la diferencia entre XSS y la inyección de código del lado del servidor. Creo que una comprensión firme de estos conceptos aclarará gran parte de la confusión.

¡La mejor de las suertes!

HTTP es un protocolo sin estado, esto significa que las interacciones entre el servidor y el cliente son breves y repetitivas.

un cliente / navegador puede OBTENER un documento del servidor, si el servidor tiene ese documento en PHP, lo ejecutará y enviará el HTML resultante al cliente / navegador, por lo que nunca podrá ver el PHP. Si la página HTML resultante contiene un formulario para los datos del usuario, el cliente puede enviar el formulario por correo al servidor para su procesamiento. Esta es la funcionalidad de ejecución de código / entrada no saneada.

XSS es una bestia diferente. Si el HTML que obtuvo el cliente contiene una referencia a, por ejemplo, una imagen de gato gracioso que estaba en el sitio de otra persona, entonces el cliente con gusto la buscará en ese otro sitio. Ahora bien, si el otro sitio fue lo suficientemente malo como para cambiar sus divertidas imágenes de gato a scripts de JavaScript infames (que a diferencia de PHP y ASP * no se ejecutan en el servidor sino en el cliente), esos scripts podrían cruzarse desde su sitio original y ejecute el código como si viniera del sitio que estaba visitando.

Ciertamente, sería posible combinar las dos entradas no saneadas con XSS, las secuencias de comandos de los otros sitios podrían cambiar los datos enviados al servidor, y si el servidor no los desinfecta, ¡podría ejecutar los datos publicados! Cualquiera que sea el servidor ejecutado, se devuelve al cliente como respuesta, quien ni siquiera sabía que esto estaba sucediendo.

PHP / ASP permanece en el servidor y crea páginas web para el cliente. El DOM se genera aquí. El cliente utiliza el DOM HTML generado, pero puede incluir JavaScript ejecutable que cambia el DOM. Cualquier cosa publicada de nuevo es manejada por PHP nuevamente.

El código interpretado es solo texto, por lo que es completamente inofensivo. Necesita otro programa para reconocerlo y luego hacer algo con él. Entonces, si envía código a un navegador, es inofensivo a menos que el navegador lo reconozca.

PHP es un lenguaje específico que requiere un intérprete específico para ejecutarse. Sin un intérprete de PHP, es sólo texto. Por lo tanto, si su servidor no tiene un intérprete de PHP instalado, el PHP malintencionado es solo un documento de texto simple inofensivo.

Del mismo modo, si el código PHP se envía al navegador, el navegador no puede hacer nada con él. Los navegadores no reconocen el código PHP. Los navegadores reconocen JavaScript y ejecutarán el código javascript si se incluye adecuadamente. Pero no pueden hacer nada con PHP. También podrías haber escrito tu código PHP malicioso en Klingon por todo lo bueno que hará.

El código ASPX también se ejecuta en el lado del servidor (requiere ASP.NET para ejecutarse), pero Microsoft, en un intento equivocado de hacer que las cosas sean "simples", difumina un poco los límites, lo que le permite incrustar runat="server" en sus elementos HTML , que el marco del servidor captura y realiza una transformación adicional antes de enviar los resultados al cliente. Pero normalmente hay un límite de línea brillante entre el código del lado del cliente y el código del lado del servidor, y normalmente (excluyendo node.js) el lado del cliente y el lado del servidor no son ni siquiera está escrito en el mismo idioma, porque nadie ^[**] ejecuta javascript en sus servidores.

Lo único que tiene lógica en el navegador web es javascript. Todo lo demás se ejecuta en el lado del servidor. El propio HTML es declarativo, por lo que no hace nada en sí mismo, excepto para declararse a sí mismo. Transiciones de lujo, el audio es un esfuerzo continuo para incluir la funcionalidad como una especificación en el w3c.

Dejando de lado, la existencia de javascript del lado del servidor ya existía mucho antes de que surgiera el nodo.