Related
Is there a way to 'hide' structure and content of javascript objects?
I have fairly extensive JavaScript objects on my client side holding information about the users UI (and other things). It holds a lot of information about the resources that the user will be operating on. As it is, someone with Firebug can just open the console and see the structure of all that data. I'm not crazy about that for security reasons.
Are there any ways I can protect this data?
Thanks,
No, you cannot protect that data. Anything that can be seen and used by the browser can also be seen and used by a person inspecting what the browser has.
You really need to think about why is this a problem for you? If you're concerned about a man-in-the-middle snoop who might intercept that data, then you should run your connections over https.
If you're concerned about the end-user themselves seeing this data, I'd ask why are you concerned about that? It's the user's own state. There should be no secrets in there.
If you're concerned that the user might manipulate things to do things on your server that they shouldn't be allowed to do, then you need to implement protection on your server for things the user shouldn't be allowed to do. Clients cannot implement such protection because clients are, by definition, not secure in this regard.
If there is actually secure data on the client that the end-user themselves shouldn't have access to, then you need to rethink how your app works and keep that data only on the server. The client should only have data that is absolutely required to be on the client. It's possible to implement a UI with very little actual data in the client except specific fields that are being edited if you generate most of the UI server-side.
So ... in summary. Don't put data in the client that the end-user shouldn't have access to. Rethink how your app works if that's a problem. If the end-user can have access to it, then don't work. If nobody else should have access to it, then run your pages over https.
As for obfuscation, it's barely worth any effort. Obfuscation does not provide any true security as it can always be defeated. At best, it provides a level of annoyance to someone trying to look at your code. A determined hacker will be able to get through the obfuscation by just spending a little more time on it and running it through some tools. Certainly there is no harm in minifying your javascript code as that makes it smaller and makes it less readable by humans, but do not count it as any form of real security.
No, there is not.
However, you have some options:
You can obfuscate your javascript -- this will help slightly as it makes it harder to read and understand your code. There are plenty of good obfuscators out there. I advice against this!
You can minify your javascript -- this might look like an obfuscation method, but is not. It can easily be reverted back to readable javascript and is mainly intended for limiting bandwidth. I encourage this, but advice against it for this reason!
You can try to put as much of your sensitive data and code on your server. This might make sense, or it might not.
You can encrypt your data and decrypt it on-the-fly via your own javascript decryption library. Not a good idea, as it is fairly easy to by-pass this security and it is resource intensive. However it will slightly discourage "theft" of your data. I strongly advice against this!
If you can accept to only target Google Chrome (for now) or Chromium, you can implement your code and data in Native Client, which basically is compiled C code running in a sandbox in your browser (Chromium/Chrome). The only way to get access to your code is decompilation. If you are really paranoid over data theft, you can obfuscate your C code before compiling, to try to kill debuggers from snatching your data, and possibly fetch all your data over SSL from your server in real time rather than having it in your binary.
Though, remember, even with option 5 there are ways to claim your data, though it will be very few who both have the will, time and know-how to get it.
And also remember, if you are looking for a way to conceal sensitive data on the web, it is highly likely you have thought out your solution wrongly. Never ever put sensitive data on the client or use client side verification as your only verification. Perhaps the web is not the platform you are looking for? Perhaps you're looking for a distributed solution?
If it's a security concern, don't send it to the client. Even if you obfuscate it, you're not making it more secure.
Obfuscation can only get you so far, because the nature of Javascript is that it is downloaded to the user's system so that their browser (and user) can read it. Making something harder to read is not hiding it completely. You cannot encrypt it without giving your users some way to decrypt it, thus defeating the purpose. What you're looking for is a server-side language that's compiled before the user sees it, such as PHP, Python, Java, etc.
No, not really. You can obfuscate, pack and do all kinds of stuff to make the source code harder to read. Hell, you can even give your objects really weird and indescript properties. But that's it really, you only make it harder to read. The data is there, and a determined attacker can find out what he wants if sensitive data is sent to the client.
So don't store sensitive data client side. Anyway, what's so horribly secret about UI state? If a user wants to break his state, let him?
I would not suggest to try to obfuscate the javascript logic. But you can minify it (i.e. uglifying it). at least you would make it more difficult to read.
If you are concerned about the security of your client side code, then there is no way but to use server side code. Perhaps making more code available through services and then calling your services through $.ajax or someting similar.
When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!
Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…
No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against
This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.
You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?
Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
Now that JavaScript libraries like jQuery are more popular than ever, .js files are starting to contain more and more of a site's logic. How and where it pulls data/information from, how that info is processed, etc. This isn't necessarily a bad thing, but I'm wondering to what extend this might be a security concern.
Of course the real processing of data still happens in the backend using PHP or some other language, and it is key that you make sure that nothing unwanted happens at that point. But just by looking at the .js of a site (that relies heavily on e.g. jQuery), it'll tell a person maybe more than you, as a developer, would like. Especially since every browser nowadays comes with a fairly extensive web developer environment or add-on. Even for a novice manipulating the DOM isn't that big of a deal anymore. And once you figure out what code there is, and how you might be able to influence it by editing the DOM, the 'fun' starts.
So my main concerns are:
I don't want everyone to be able to look at a .js file and see exactly (or rather: for a large part) how my site, web app or CMS works — what is there, what it does, how it does it, etc.
I'm worried that by 'unveiling' this information, people who are a lot smarter than I am figure out a way to manipulate the DOM in order to influence JavaScript functions they now know the site uses, possibly bypassing backend checks that I implemented (and thus wrongly assuming they were good enough).
I already use different .js files for different parts of e.g. a web app. But there's always stuff that has to be globally available, and sometimes this contains more than I'd like to be public. And since it's all "out there", who's to say they can't find those other files anyway.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
What are your thoughts about this? Am I overreacting? Should I split my JS as much as possible or just spend more time triple checking (backend) scripts and including more checks to prevent harm-doing? Or are there some best-practices to limit the exposure of JavaScripts and all the info they contain?
Nothing in your JavaScript should be a security risk, if you've set things up right. Attempting to access an AJAX endpoint one finds in a JavaScript file should check the user's permissions and fail if they don't have the right ones.
Having someone view your JavaScript is only a security risk if you're doing something broken like having calls to something like /ajax/secret_endpoint_that_requires_no_authentication.php, in which case your issue isn't insecure JavaScript, it's insecure code.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
This is generally minification (to reduce bandwidth usage), not obfuscation. It is easily reversible. There are obfuscation techniques that'll make all variable and function names something useless like "aa", "bb", etc., but they're reversible with enough effort.
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
It's possible to do this, but it's easily worked around by any half-competent attacker. Bottom line: nothing you send a non-privileged user's browser should ever be sensitive data.
Of course you should spend more time checking back-end scripts. You have to approach the security problem as if the attacker is one of the key developers on your site, somebody who knows exactly how everything works. Every single URL in your site that does something to your database has to be protected to make sure that every parameter is within allowed constraints: a user can only change their own data, can only make changes within legal ranges, can only change things in a state that allows changes, etc etc etc. None of that has anything at all to do with what your Javascript looks like or whether or not anyone can read it, and jQuery has nothing at all to do with the problem (unless you've done it all wrong).
Remember: an HTTP request to your site can come from anywhere and be initiated by any piece of software in the universe. You have no control over that, and nothing you do to place restrictions on what clients can load what pages will have any effect on that. Don't bother with "REFERER" checks because the values can be faked. Don't rely on data scrubbing routines in your Javascript because those can be bypassed.
Well, you're right to be thinking about this stuff. It's a non-trivial and much misunderstood area of web application development.
In my opinion, the answer is that yes it can create more security issues, simply because (as you point out) the vectors for attack are increased. Fundamentally not much changes from a traditional (non JS) web application and the same best practises and approaches will server you very well. Eg, watching out for SQL injection, buffer overflows, response splitting, etc... You just have more places you need to watch out for it.
In terms of the scripts themselves, the issues around cross-domain security are probably the most prevalent. Research and learn how to avoid XSS attacks in particular, and also CSRF attacks.
JavaScript obfuscation is not typically carried out for security reasons, and you're right that it can be fairly easily reverse engineered. People do it, partially to protect intellectual property, but mainly to make the code download weight smaller.
I'd recommend Christopher Wells book published by O'Reilly called 'Securing Ajax Applications'.
There is free software that does JavaScript Obfuscation. Although there is not security though obscurity. This does not prevent all attacks against your system. It does make it more difficult, but not impossible for other people to rip off your JavaScript and use it.
There is also the issue of client side trust. By having a lot of logic on the client side the client is given the power to choose what it wants to execute. For instance if you are escaping quote marks in JavaScript to protect against SQL Injection. A Hacker is going to write exploit code to build his own HTTP request bypassing the escaping routines altogether.
TamperData and FireBug are commonly used by hackers to gain a deeper understanding of a Web Application.
JavaScript code alone CAN have vulnerabilities in it. A good example is DOM Based XSS. Although I admit this is not a very common type of XSS.
Here's a book by Billy Hoffman about Ajax security:
http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1266538410&sr=1-1
looking for some general advice and/or thoughts...
i'm creating what i think to be more of a web application then web page, because i intend it to be like a gmail app where you would leave the page open all day long while getting updates "pushed" to the page (for the interested i'm using the comet programming technique). i've never created a web page before that was so rich in ajax and javascript (i am now a huge fan of jquery). because of this, time and time again when i'm implementing a new feature that requires a dynamic change in the UI that the server needs to know about, i am faced with the same question:
1) should i do all the processing on the client in javascript and post back as little as possible via ajax
or
2) should i post a request to the server via ajax, have the server do all the processing and then send back the new html. then on the ajax response i do a simple assignment with the new HTML
i have been inclined to always follow #1. this web app i imagine may get pretty chatty with all the ajax requests. my thought is minimize as much as possible the size of the requests and responses, and rely on the continuously improving javascript engines to do as much of the processing and UI updates as possible. i've discovered with jquery i can do so much on the client side that i wouldn't have been able to do very easily before. my javascript code is actually much bigger and more complex than my serverside code. there are also simple calulcations i need to perform and i've pushed that on the client side, too.
i guess the main question i have is, should we ALWAYS strive for client side processing over server side processing whenever possible? i 've always felt the less the server has to handle the better for scalability/performance. let the power of the client's processor do all the hard work (if possible).
thoughts?
There are several considerations when deciding if new HTML fragments created by an ajax request should be constructed on the server or client side. Some things to consider:
Performance. The work your server has to do is what you should be concerned with. By doing more of the processing on the client side, you reduce the amount of work the server does, and speed things up. If the server can send a small bit of JSON instead of giant HTML fragment, for example, it'd be much more efficient to let the client do it. In situations where it's a small amount of data being sent either way, the difference is probably negligible.
Readability. The disadvantage to generating markup in your JavaScript is that it's much harder to read and maintain the code. Embedding HTML in quoted strings is nasty to look at in a text editor with syntax coloring set to JavaScript and makes for more difficult editing.
Separation of data, presentation, and behavior. Along the lines of readability, having HTML fragments in your JavaScript doesn't make much sense for code organization. HTML templates should handle the markup and JavaScript should be left alone to handle the behavior of your application. The contents of an HTML fragment being inserted into a page is not relevant to your JavaScript code, just the fact that it's being inserted, where, and when.
I tend to lean more toward returning HTML fragments from the server when dealing with ajax responses, for the readability and code organization reasons I mention above. Of course, it all depends on how your application works, how processing intensive the ajax responses are, and how much traffic the app is getting. If the server is having to do significant work in generating these responses and is causing a bottleneck, then it may be more important to push the work to the client and forego other considerations.
I'm currently working on a pretty computationally-heavy application right now and I'm rendering almost all of it on the client-side. I don't know exactly what your application is going to be doing (more details would be great), but I'd say your application could probably do the same. Just make sure all of your security- and database-related code lies on the server-side, because not doing so will open security holes in your application. Here are some general guidelines that I follow:
Don't ever rely on the user having a super-fast browser or computer. Some people are using Internet Explore 7 on old machines, and if it's too slow for them, you're going to lose a lot of potential customers. Test on as many different browsers and machines as possible.
Any time you have some code that could potentially slow down or freeze the browser momentarily, show a feedback mechanism (in most cases a simple "Loading" message will do) to tell the user that something is indeed going on, and the browser didn't just randomly freeze.
Try to load as much as you can during initialization and cache everything. In my application, I'm doing something similar to Gmail: show a loading bar, load up everything that the application will ever need, and then give the user a smooth experience from there on out. Yes, they're going to have to potentially wait a couple seconds for it to load, but after that there should be no problems.
Minimize DOM manipulation. Raw number-crunching JavaScript performance might be "fast enough", but access to the DOM is still slow. Avoid creating and destroying elements; instead simply hide them if you don't need them at the moment.
I recently ran into the same problem and decided to go with browser side processing, everything worked great in FF and IE8 and IE8 in 7 mode, but then... our client, using Internet Explorer 7 ran into problems, the application would freeze up and a script timeout box would appear, I had put too much work into the solution to throw it away so I ended up spending an hour or so optimizing the script and adding setTimeout wherever possible.
My suggestions?
If possible, keep non-critical calculations client side.
To keep data transfers low, use JSON and let the client side sort out the HTML.
Test your script using the lowest common denominator.
If needed use the profiling feature in FireBug. Corollary: use the uncompressed (development) version of jQuery.
I agree with you. Push as much as possible to users, but not too much. If your app slows or even worse crashes their browser you loose.
My advice is to actually test how you application acts when turned on for all day. Check that there are no memory leaks. Check that there isn't a ajax request created every half of second after working with application for a while (timers in JS can be a pain sometime).
Apart from that never perform user input validation with javascript. Always duplicate it on server.
Edit
Use jquery live binding. It will save you a lot of time when rebinding generated content and will make your architecture more clear. Sadly when I was developing with jQuery it wasn't available yet; we used other tools with same effect.
In past I also had a problem when one page part generation using ajax depends on other part generation. Generating first part first and second part second will make your page slower as expected. Plan this in front. Develop a pages so that they already have all content when opened.
Also (regarding simple pages too), keep number of referenced files on one server low. Join javascript and css libraries into one file on server side. Keep images on separate host, better separate hosts (creating just a third level domain will do too). Though this is worth it only on production; it will make development process more difficult.
Of course it depends on the data, but a majority of the time if you can push it client side, do. Make the client do more of the processing and use less bandwidth. (Again this depends on the data, you can get into cases that you have to send more data across to do it client side).
Some stuff like security checks should always be done on the server. If you have a computation that takes a lot of data and produces less data, also put it on the server.
Incidentally, did you know you could run Javascript on the server side, rendering templates and hitting databases? Check out the CommonJS ecosystem.
There could also be cross-browser support issues. If you're using a cross-browser, client-side library (eg JQuery) and it can handle all the processing you need then you can let the library take care of it. Generating cross-browser HTML server-side can be harder (tends to be more manual), depending on the complexity of the markup.
this is possible, but with the heavy intial page load && heavy use of caching. take gmail as an example
On initial page load, it downloads most of the js files it needed to run. And most of all cached.
dont over use of images and graphics.
Load all the data need to show in intial load and along with the subsequent predictable user data. in gmail & latest yahoo mail the inbox is not only populated with the single mail conversation body, It loads first few full email messages in advance at the time of pageload. secret of high resposiveness comes with the cost (gmail asks to load the light version if the bandwidth is low.i bet most of us have experienced ).
follow KISS principle. means keep ur desgin simple.
And never try to render the whole page using javascript in any case, you cannot predict all your endusers using the high config systems or high bandwidth systems.
Its smart to split the workload between your server and client.
If you think in the future you might want to create an API for your application (communicating with iPhone or android apps, letting other sites integrate with yours,) your would have to duplicate a bunch of code for all those devices if you go with a bare-bones server implementation of your application.
Many years back, I was told that Javascript was harmful, and I remember being annoyed with endless popup when I right-clicked an image to download it.
Now it seems suddenly that Javascript is great, and you can do a lot of things with it to let users have native-like web application experience.
I admit I have missed 6-7 years of Javascript literature, so I hope to start anew with SO kickstarting me to understand the following:
Is Javascript mainly concerned about user interface i.e. smoothen interaction between application and users and not about logic processing, number crunching or form processing etc.?
Can Javascript write to local hard drive (besides cookies)?
Can Javascript web application run with Javascript capabilities in browsers turned off? (I would think outright no, but an article on Adaptive Path said 'maybe')
Is AJAX illegal to use due to Eolas patent claim? Is it worth it spending effort learning it when the future is not secure? (I know AJAX is not Javascript)
Thanks. Hoping for enlightenment.
Yes. JavaSscript is usually used to enhance the user's experience and make the site easier to use. It is also possible to delegate validation tasks and the like to JavaScript, however (though this should never absolve the server of its responsibility to check input).
No.
That depends on how the application is written. If it's done properly, then the JavaScript will merely enhance the interface, and the application will still work without it; this is called progressive enhancement.
Not at all. AJAX is used extensively on this very site!
One reason for the resurgence of popularity for JavaScript lately is the emergence of several frameworks. These make the process of writing JavaScript much, much easier, allowing tasks that would previously have been horribly complex to be implemented with minimal time and effort. The most popular of these is jQuery, which is a good place to start if you're intending to get in on the action.
Overall, JavaScript is a very powerful tool that allows you to create very rich interfaces. Well worth learning.
Yes, Javascript is all about client side processing, but also about AJAX where it calls back to the server asynchronously so that users do not see pages reloading.
No
No, but there are ways to gracefully degrade the experience for non javascript users. It requires carefult planning however.
No, that lawsuit was just about the browser technology that enables it. As a developer you dont have to worry about that.
Can Javascript write to local hard drive (besides cookies)?
Not really. However, as HTML5 support becomes more widespread you'll be able to use things like Web Storage and Web SQL. You won't be able to write arbitrary files on the user's hard drive, but using those two technologies you'll be able to persistently store and access data.
Can Javascript web application run
with Javascript capabilities in
browsers turned off? (I would think
outright no, but an article on
Adaptive Path said 'maybe')
It really depends on how you define "web application." You can write web apps without using Javascript for anything but UI candy, in which case you can degrade gracefully without without it. However, it's also possible to write web apps that rely heavily (entirely, even) on Javascript, which will utterly fail without it.
Is AJAX illegal to use due to Eolas
patent claim? Is it worth it spending
effort learning it when the future is
not secure?
I'm not a lawyer, but I'd agree with the other answers -- you shouldn't worry about it. I'm certainly still writing AJAX stuff :)
Is Javascript mainly concerned about
user interface i.e. smoothen
interaction between application and
users and not about logic processing,
number crunching or form processing
etc.?
It's about both. And more than that.
Javascript has really come into its own in the past few years. Browsers have gotten a lot faster at executing it quickly, and people have been figuring out new ways to use the language itself to its full potential. You can really start using Javascript like a full-out application programming language, and not just to write little scripts that animate something or validate input.
If you're just getting back into the language and haven't read Crockford yet, I would highly recommend it. It's a great starting point to realizing the full potential of Javascript.
Edit: Some good Crockford Links
Javascript: The World's Most Misunderstood Programming Language
Javascript: The Good Parts (This is a presentation. Crockford also wrote a book by the same name that I haven't read myself, but I hear it's quite excellent.)
It's mainly for UI, but it can be used to save server-time on some operations (for example, Mathoverflow uses it to render LaTeX) and it's becoming popular to do so. But when you do this, you need to be respectful of the end-users time, because JavaScript can hold up some browsers, while it runs. But in general, it's a good and interesting idea.
Not without permission
If it's written correctly, it can. It's called "Graceful degredation" (some other variant terms exist, but the idea is the same). The basic idea is that you have it such that the JavaScript fails 'gracefully', and links that would normally get handled via JavaScript (i.e. to do some inline next-paging) will navigate to a 'backup' page that shows the relevant content.
I don't know about that, but AJAX can be implemented in different ways, XMLHTTPRequest is just one of them :) (And the most common, and suitable). Generally you like a library do this for you anyway (jQuery, or otherwise) but you can do it yourself for fun.
Yes, in my experience JavaScript is generally used to create a streamlined interface and relays information from the client to a server application for processing.
Yes, if the browser is configured to allow this (most aren't by default since this can be very dangerous).
No, JavaScript will not run if the browser is configured to have JavaScript disabled.
I wouldn't forgo learning JavaScript for this reason - as for the legality of the whole thing I wouldn't feel comfortable advising you about this. Still I think JavaScript is worth learning in spite of this situation.
The Eolas patent covers the embedding of objects in a HTML document (see US patent 5,838,906 titled "Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document") ... this scope would not seem to include AJAX as a suite of technologies (being essentially scripting in a document to load content elements).
Partial answers:
I think all the security vulnerabilities associated with javascript have been fixed? IIRC the problems weren't with javascript, they were with particular browser's implementation of javascript.
I wouldn't worry about any patent claims on the AJAX technology. Patent sueing and counter-sueing is common place in the software world and invariably ends up with the affected parties licencing each other's technology. AJAX is not going anywhere :)