1

I have recently joined a team working on an application with an integrated chat system. It is a standard chat system that allows clients to communicate, with messages routed through a central server.

Usually when dealing with user-input text, it is recommended to 'escape-on-output' instead of 'escape-on-input'. There are numerous examples (1, 2, 3) as to why this is better, but it basically boils down to: you need to sanitize the text depending on the context in which it is used. If inserting a user chat message into a database, you should escape for SQL and use prepared statements. If display the chat message to a web browser, you should escape for HTML. Etc.

Unfortunately, none of the above security concerns were recognized until recently. (Yes, really).

The quick 'hack' solution was to filter user chat messages when received by the server, and strip out any possibly nefarious-looking character (<,>,",',{,},\, etc). This led to a lot of user complaints, since their punctuation would now magically disappear when displaying in the chat channel.

I want to believe that we can do better than this current 'hack', and allow users to type any text they want in a secure environment.

The problem is that I am working with seemingly impossible constraints. We have numerous versions of the client, spread over many devices, thousands of users, and slow adoption rate of new versions. There's lots of fragmentation, and we can't force clients to update.

Management doesn't care too much about user experience, and has basically told me:

Implement a solution to protect against every possible type of malicious user-input without having to touch the clients. Oh, and also protect against any future 'careless' developer who doesn't know what they are doing and might accidentally try to eval() the user chat message.

(Yes, I was actually told that last part).

Is there any better solution to this problem that would provide a slightly better user experience?

Thanks for reading.

  • Management's requirement can be met by routing all incoming messages to the bit bucket. Not helpful in spirit, but it does meet the letter. – Blrfl Jul 7 '15 at 14:03
2

yes, your manager is right - security flaws don't make themselves, they were all produced by a developer who didn't consider every case. Because software can be complicated, we can all be guilty of this. So you design a system defensively to help prevent us from screwing up. One day some requirement will come in that requires eval, and then..

So, you can strop stripping out any character, and instead just make the input safe for insertion into the DB. This should be simple and easy to verify.

Then you need to change the routines that pull the data out of the DB and sanitise that for the client. If you cannot detect the client application (eg thick client or web) then you'll have to apply a lowest-common denominator to all output, escaping all possibilities.

The important part here is verifying the data, stripping out any character is, as you've found, unhelpful. So determine what the requirements are for making the data safe rather than implementing an overly broad modification. That should be sellable to your boss - you can't tell if its done right if you don't know what right is.

2

It is quite easy to get frustrated with management in these situations but keep in mind that your company only exists to make money. Having a super useful and secure application is not necessarily a worthwhile goal from a manager's point of view.

You have not mentioned in what format the data is pushed to clients but if it is in HTML form then have you considered replacing certain characters with their HTML entity form? Instead of removing them all together. I.e. > becomes &gt; etc. From the client's perspective they will still be able to send and receive non-word characters but without the risk of XSS. This would be my recommendation.

Unfortunately I believe it may be necessary to filter both incoming and outgoing data due to issues such as second order SQL injection whereby data that is not immediately malicious becomes so when it is later retrieved and used in a different context.

It sounds like you may also benefit from educating your manager a little. There is no such thing as 100% secure. A popular approach to thinking about security which I like is that security is not about making your self invulnerable it's about raising the bar to a level where it is no longer worth it for someone to attack you.

Again, it comes back to money. If you can talk to your manager on his level, about how much engineering effort and time (therefore money) it will take to achieve what he is asking then he might cut you some slack. Get him to start thinking about "secure enough" not just "secure".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.