0

So I'm having a website which uses a couple of AJAX requests which fetch data from the DB in an array in PHP, and then generate the markup accordingly needed on the frontend within PHP, then deliver that to the client, and insert it into the DOM using js (simple targetElement.innerHTML = responseFromServer principle).

What I want to do now to be more compatible with non-web interfaces (such as ios and android apps) is adapt these AJAX calls to exclusively output JSON responses. And consequently change the js client-side code to generate the according markup upon reception, with stuff like createElement(), appendChild(), etc. In this case, some people told me that this could be dangerous, in terms of the security of the webapp. I could not understand these reasons; so what are the risks of generating HTML content on the client-side in js, using a JSON response, instead of directly inserting a thus on-the-server-generated-HTML into the DOM?

DevelJoe
  • 856
  • 1
  • 10
  • 24
  • XSS is an obvious one, but that would be the case with server generated code too, if it includes data taken from user input. So html-encode that, as you are hopefully doing in the server side version currently – ADyson Jan 27 '22 at 19:28
  • Could you elaborate on that, maybe with an example? Just that we understand each other, input is sanitized and validated, ALWAYS, before doing anything with it anyway, of course. I just don't understand how outputting html for use in a page has smaller risks than generating it via js upon reception.. – DevelJoe Jan 27 '22 at 21:12
  • You don't need to sanitise _input_, you need to sanitise _output_. You can't sanitise something correctly until you know what it's going to be used for - and therefore what the risks which need to be avoided are. e.g. if someone inputs HTML into your app, there's no point in HTML-encoding it unless you're about to display it in a HTML document where it will be parsed by a browser. If you were outputting the same HTML data to a CSV file (for example) it would be completely harmless in its original form. Sanitising the data up-front when you receive it is akin to corrupting the data, effectively – ADyson Jan 27 '22 at 22:15
  • A simple example of script injection would be if you have a textbox and I write `` in it, and you then output that directly into a HTML file without html-encoding it (after encoding it doesn't look like a script tag to the browser anymore, and therefore the browser doesn't parse it and execute the script). Obviously that particular script is harmless enough, but it could easily contain something much more malicious. https://owasp.org/www-community/attacks/xss/ explains in more detail and better than I can, and there are lots of other articles about it online too – ADyson Jan 27 '22 at 22:18
  • Okay in your example of the ```alert("hello")```, proper input sanitization e.g. by simply stripping all html tags from the input, that would already eliminate the script tags, which you surely never wanna store, no? And mainly, if the responses generated on the server-side NEVER include any of the user input, and exclusively strings hardcoded from the server, why is there still a need of sanitizing the output in that case? I mean, if you know 100% what you're outoutting in the server's response and it doesn't contain any user input...? – DevelJoe Jan 27 '22 at 23:21
  • The functions I'm talking about are ajax requests where you send precise data to the endpoint, like three numbers, a, b and c. Upon input, the server then first validates that the value of a, b and c is an integer for each. If yes, the callbacks then generate html sections which are entirely built on the server-side, and which do not use the provided inout anywhere: what and why do I need to sanitize the output? – DevelJoe Jan 27 '22 at 23:28
  • And to conclude an answer to my question, if I either take care to always sanitize the output OR I can assure that the output is a hard-coded HTML string, written on the server-side, not containing any variable data. In that case, would you still consider it an elevated risk to generate the concerned HTML via js within the client vs on the server-side? If yes, why? :) – DevelJoe Jan 28 '22 at 01:01
  • I mean as long as script tags won't be stored within the DB, and malicious js is only executed in the browser of the attacker and there's no way for the attacker to broadcast it. In that case, is there still a reason to worry?? I mean of course GET parameters are consistently escaped according to their needs. But concerning the explained type of ajax I don't see the elevated risk of genersting the markup on the client-side vs on the server-side. If you could may elaborate on that aspect, being the actual core of my question? – DevelJoe Jan 28 '22 at 01:10
  • 1
    `which you surely never wanna store`...it depends - maybe the data entry is a blog post talking about programming where they want to show a script example, or a dynamic programming environment where _in some circumstances_ the code might be allowed to be executed. Or there could be other reasons. e.g. (off the top of my head) you want to analyse the amount of XSS attempts coming from a particular IP range - can't do that if you've already stripped the interesting data at input time. That's what I mean by context - the data is only dangerous at certain times. – ADyson Jan 28 '22 at 08:55
  • 1
    `if the responses generated on the server-side NEVER include any of the user input`... then no in theory you wouldn't need to sanitise the output. BUT...your server-side program might change in future. And you don't want to have to remember to go and fix lots of stuff in the front-end because you made some little change in the back-end. So it's better to take no chances, and always sanitise for the environment you're outputting into, from the beginning. It's all about following best practice with the purpose of reducing risk, without compromising legitimate data. – ADyson Jan 28 '22 at 08:56
  • 1
    `In that case, is there still a reason to worry`...it assumes you're 100% confident about the rest of the pipleine. That's a big assumption. But if you filter at the end of the tube before it comes out, you can't really go too far wrong. `I don't see the elevated risk of genersting the markup on the client-side vs on the server-side`...correct, because you should have already been sanitising the output when the server was generating it, as per my original point. – ADyson Jan 28 '22 at 08:59
  • 1
    Basically the fact you're doing this via AJAX / JS doesn't particularly change the security risks. It's still a HTTP request, it's still some code generating the output. If the people who told you it's more risky would like to elaborate on what they think the risks are, I would be interested to hear. – ADyson Jan 28 '22 at 09:39
  • 1
    Regarding the filtering input or output thing - see https://stackoverflow.com/questions/3126072/what-are-the-best-php-input-sanitizing-functions, https://stackoverflow.com/questions/129677/how-can-i-sanitize-user-input-with-php, https://security.stackexchange.com/questions/42498/which-is-the-best-way-to-sanitize-user-input-in-php – ADyson Jan 28 '22 at 09:39
  • thx a lot for your answers mate! – DevelJoe Jan 28 '22 at 10:24

0 Answers0