I’m developing a ticketing system for a local hosting company and one of the requirements is that users be able to submit tickets with actual html in it. This would be a valid input.
<html>
<head>
<script>alert('hello!');</script>
</head>
</html>
This input could be placed into the system via an online submission or an email coming into the system.
Furthermore, one of the business requirements is that those viewing the tickets be able to see the html version as html, so rendering it to the browser in some fashion is a business requirement.
Now, I understand that there is absolutely no way for me to be able to protect this system. I’ve done a lot to protect it in the places where I’m able to do so, but this particular security hole is just not fixable given the current business requirements.
I cannot even conceivably whitelist these things because the user could be describing an html page with script tags embedded in it, a web.config file, an XML file, an odf file, you name it, they probably have a user who has sent an example of it in.
I am unaccustomed to writing software that has requirements that are so ‘open’, and I’m unsure how best to approach this. My current thinking is risk management rather than risk prevention, I see no other way to effectively limit malicious input in this scenario. but, if anyone has any suggestions for how I can do some sort of prevention with the current requirements, I’m all ears. Since I’m sure someone will bring it up, let me also say I’ve had a frank conversation with the owner of the company I’m contracting with, and the requirements will not be changing anytime soon 🙂
I would like to get input from people who have dealt with this scenario and what advice you can give based upon that experience. I’m not really interested in theory, but practice. Part of my goal is to put a solid proposal in front of the owner and see what we can do to compromise on the whole security vs convenience tradeoff.
Also keep in mind that this system will eventually be sold to their customers, which means there are many assumptions I simply cannot make. Currently the system is built fairly specific for them, but as time moves on, many of the assumptions we have in place will eventually be removed or generalized.
My first thought is some sort of risk assessment of incoming emails, if an email trips a threshold, certain restrictions are automatically put in place. Things like an inability to view the html version in the browser, opening it in a text editor instead of the browser, that sort of thing. My concern is that this may be a pain for the users, and any workaround I put in place (‘approving emails’) would be used without any actual thought put into it, making this worthless.
I’ve also considered ‘trusted zones’, by which I mean, tickets from new email addresses have restrictions put on them until X number of tickets from that address, restrictions are always put in place for tickets/emails created via the web interface, that sort of thing. In many ways this suffers from the same things as the other solution.
Another solution is to let it be. This is obviously the easiest solution, and it may be a valid one, but I would require a very strong argument before I would accept it.
I’m not above pulling out an HTML parser and looking over the emails myself for specific things, but I do not believe there is any automated way of protecting this system without getting false positives, which the owner has made clear is completely unacceptable. Which I understand, who wants to email support only to never hear from them?
Any advice or insights from those that have tackled this problem in the past would be greatly appreciated. The specific technology I’m using is ASP.Net 4.5/IIS
For me, the first answer is the obvious one: Don’t do that. Don’t let them submit arbitrary HTML/JS and then render it to authenticated clients. I can’t exactly imagine a scenario where that would be necessary.
The second most obvious answer follows Guffa’s: If you do render it, then the plan would be to render it in an environment where it can’t make use of any authenticated-ness, to steal cookies or redirect to authenticated actions and what-not. I.e. the page that does the rendering is not authenticated and requires no cookies to view (or similar approach). However, it will still be possible to them to arbitrarily write malicious JavaScript which could – all on it’s own – do Bad Things. For example, you could take any input they have, render it as a pure .HTML file that the viewer has to open locally in their browser (i.e. not hosted); this is still bad.
So in general, this is a pretty bad idea, and I wouldn’t do it. The typical way out is to force any submission of data to be very well structured (as on, say, this forum), such that you can deal with specific bits in an appropriate way. This is probably want they want anyway – i.e. they just don’t want to restrict input; but maybe you should just have a seperate area for certain types of input (Code samples, what-not).
So in summary: avoid this; you can make your situation slightly better in some ways, but it’s still going to basically be bad.