Render: $.fn.dataTable.render.text() Presentation

pybcg

Link to test case:
Debugger code (debug.datatables.net):
Error messages shown:
Description of problem: I understand that $.fn.dataTable.render.text() is helpful in mitigating XSS attacks by escaping dangerous characters, but it's not a pretty representation of the data. Apostrophes and ampersands are being escaped and substituted with numbers/special characters and that's not exactly the best alternative either. For example, Pedro's becomes Pedro's. Is there a way to still render as Pedro's while making sure we're avoiding XSS attacks?

allan

I’m going to guess that you are using Editor with our .NET libraries (I might already know that from a previous discussion - apologies if I’ve forgotten).

Editor’s .NET libraries have anti-XSS built in, and will slightly encode the data when writing it to the database. As such you don’t need to use the text renderer since doing so would double encode the HTML entities, which I think is what you are describing.

The best option is to disable the XSS on the server-side (new Field(“...”).Xss(false)) and then use the text renderer on the client-side. That isn’t the default mainly for historical reasons - DataTables hasn’t ever escaped HTML without a renderer, so when Editor came along later, that was the fail safe way of doing it to help protect folk without requiring extra configuration.

Allan

pybcg

I’m going to guess that you are using Editor with our .NET libraries (I might already know that from a previous discussion - apologies if I’ve forgotten). We are actually not using the .NET libraries but have a Python backend so we're building protection from scratch. For the most part, we're not too concerned with XSS since our inputs are all integers, but we want to come prepared in the event that we begin to have text inputs.

Editor’s .NET libraries have anti-XSS built in, and will slightly encode the data when writing it to the database. As such you don’t need to use the text renderer since doing so would double encode the HTML entities, which I think is what you are describing.

The best option is to disable the XSS on the server-side (new Field(“...”).Xss(false)) and then use the text renderer on the client-side. That isn’t the default mainly for historical reasons - DataTables hasn’t ever escaped HTML without a renderer, so when Editor came along later, that was the fail safe way of doing it to help protect folk without requiring extra configuration. Question about this - is this a response based on the assumption that we're using the .NET libraries? Otherwise, my follow up question would be why the best option is to disable the XSS on the server-side and enable the text-renderer.

1. Now that you're aware we're building from scratch on the server side, do you have a suggestion on how to get mitigate XSS risk? Going back to your comment about .NET libraries having anti-xss built in, I'm wondering how the data looks after the library "slightly encodes the data"? Are you saying that for .NET libraries, when you save something like Pedro's, it will save as something slightly different, but still render itself as Pedro's without using the text renderer?

allan

Question about this - is this a response based on the assumption that we're using the .NET libraries?

Yes, completely.

If you are using Python, then perhaps there is a layer in your framework that is doing the entity encoding? The way to check for sure would be to:

1. Make an edit in the browser
2. Check that it was submitted to the server without encoded entities (using the browser' network inspector)
3. Check the value in the database - using an SQL browser tool.

If the two don't match then there is something doing XSS prevention already. What that is.. I've no idea I'm afraid .

Now that you're aware we're building from scratch on the server side, do you have a suggestion on how to get mitigate XSS risk?

The best way is to use the text renderer. That means that the data on your database doesn't get modifier from what the user has submitted. You just need to be sure you escape the data whenever you display it (never trust user data!).

Allan