One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
The website responds with some HTML containing some JavaScript along with a script tag. When the browser sees the script tag, it makes another GET request back to the vulnerable site to load the script, sending the auth cookie along.
This makes more sense. I'd always wondered why people were concerned about Javascript exploits. If you have FireBug open, what can't you do with Javascript? It's essentially a completely open source, open data situation. The best security you can use is obfuscation, and that's not really security at all.
Turns out people are getting all upset about stuff that should really never happen in apps I [help] write.
1.) You have to be dealing with sensitive information
2.) The user has to succumb to some social engineering.
3.) You allow cross-site access to json that requires sensitive information to access.
It's that "to access" part that's really the kicker. If you're reading a cookie to produce the JSON, the hole is there, not necessarily in the JSON itself.
So if someone has a cookie to their bank stored on their browser, gets tricked into going to a spoof website (or just hits a website that's spoofing), and you allow cross-site scripting, then and only then are you potentially in trouble.
In a sense, duh. In another sense, "Oh." You'd have to go out of your way to create a problem, but apparently, at least briefly, even Twitter did.
I had never seen this $ref and $id tags before, so I didnโt know how to use them or what to make of it. It turns out that in order to condense the JSON object into a smaller object, it avoids rewriting an object twice if it doesnโt have to. In order to accomplish this, the JSON.NET serializer will serialize these special JSON properties of $id and $ref. Every object being serialized will get an $id. If that same exact object is used again somewhere in the same JSON object, it will use a $ref property to tell you that the particular object youโre looking at has already been serialized. It then gives you the $id to lookup as the value of the $ref property so that you know where to find the object being referred to.
And wow, does this speed up getting info from a database to json. Between the Entity Framework objects and Json.NET, about all you need a programmer for is constructing the LINQ where clause.
If you want to bring Web APIโs behavior more in line with the output of MVCโs Json() helper, you can remove XML support from your API entirely. Just add this to the Application_Start event and youโll never see XML again...
Good riddance. Never have I seen since a bloated, kitchen-sink approach become so unquestionably adopted. Sure, XML does everything you'd ever need, but the times you need more than JSON (what, I've already mentioned, is little more than a home-rolled string format) really are pretty rare.
I know I've mentioned it before, but years ago I remember getting a doc from our resident XML expert promoting its benefits, and search and replaced every occurrence of "XML" with "ASCII" before sending it back to him. The accuracy of the doc really hadn't changed at all, somewhat surprisingly. He took it as the good natured jabbing I intended (XML couldn't be stopped at that point), but I think, for at least that once ;^D, I was ahead of the game.
It's all zeroes and ones. XML doesn't necessarily make something human and machine readable at the same time. It can, but one look at OOXML tells you that this human readability isn't a requirement.
Maybe the lesson is that we underestimated our ability to read like a machine. They are modeled after us (how can they not be? We made them up) to some degree, after all.
I'd been running an ExtJS app that throws params to a .NET WCF server and expected JSON returned. It worked from within the application, but every time I tried with a much more generic request from a test app, it borked with a "communication failure" error. If I sent back null as a return object, it serialized and was processed perfectly. Strange.
I haven't chased this down definitively, but after limiting my results fairly severely (first from an unencumberedly huge number of returns, then to 800, then finally to 80), things started working again.
Invoking web methods from client scripts is fun. But before you roll out your cool applications into the production, please don't forget to reconfigure the max JSON string length, represented by either the maxJsonLength value in the web configuration file or the MaxJsonLength property of the JavaScriptSerializer class.
* Jayrock is open-source, making it possible to extend or customize as needed. ... * ... While ASP.NET AJAX includes some support for creating and parsing JSON text, its primary purpose is to offer a rich platform for building end-to-end Ajax-style web applications in ASP.NET. The extra bells and whistles can be distracting when your main focus is JSON.
That's the kind of attitude I like to see. So much stuff is overkill, like XML for AJAX.
EDIT: Also good -- The comments in json2.js, a reference impl for JSON here.
// Due to a specification blunder in ECMAScript, typeof null is 'object', // so watch out for that case.
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author