Difference in Web Language Compilation and Execution

Question

I'm trying to get a handle on the difference between certain web languages and the security implications of each. Specifically this is with regards to executing code in the context of the web browser on the server side.

I understand with many injection flaws such as cross site scripting and Javascript you can have improperly sanitized output displayed within the HTML element - which is then interpreted as code instead of it's original intended context (i.e. most likely text). I also appreciate that this is largely because the code processing is taking place on the client machine.

With other languages such as PHP 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, triggering the PHP information display.

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

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

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

Is there such as thing as DOM execution of PHP code?

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

---

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

Answer 1

There seems to be a bit of confusion here, I will start by clarifying a few things.

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

This might be what you mean, but it isn't what anyone else means. XSS is the injection and execution of javascript on the browser. This injected javascript can come from the server (stored) or the browser itself (reflected).

...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, that isn't correct. It takes more than just including PHP in a HTTP request to inject code on the server side. If what you were saying were true, it would be a security disaster.

To answer your questions:

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

I would say that if it is part of an attack it would not be included in the page at all. If someone is trying to attack a website, they will most likely do it from the HTTP request level using an HTTP proxy. This is beyond the scope of a page.

Injecting code on the server requires some specific vulnerabilities in the code. Give this article a read to get an idea of how it would happen in PHP.

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

No - server side code injection and XSS are two totally different things. An XSS vulnerability doesn't become server side code injection just because you provide PHP.

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

I don't really understand what you are asking here, but the answer is probably yes. Server side code injection and XSS are totally different.

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

Again not really sure what you mean. There are obviously differences between these languages.

I would focus on learning the difference between XSS and server side code injection - I think a firm grasp of these concepts will clear up a lot of the confusion.

Best of luck!

Answer 2

HTTP is a stateless protocol, this means that the interactions between server and client are brief and repetative.

a client/browser may GET a document from the server, if the server has that document in PHP, it will execute it and send the resulting HTML to the client/browser, so it never gets to see the PHP. If the resulting HTML page contains a form for user data, the client can POST that form back to the server for processing. This is the unsanitised input/code execution vurnerability.

XSS is a different beast, If the HTML that the client got contains a reference to, say, a funny cat picture that was on someone else's site, then the client will happily fetch it from that other site. Now if the other site was evil enough to change its funny-cat-pictures into nefarious JavaScript scripts (which unlike PHP and ASP* don't execute on the server but on the client), then those scripts could cross from their original site and execute code as if it came from the site you were visiting.

To combine the two, unsanitised input with XSS, would certainly be possible, the scripts from the other sites could change the data POSTed to the server, and if the server doesn't sanitise it, it might execute that post data! Whatever the server executed then is served back to the client as a reply, who never even knew this was going on.

PHP/ASP stays on the server, and builds webpages for the client. The DOM is generated here. The client uses the generated HTML DOM, but it may include executable JavaScript which changes the DOM. Anything posted back is handled by PHP again.

Answer 3

Interpreted code is just text, so on its own it's entirely harmless. It needs another program to recognize it and then actually do something with it. So if you send code to a browser, it's harmless unless the browser recognizes it.

PHP is a specific language that requires a specific interpreter to run. Without a PHP interpreter, it's just text. So if your server doesn't have a PHP interpreter installed, malicious PHP is just a harmless plaintext document.

Similarly, if the PHP code gets sent to the browser, the browser can't do anything with it. Browsers don't recognize PHP code. Browsers recognize JavaScript, and will run javascript code if it's appropriately included. But they can't do anything with PHP. You might as well have written your malicious PHP code in Klingon for all the good it will do.

ASPX code also runs server-side (it requires ASP.NET to run), but Microsoft, in a misguided attempt to make things "simple" blurs the boundaries a bit, allowing you to embed runat="server" into your HTML elements, which the server framework catches and does some additional transformation on before sending the results to the client. But typically there's a bright-line boundary between client-side code and server-side code, and typically (excluding node.js) the client-side and server-side aren't even written in the same language, because nobody^[**] runs javascript on their servers.

Answer 4

The only thing that has logic on the web browser is javascript. Everything else runs on the server side. HTML itself is declarative, so it does not do anything in itself, other than to declare itself. Fancy transitions, audio is an ongoing effort to include functionality as a spec at the w3c.

Just an aside, the existence of server side javascript was already there way before node came about.