I've read a lot about sanitizing and escaping of untrusted data, e.g. starting with this cheat sheet. But I didnt get the full picture yet. I am struggeling to understand, what principles I have to follow in order to parse JSON data safely.
Let's be more precise by means of an example. I retreive an Object in JSON format via an Ajax call from my server. The object shoudnt contain any malicious code, but.... you never now. So I parse the JSON data using JSON.parse in JS. The sesult is a multilevel JS object. I use the object in various way, e.g. creating table code via JS and writing it in the DOM.
Is this approach safe. Or do I have to somehow escape the invidual items of the object individually? Appreciate your help. Happy to concrete my example if necessary.
Related
According to this Angular 2 guide:
Don't expect the decoded JSON to be the heroes array directly. This server always wraps JSON results in an object with a data property. You have to unwrap it to get the heroes. This is conventional web API behavior, driven by security concerns.
('Heroes' is an array of objects).
The link in the above paragraph says :
Always return JSON with an Object on the outside
Always have the outside primitive be an object for JSON strings:
Exploitable:
[{"object": "inside an array"}]
Not exploitable:
{"object": "not inside an array"}
Also not exploitable:
{"result": [{"object": "inside an array"}]}
My Question is: Why shouldn't the server return something like a JSON array?
Say :
[
"apples"
,"oranges"
, "peaches"
]
How is this a security concern ?
To avoid JSON Hijacking:
The fact that this is a JSON array is important. It turns out that a script that contains a JSON array is a valid JavaScript script and can thus be executed. A script that just contains a JSON object is not a valid JavaScript file.
For example, if you had a JavaScript file that contained the following JSON: {“Id”:1, “Balance”:3.14} And you had a script tag that referenced that file:
<script src="http://example.com/SomeJson"></script>
You would get a JavaScript error in your HTML page. However, through an unfortunate coincidence, if you have a script tag that references a file only containing a JSON array, that would be considered valid JavaScript and the array gets executed.
So allowing JSON to be returned as anything but an object would make it possible to return a JSON array that contained code that could be run on the client level (in a context where the client isn't expecting it to be runnable, could be malicious, etc). Only returning JSON objects prevents this from happening.
This was rather bad advice that has since been removed from the angular tutorial.
The linked OWASP Cheet Sheet lists three ways to defend against JSON Hijacking. The one the tutorial picked is the hardest to implement correctly, because one must educate every single developer, and audit every single REST resource, rather than writing a single HttpInterceptor to extend CSRF-defenses to GET requests.
JSON hijacking can only occur due to browser bugs, which tend to be fixed quickly (this does not imply such attacks are impossible, but the easy exploits no longer work in modern browsers)
I'm looking for most elegant way of "dumping" simple JavaScript object into JavaScript source-code generated on-fly.
Purpose:
Assume we have node.js server generating HTML. We have an object x on server side. The object is simple - only strings/ints/arrays in it (so, it's JSON-able). I want to "embed" object x into HTML being generated, to be available for JavaScript code which will run on the browser. So the code:
console.log(x);
will dump exactly the same data on both server-side and browser-side.
For example - imagine I'm going to pass some additional config/data to JavaScript running on browser.
Obvious solutions:
Encoding as JSON and send as AJAX/Websocket is not a part of this question as we have to embed the object in the HTML. I don't want additional HTTP requests - everything should be passed in one go.
Encoding as JSON and simply attach to variable sounds initially good, but involves some additional escaping steps.
Using util.inspect() works for me, in this way:
var toHtml = 'var x = ' + util.inspect(theXonServer, {depth:9}) + ';';
but I'm not sure if it's "elegant" (and secure and error-prone and...)
Any better suggestions ? Standard way of doing that ?
The Wrong Way to Pass Data
It's common to get advice to just stringify some JSON and dump it into a <script> tag. This is bad advice. Don't do it.
It's important to understand why this is a bad idea.
When you string-build JavaScript, you're opening yourself up to all sorts of quirks of the language that you'd absolutely be required to understand to make sure that there are no issues.
One such quirk is that within a <script> element, the first occurrence of </script> will close the <script> element. It doesn't matter that it's in a string, the script will be closed, and the rest of the contents after that point will be treated as HTML.
HTML escaping doesn't work because JS doesn't like HTML entities.
what might start as:
<script>
window.xss = <%= JSON HERE %>
</script>
could turn into:
<script>
window.xss = {"username":"Robert Hackerman</script><script src='nefarious.js'></script>"}
</script>
Don't risk it.
The Right Way to Pass Data...
...When the Page is Rendering
The much safer way that prevents any script execution is via [data-*] attributes. You must HTML-escape the contents, but that's OK in attributes. I'm using a <script> element because it's implied that the script will be using the data.
What would start as:
<script data-foo="<%= HTML ENCODED JSON HERE %>" src="yourscript.js"></script>
Would turn into:
<script data-foo="{"username":"Robert Hackerman</script><script src='nefarious.js'></script>"}" src="yourscript.js"></script>
And if you want access to that data, you can just access the attribute value, or use the dataset api (if your target browsers support it):
var fooElement = document.querySelector('[data-foo]');
var rawData = fooElement.dataset.foo;
// or
var rawData = fooElement.getAttribute('data-foo');
var data = JSON.parse(rawData);
console.log(data);
...After the Page has Rendered
If the page has already loaded, and you want to access some data, just use an AJAX request. You'll be able to safely read in a JSON data source, which can be piped through JSON.parse to access the data object.
Util.inspect vs JSON.stringify
You only need util.inspect if your object is circular. If it's JSON encodable in 99.9% of cases you can just output it to the source with JSON.stringify.
Using JSON
There are edge cases to this - not only are JS objects more expressive than JSON (functions etc), JSON objects can do things JS objects can't (in edge cases of encoding). So make sure not only is your object serializable correctly, it's also deserializable correctly. I also assume you didn't do anything crazy like override the array constructor (which would make JS objects behave differently from JSON ones).
Security
As for security, unless your object can contain sensitive data (and it really shouldn't, whitelist it first) there should not be any related issues.
Overall option 2 is a standard approach that is quite commonly used - including on this very site.
It usually works for simple data which is most data you need to share (numbers and strings).
It saves the round trip.
It's used very often in big sites and in practice.
I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page ( I'm basically trying to display invoices on a web browser)
My skill set is HTML/CSS and I understand a little JavaScript
I've managed to pull XML data into HTML using http request and style that information using xslt
Really what I'm asking is what is the best solution to my needs is it using the above method then using xquiry to add up values or would I need to learn a bit of Ajax, Json and calculate the values with JavaScript?
You really should learn AJAX in order to fetch and manipulate data instead of fetching presentation parts. That's the way everyone follows as it allows more responsive interactions with the user and a cleaner architecture in case of complex interactions.
But that doesn't mean you must abandon XML : originally AJAX was built on XML (the X in AJAX) and not JSON.
Personally I prefer JSON, and I think it will be easier to manage in the long term, but if the server side is hard to change, you can fetch the XML (look for example at jquery's ajax function), build javascript objects using it, and then change your screen using those data. If later you decide to use JSON instead of XML, you'll just have to change the "parsing" part of the client code.
"I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page"
You can do this with either XSLT or javascript. However, with XSLT things can become pretty complicated, depending on what version you're using. XSLT 1.0 has pretty limited set of functions for aggregating results. For all XSLT, you can't reassign variables you'll have to solve many of these things with recursion. In my opinion, not really a comfortable method.
Regardless of the choice between XSLT and Javascript, I would also question the architecture that would put this kind of logic in the presentation layer in the browser. I think it would be better if the server side would perform all the calculations that are required, and limit the browser's tasks to styling the output.
New to JSON, just trying to get my feet wet.
I know how to do this with XML via javascript, but am trying to learn how to handle JSON objects so I can switch over.
Basically I want to search through all "permalink" tags in the following JSON object and, when I find the right one, save its corresponding "title" and "id" tags to javascript variables:
http://api.soundcloud.com/users/goldenstatewarriors/tracks.json?client_id=02db8e29aa2fb5bf590f478b73137c67
Can this be done with only javascript (no PHP)? The main issue I'm facing is simply grabbing the text from the page and converting it to a json object.
You need to use a JSON parser in order to transform the JSON string into an object you can handle natively in JavaScript. Recent browsers have this functionality built in as JSON.parse(), but obviously this will not work in older browsers (we're talking very old browsers here).
A solution to that problem is to use the JSON parsing library available here. If native browser support is detected, it simply uses that, otherwise it has a JavaScript implementation to achieve the same result. The file you'll need is json2.js - simply include that as you would any other library and away you go!
An example of the code would be:
var dataObject = JSON.parse(jsonData);
As a side note, XMLHttpRequest is somewhat of a misnomer these days. It is simply a mechanism for making HTTP requests and retrieving the data returned, it doesn't have to be XML. It can be plain text, (non X)HTML, JSON, anything. In fact, I don't think I've seen anything in the wild return actual XML data for an XMLHttpRequest in a very long time.
I can do it via jQuery and/or Underscore JS as arrays of data, but I want to learn the API for just pure RAW JSON. For example, I know there is:
delete json.item
Which just simply deletes the item, but is there a set place I can go learn the full API?
--UPDATE--
I guess this came out wrong. I want to learn about Douglas Crockfords library, all of it. The JSON.func() library, not just "JSON" which is a string. For example he has a function called stringify etc. His site is a total mess, so I was wondering if there was a better place to learn about that JSON library (which has become the standard.)
There is no such thing. Raw JSON is a string, and attempting to manipulate it will only serve to damage it. Always manipulate it after decoding it.
delete will modify the property of an object, it won't let you manipulate JSON (unless that JSON is stored as the property of an object, in which case it will delete it entirely).
You appear to be asking about how to modify a JavaScript object, in which case, the "API" can be found at https://developer.mozilla.org/en/JavaScript/Reference