I have a security-related question with regards to d3.js

D3.js essentially allows data to drive dynamic charts etc, among other features.

The "d3js.org" landing page mentions "D3 (js) allows you to bind arbitrary data to a DOM".

Functions such as d3.csv.parse can be used to read in "arbitrary" data. However, the chart in question would be expecting certain types of data etc.

Can such a library truly accept "arbitrary" data from anonymous users? Could a user potentially parse carefully crafted data to produce an unexpected result with D3? (ie, authorized JS execution).

What may be best practise here for wanting to parse arbitrary to D3?

  • Thanks for the response Jimmy. Sorry, you misunderstood me. The Javascript would execute client-side yes. I understand that a technically-inclined could start up the Chrome JS console and start entering arbitrary JS commands. I am not concerned with that. I am referring to the data, not the JS. Many JS libraries out there (ie D3.js) take data, which then in-turn drives some charts. What happens if you allow users to create any data they wish.. which in-turn is then fed to the JS? Could crafted data somehow cause the JS code to generate undesired results? – user88567 Oct 6 '15 at 23:17
  • Giving the user the ability to input arbitrary data would not make sense. While this is possible, d3.js would simply not be able to display meaningful diagrams or just throw an exception. There would not be any security problem if d3.js runs on the client side. – John Oct 7 '15 at 17:27

EDIT: I can't comment on the question since I got locked out of my old account and don't have enough reputation... All the below applies to data too. Nothing on the client side is under your control. I'm confused as to why you wouldn't be worried about arbitrary code but only arbitrary data. Generally speaking, the ability to modify code provides more power to produce "unexpected" results than the ability to modify data. Maybe you should explain exactly what you are worried about. Can you clarify what you mean by "authorized JS execution"?

If I understand your question I think you are asking whether a user can change your client-side javascript arbitrarily i.e. to change it however they please. The answer is a resounding yes. Have a look at Greasemonkey, for example. In general, anything that is executing on the client is in their control. There have been many attempts to create client-side systems that prevent this kind of thing but they really only work if the client opts to use them. Any technically sophisticated user will be able to disable these options.

You should never put any sort of sensitive logic on the client-side. All input coming from the client should be considered potentially malformed or otherwise manipulated for nefarious reasons.

There was a case decade or so back where a retail website took the price of an item as an input from the client's POST. A user saw this and submitted a price of $0.01 and ordered a bunch of items. The website duly executed the order as submitted. It went to court and the case was ruled against the website. That is, it wasn't even illegal.

| improve this answer | |

What happens if you allow users to create any data they wish.. which in-turn is then fed to the JS? Could crafted data somehow cause the JS code to generate undesired results?

This all boils down to how much you trust the library. That is, trusting that it is not doing anything malicious, and trusting that there are no exploitable bugs that would allow the above.

If you are downloading the source code, you can inspect it to ensure that it has a low chance of being the former. The latter is harder to detect, although unlikely unless there is use of eval or similar somewhere (there are quite a few ways of executing arbitrary code, even if eval is not used).

If you are linking to the library on their site using <script src="... then you are trusting that they do not update the library with a malicious version, or that their site is not compromised and that an attacker does not replace the library with a malicious version.

All in all it should be a low risk, especially if you host the library yourself and code review it before minifying yourself if necessary.

| improve this answer | |

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.