Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Experts Say Ajax Not Inherently Insecure

Zonk posted more than 7 years ago | from the good-to-know dept.

Security 82

An anonymous reader writes "Jeremiah Grossman (CTO of WhiteHat Security) has published Myth-Busting - an article dismissing the hyped-up claims that AJAX is insecure. He says: 'The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true ... Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.'"

cancel ×

82 comments

Sorry! There are no comments related to the filter you selected.

Now I can tell my mother (-1, Offtopic)

mrkitty (584915) | more than 7 years ago | (#17069328)

First post!

Re:Now I can tell my mother (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17069462)

it was harder to get firsty back when slashdot didn't suck total cock

MERRY CHRISTMAS (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17069442)

I LOVE YOU!!!!!!!!!!!

Carrie, the Christmas Angel

Strawman (2, Interesting)

markov_chain (202465) | more than 7 years ago | (#17069448)

Way to make up an issue and then show off attacking it.

Vulnerability in practice is just as bad or worse (5, Insightful)

ScentCone (795499) | more than 7 years ago | (#17069464)

When something is this widely adopted and this tempting to rapidly trot out (because PHBs are desparate for that shiny stuff as they head to the next board meeting), the fact that you're suddenly introducing a wildly more complex set of GETs and POSTs and layered hoo-hah on an interactive page (never mind the purpose of the app) means that all of the stuff that always introduces vulnerabilities will be there, multiplied by the new complexity. And, of course, with a smaller crowd of talented, experienced people truly able to quickly size up the risks as something goes live.

It's not the (non-existent?) inherent security problems in the bundle of techniques we're referring to, it's the weaknesses that show up in the practice of shoddy implementation, cheezy hosting platforms, etc. There's nothing wrong with AJAX, it's the AJAX-envy among less sophisticated operators that we have to worry about. We just have to quit saying it's 'easy' to implement, because none of the underlying bits and pieces are (in terms of being bullet-proof) are 'easy,' and a browser-agnostic soup of a couple dozen of those bits is that many times harder.

Re:Vulnerability in practice is just as bad or wor (1)

oni (41625) | more than 7 years ago | (#17070464)

it's the weaknesses that show up in the practice of shoddy implementation

Right, that's what I was about to say. The only vulnerability I've seen that I would say was AJAX-specific was that someone put security on the main page, but on none of the little ajax widgets. It just didn't occur to this person that securing the widgets was necessary - probably because what we're used to when programming on the web is a main page (that is secure) and libraries that can only be called on the server side.

Someone who has more experience with web services wouldn't have made that mistake.

So anyway, like you said, the problem is shoddy implementation.

Enabling Javascript AT ALL is the main risk (1)

billstewart (78916) | more than 7 years ago | (#17074998)

The big risk with AJAX isn't that it introduces new vulnerabilities that Javascript doesn't have, or that good Javascript writers can't write good safe Javascript. The big risk is that evil Javascript writers can write harmful Javascript, and good AJAX web pages dangle something shiny in front of the user that makes them turn Javascript on at all, so when they also view the evildoers' web pages, they're running the harmful Javascript.


It is of course possible for well-intentioned Javascript or AJAX writers to write insecure code, which can be attacked either by the end user or possibly by cross-site scripting attacks, and the author of the article offers some good advice about how to prevent and manage those risks. IMHO, it's really really nice to hear somebody today offering up the same basic advice I learned when I first took programming in college 30 years ago, which is to never ever trust input from users. Any kind of scripting that runs in the browser offers more opportunities for a programmer to trust the end users - for instance, one of Javascript's big uses has always been to validate input fields in forms before submitting them to the web server, and while that can often help users who accidentally put incorrect types of information in forms, or forget to fill out fields you want, it's no protection against a malicious user trying to send malformed data to your application. AJAX gives you some more tools for trusting users (:-), as well as more tools to validate input from users because of the structure imposed by XML. And of course it's also possible for malicious users to abuse old-fashioned simple web forms, especially if the programmer isn't careful about validating form contents for safety before handing them to any applications.


Most of the popular browsers give the user some granularity in managing what kinds of scripting you'll accept from what sites, so in theory it's not as dangerous as just turning on the big red kick-me switch like on earlier browsers (or Netscape 2, which didn't even give you a choice.) But in practice the tools aren't that friendly, and the vast majority of users aren't going to use them successfully.

Time to kill another myth (1)

SkiifGeek (702936) | more than 7 years ago | (#17077354)

Yes, JavaScript is an evil, evil thing in the hands of the malcontent, but having scripting support deactivated in your browser isn't really going to stop much. Some of the most recent work being carried out by Jeremiah Grossman and others who like to dabble in the area has shown that it is possible to enumerate systems on internal LANs via the browser of a visitor to an external website that the attacker controls.

Without Scripting enabled.

While the developed technique is still quite noisy and fairly obvious, there has been some work at making it more efficient. But, if you add enough shiny elsewhere on the page, then history has shown that people will be happy to put up with almost anything to get at the shiny.

Outside of the LAN, and with scripting support disabled, it is trivial to develop a network scanner that hits every port of every IP on the network segment that a site visitor is coming from, and which triggers only when the site is visited by the victim.

The bigger threat to AJAX in recent months has been the widely published (amongst security researchers) issues affecting the core AJAX components for Internet Explorer and Firefox. IE had threats affecting the XMLHTPPRequest ActiveX object (sort of core to the whole AJAX experience) as well as other threats targeting different scripting support, while Firefox had a number of issues affecting JavaScript support. Most of these issues had public exploit code and actively circulating exploits (though only in small numbers). Had something been developed which was aggressive in attacking these flaws, Web 2.0 could rapidly have become Web 0.2 for many users. Before you claim that trusted sites should be safe, the WMF vulnerabilities from last December / January showed that once an adhost gets compromised, it is game over for many many many sites that should otherwise be trusted.

Re:Time to kill another myth (0)

Anonymous Coward | more than 7 years ago | (#17079958)

> having scripting support deactivated in your browser isn't really going to stop much.

Bollocks. As a home user I have 2 desktops and a gateway, you can do all the timing based attacks you want but the only open ports on my 10.128.255.0/30 are SSH. What's an attacker going to do using HTML in an iframe?

Likewise the only way to use this attack to exploit a known vulnerability on an internal facing corporate web app is via HTTP GET. That's assuming that you can access web apps by IP because best practice is to configure vhosts and internal DNS. That might leave a few network printers vulnerable on the local VLAN but there should be nothing else that you can harm via HTTP GET.

Javascript is a much more serious risk.

> Outside of the LAN, and with scripting support disabled, it is trivial to develop a network scanner
> that hits every port of every IP on the network segment that a site visitor is coming from, and
> which triggers only when the site is visited by the victim.

In other words, anybody can portscan any public address range? Poorly worded, misleading and irrelevant to the issue of web browser security.

Best security practices (1)

Tackhead (54550) | more than 7 years ago | (#17069492)

From TFA: "What can I do to protect myself as a user?"

> One of the best ways to protect yourself is to turn off Javascript in your browser settings.

The more things change, the more things stay the same.

Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.

Re:Best security practices (2, Interesting)

nine-times (778537) | more than 7 years ago | (#17069636)

Is javascript really that horrible? I know it can be used in annoying ways, how difficult is it to do something outside of superficial changes to the browser?

I'm really asking. It seems like you should be able to have a simple scripting language that can only really manipulate superficial aspects of web pages without any real increase to the security risk. I thought this was what javascript was. Am I wrong? If so, why doesn't someone replace javascript with something better.

Re:Best security practices (1)

Shados (741919) | more than 7 years ago | (#17069950)

No, its not. Or at least, its not supposed to be. Its just that most browser vulnerabilities come from errors in Javascript. Assuming a "perfect" browser, Javascript is safe. Of course, no browser is perfect, but the odds of getting owned while using, let say, Opera, are pretty god darn low.

That being said, the NET without javascript is one damn boring beast. The only interaction you can then have with your page are links and submit buttons. Might as well read a book.

Re:Best security practices (1)

cswiger2005 (905744) | more than 7 years ago | (#17076088)

I like books. They don't come with flashing banner ads, pop-up windows, pop-under ads, and all the rest of the active content that pollutes a lot of the WWW nowadays. Of course, if you don't install Flash, disable animated images, Javascript, and so forth, the web becomes a lot less annoying and more legible.

As for YouTube, or anything else that requires Flash or something to work, well, I live without.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17069990)

The problem isn't javascript, the problem is automatically running aritrary script over a public network. From a security perspective that's what is commonly called "asking for it".

Re:Best security practices (1, Insightful)

hotdiggitydawg (881316) | more than 7 years ago | (#17070066)

Is javascript really that horrible?

Yes.

I know it can be used in annoying ways, how difficult is it to do something outside of superficial changes to the browser?
A computer is practically worthless to most people if you cannot use it to browse the internet nowadays. So, forget about things outside the browser, and start thinking about user-website interaction through the browser. You can rely on so many trivial vectors to build an effective attack to manipulate a user's browsing experience, and in the case of most sheeple they'll be none the wiser. And the proliferation of it with the latest AJAX fad simply means more people are likely to have it on globally by default rather than have a degraded browsing experience.... as well as more sites with forms and other input vectors for XSS and other attacks too.

It seems like you should be able to have a simple scripting language that can only really manipulate superficial aspects of web pages without any real increase to the security risk. I thought this was what javascript was. Am I wrong?
Largely, you're correct. But it's scope of manipulation is such that it can be effectively used to dupe gullible and/or less tech-savvy users into doing something foolish... It's an effective tool in the right hands, in as much as a hand-grenade is. Give it to someone who has no idea how it functions, with a "Pull Me" tag on the ring-pull, and the consequences will eventually be dire... even if it's not the fault of the grenade itself.

Re:Best security practices (1)

nine-times (778537) | more than 7 years ago | (#17070452)

But it's scope of manipulation is such that it can be effectively used to dupe gullible and/or less tech-savvy users into doing something foolish...

What kind of "something foolish"? I'm just wondering, what are the limits to these sorts of things? Phishing?

I always try to train people to distrust the internet, but you can't keep people from being stupid. Can javascript be used to open software firewall ports, or establish some kind of tunneling? Can it execute arbitrary code on the client machine? Can it give someone remote access to access/change files on your hard drive? Can it allow someone to look at my browser cache, read my bookmarks or history, or copy my passwords?

I don't know, but it seems like some common sense is in order. Some sort of scripting seems necessary for decent web apps. We should assume that users generally have javascript enabled anyway, because it's enabled by default when you download any major browser. If there is any one feature of javascript that allows for easy security exploits and doesn't have a real practical use, then let's petition to have it dropped from major browsers.

Otherwise, it seems like you can't say users should run with javascript disabled. It's not going to happen. We should be able to get rid of ActiveX and even possibly Flash, but to believe you'll be able to regress the web to being pure HTML is just unrealistic.

Re:Best security practices (1)

Phrogman (80473) | more than 7 years ago | (#17070884)

One example I just read about somewhere (possibly on /. not sure) is the use of Javascript and frames to capture username/password information for Phishers. So instead of making a false webpage and linking to it, they make a set of invisible frames that display the real website and say your bank account login page - then use JS to pull the values from those fields when you enter your data. I haven't looked into whether or not this is possible mind you, just read someone commenting that it was en vogue at the moment.

I am currently building a AJAX-ish application as a hobby (basically an SVG based napoleonic combat simulator that we can use to fight napoleonic battles in a Napoleonic Campaign management program a friend is working on). I am constantly considering how it could be fucked up by someone with a will to do so and trying to build in checks to ensure that everything the client does can be validated on the server end before I do anything with it. I imagine it will take several passes and many improvements to try to harden this up to ensure we maintain some level of security.

Personally, I think its time for another environment to be specced out, something that replaces both ActiveX (which I would never use) and Javascript (which I reluctantly use) that permits client side activity in an environment that is specifically designed to avoid insecurities (built in form validation functions etc). I haven't looked into XUL yet and that might help me in many ways. Thats a future project :)

Re:Best security practices (1)

nine-times (778537) | more than 7 years ago | (#17071990)

I'm not sure about ActiveX. Do we need a replacement, or do we just need to get rid of it?

But web applications and interactive/animated web pages are too useful and popular to expect they'll just go away. If the current mixture of PHP, HTML, CSS, Javascript, and XML is too inefficient and insecure, then by all means, I'd like to encourage people to come up with something better. I'd assume it's a bit harder than it sounds, though.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17073724)

"One example I just read about somewhere (possibly on /. not sure) is the use of Javascript and frames to capture username/password information for Phishers. So instead of making a false webpage and linking to it, they make a set of invisible frames that display the real website and say your bank account login page - then use JS to pull the values from those fields when you enter your data. I haven't looked into whether or not this is possible mind you, just read someone commenting that it was en vogue at the moment." Won't work on browsers with sensible security. Even IE probably wouldn't let it happen. You can't usually access anything within an iframe, frame etc that is on a different domain using javascript. Even different subdomains usually doesn't work.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17070992)

I always try to train people to distrust the internet, but you can't keep people from being stupid. Can javascript be used to open software firewall ports, or establish some kind of tunneling?


Exactly. HTML5 even goes so far as to propose TCPConnection().


Can it execute arbitrary code on the client machine?

Javascript automatically retrieved and run from a web server is arbitrary code! Generally it can't do anything outside the JS sandbox without exploiting a security vuln in the browser. If you think that sounds reassuring, remember that javascript is used to bootstrap nearly every web nasty; spam zombies could be virtually eliminated if the world disabled javascript.



Can it give someone remote access to access/change files on your hard drive? Can it allow someone to look at my browser cache, read my bookmarks or history, or copy my passwords?

Generally not without exploiting a browser flaw or XSS hole... in other words, yes! Just go through and tally the percentage of browser vulns that would not exist if JS were disabled.


to believe you'll be able to regress the web to being pure HTML is just unrealistic.


Sites should function without script for accessibility and only the bad guys would stand to lose from a more realistic approach to security by browser vendors.

Re:Best security practices (3, Insightful)

nine-times (778537) | more than 7 years ago | (#17071532)

Sites should function without script for accessibility and only the bad guys would stand to lose from a more realistic approach to security by browser vendors.

When you can write a new version of Google's spreadsheet program that uses only HTML and CSS, I'll go along with the idea that we should get rid of javascript.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17072078)

When you can write a new version of Google's spreadsheet program that uses only HTML and CSS,

Poor example, most script (popups, postbacks) is not (should not be) necessary for a site to function. Googles spreadsheet is a traditional desktop application as webpage. A firefox extension (in XUL & javascript - heh) could replace that web app without requiring you run script from public web servers.


I'll go along with the idea that we should get rid of javascript.

I've been working in javascript all day. The problem isn't the language, the problem is running remote scripts.

Re:Best security practices (1)

nine-times (778537) | more than 7 years ago | (#17072378)

Sure, I'm not saying there aren't problems with javascript. I'm saying you can't expect to get rid of it without offering an alternative. Personally, I'm not sure I see a valid justification for javascript being able to make pop-ups or resize windows and such. If there are security problems, they should be addressed.

But Google's spreadsheet program is a terrific example, in that people want web applications. It can be extremely useful to have an application that feels like a desktop application, but can be run over the internet without extra installations or application-specific add-ons. I don't think you can get rid of javascript until you have some means to have Google's spreadsheet, word processor, and webmail run on a remote system without prior setup.

On the other hand, I could see an argument that these should be done in a separate program from the traditional "web browser". I'm not sure I agree, but I've seen the argument that we should really have RSS readers, some sort of a generalized web application client, and a "web browser" that only views static HTML and CSS. I can see the argument, but I suspect that if this were done, you would find that users just wanted to stay in their "web application client" anyway, and have a web browser and rss reader in that client. In that case, this "web application client" would end up being essentially the same as web browsers we have today.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17072754)

So the argument comes down to web application deployment?

Entire industries are built on the javascript cross domain problem, not just web stats companies but major advertisers as well. Let's not pretend that any technical problems would be difficult to solve.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17072392)

A firefox extension (in XUL & javascript - heh) could replace that web app without requiring you run script from public web servers.

While at the same time requiring you to use a slow, bloated set of tools that's tied to one browser (family).

Brilliant solution.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17072594)

Fine then, just a zip of all the files to download and run locally, still allowing you to upload your data to Googles servers.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17072616)

Javascript automatically retrieved and run from a web server is arbitrary code!

Not really..it is code; but not exactly the same thing in this context. "Arbitrary" javascript code does not interact directly with the underlying OS, so it's not really as if someone is running arbitrary code on your machine from a buffer exploit.

If you think that sounds reassuring, remember that javascript is used to bootstrap nearly every web nasty; spam zombies could be virtually eliminated if the world disabled javascript.

Replace "disabled javascript" with "using IE" and you've got it right. In the context of zombie infections, I believe most attack vectors use ActiveX which has nothing to do with JavaScript the language. It's the browser's fault for having holes in it's ActiveX, DOM and JS engines, not the language, or the use of the language.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17073240)


Not really..it is code; but not exactly the same thing in this context. "Arbitrary" javascript code does not interact directly with the underlying OS, so it's not really as if someone is running arbitrary code on your machine from a buffer exploit.


How do you know that a 3rd party server isn't compromised or configured to serve malicious script once from every thousand requests? Of course remote script is arbitrary code. [google.com] And how can you be sure that an arbitrary script isn't written to execute shellcode via a browser vuln? Ad servers have been compromised in the past, this isn't some paranoid delusion.



n the context of zombie infections, I believe most attack vectors use ActiveX which has nothing to do with JavaScript the language.

Most I've seen use JS to install the activeX control but I don't run Windows so my exposure is minimal. You're absolutely correct when you say it's not the language, in this context we're talking about all remote code (javascript, ActiveX, Applets).

Re:Best security practices (1)

timmarhy (659436) | more than 7 years ago | (#17074718)

yes java script is that horrible. it's slow and prone to bugs. populate a 100x 100 grid of information in JS then do it in a native exe and see the difference, you'll be horrified at how shit JS is.

Re:Best security practices (1)

niteice (793961) | more than 7 years ago | (#17094008)

Perhaps you were testing on SpiderMonkey (Gecko's engine)? SM specifically is known to be a very slow JS engine.

Re:Best security practices (1)

Watts Martin (3616) | more than 7 years ago | (#17074948)

Is javascript really that horrible?

Yes.

While I understand your objection to it -- which is essentially the most common objection to Javascript -- let me rephrase it, albeit in a deliberately provocative manner: "any tool to make the web-browsing experience more advanced than an IBM mainframe terminal can be exploited, and therefore should not be used."

There obviously are dangers to client-side scripting, and our current solutions could arguably handle them better. But are we really going to tell people to disable everything that could possibly execute in their browser because any such thing represents a security hole? Why, we could all be even more secure if we all used Lynx (graphics libraries have had exploitable bugs in them, after all), or better yet went back to Gopher. But somehow I'm betting that would be a tough sell.

For all of the buzzwordiness of Ajax and the inevitable abuse that goes with it, it really does provide usability benefits in terms of responsiveness and immediate user feedback. And while it may be easy to say, "Well, I object to Javascript itself, not the concept," I'm not convinced that any useful scripting language for client-side interaction isn't going to have the same potential for abuse. (And as a language, Javascript is not that horrible. It's got more than its fair share of warts, but it's a functional language [wikipedia.org] , with closures and higher-order functions and a lot of general goodnesss people don't usually appreciate.)

On Slashdot in particular (but around diehard computer nerds in general), I've run into what I've dubbed the "engineer's mindset" that regards all advances past HTML 2 as unnecessary frills. But from not only a design but a usability standpoint, "Web 2.0" is not just about bling -- it's about making web applications work better. As Martha Stewart would say when she's not in prison: that's a good thing. And I don't think we really do web users nearly as much of a service as we imagine we are when we tell them, "No Google Maps for you."

Re:Best security practices (4, Funny)

Ingolfke (515826) | more than 7 years ago | (#17069732)

Downloading the HTML via WGET and reading it VI is the only secure way to surf the net.

Re:Best security practices (0)

Anonymous Coward | more than 7 years ago | (#17070334)

only if you have modelines turned off. (look up vim modeline vulnerabilities)

Re:Best security practices (1)

slashbob22 (918040) | more than 7 years ago | (#17070476)

Downloading the HTML via WGET and reading it VI is the only secure way to surf the net.
More or Less ?

Re:Best security practices (1)

Duckz (147715) | more than 7 years ago | (#17110046)

Less can do so much more than more.

Re:Best security practices (2, Insightful)

owlnation (858981) | more than 7 years ago | (#17070710)

Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.
Of course that is true. It's just that it's a real pain in the ass. Well, no mortal being requires ActiveX for any reason, and I block the horror that is Flash with the (truly joyous and wonderful) Flashblock extension - and rarely ever allow it to run, mostly just for YouTube.

It's the Javascrpt that's the pain really. I tried using the noscript extension for a while, but it was actually more of an inconvenience than the risk of running something malicious. Seems that a very high number of webpages - and the most improbable ones too - use javascript and are dysfunctional if you disallow it. I'm not sure how to win with this - a little risk for a higher quality of web browsing? It's what I do, but not what I want.

Re:Best security practices (1)

LifesABeach (234436) | more than 7 years ago | (#17075560)

I do not get it about the security problems of AJAX. I just do not see the problem. I have yet to see an example where using the following senario is a security problem;

1. user gets default web page, like "index.html" that is a combination of HTML/SVG/CSS.
2. user reads web page.
3. user fills out form.
4. user 'submits' form to a web service, (for me, web services are like console programs, but output is to a web browser).
5. web service edits input.
6. web service creates XML with a XSLT preprocessor statement for the users browser as a response.
7. user browser, ( Firefox, Safari, Opera, or IE ), translates the XML/XSLT input automatically into a HTML/SVG/CSS output
8. [ go to step 2. /]

I don't use ActiveX, COM objects, or Flash. I do use Javascript embedded in the resulting HTML/SVG/CSS page for client side edits, (only). The only time my products touch the DOM is for client editing. The client never gets involved with third party close source executable objects this way.

Yeah... (0, Offtopic)

eno2001 (527078) | more than 7 years ago | (#17069494)

...and in the movie Mars Attacks! the Martians kept telling the U.S. government they weren't going to invade. Hmmm.. Maybe THAT'S where the Bush administration got their inspiration from for the premptive strike. Certainly would explain a lot...

Re:Yeah... (0)

Anonymous Coward | more than 7 years ago | (#17074838)

Doc Ruby, is that you on another account? Jeebus, we were talking about AJAX and javascript and security, and all of a sudden it's Bush and Martians!

AJAX isn't inherently insecure but scripting IS (0)

Anonymous Coward | more than 7 years ago | (#17069498)

It's irresponsible for a security professional to claim otherwise.

Existing Best Practices (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17069532)

Yup, existing best practices takes care of all of the security issues for AJAX: disable Javascript. Problem solved.

With open-source, you can examine the source before you run the program, and can take steps to ensure that the program you run is compiled from the source you examined and that it's unchanged since the last time you ran the program. There's no good way to do the same thing with Javascript ... you're expected to nod agreeably when the website says "just trust us".

"Not trusting someone who /demands/ that you trust them without evidence" should be the #1 best practice out there.

Re:Existing Best Practices (1)

Ingolfke (515826) | more than 7 years ago | (#17069664)

You're either a troll or an idiot who chooses to speak about things he knows nothing about.

JavaScript is open plain old text. You're free to review the code for every website you visit before running it.

Re:Existing Best Practices (0)

Anonymous Coward | more than 7 years ago | (#17074880)

You're either a troll or an idiot who chooses to speak about things he knows nothing about.

JavaScript is open plain old text. You're free to review the code for every website you visit before running it.


No, You're either a troll or an idiot who chooses to speak about things he knows nothing about.

If the javascript runs either in the window_onload event, or as part of the page...then you CAN'T review the code before running it...unless you do exactly what the GP post suggests: disable javascript

Re:Existing Best Practices (0)

Anonymous Coward | more than 7 years ago | (#17069816)

Yeah but browsers could be better about this.

  1. Allow disabling of eval() on AJAX responses
  2. Only allow event handlers in html. Event handlers can call a single function, all other inline script is disabled
  3. Allow Javascript to be audited on first run
  4. Inform user when a cached script changes serverside and allow them to re-audit


WhatWG should have tackled this before making HTML5 so dependant on JS.

Re:Existing Best Practices (1)

xnebox (823727) | more than 7 years ago | (#17070544)

Write a firefox plugin.. only techies would care anyway.

Re:Existing Best Practices (0)

Anonymous Coward | more than 7 years ago | (#17071178)

Sadly 2 needs to be more than a plugin, webmasters need to move all their scripts to external files. Until then a custom proxy could be the way to go.

Where the heck did this hype come from? (3, Insightful)

Anonymous Coward | more than 7 years ago | (#17069556)

And who is honestly saying these things? Am I alone in not seeing the percieved risks here?

All AJAX really gives you is that first 'A': asynchronous. All the other underlying mechanics of client-to-server communications over HTTP apply. This means that your security checklist is absolutely no different than using a good old-fashioned [form].

To slam AJAX as insecure as a technology is just bad thinking to begin with - it's a tool, that's all. Whether or not it's used in a secure fashion is really more a best-practice and/or training issue.

Besides, didn't we already go over all this when Web-Services were a big deal?

Re:Where the heck did this hype come from? (0)

Anonymous Coward | more than 7 years ago | (#17071958)

The main problem with AJAX is that you can't turn off JavaScript (and all client side scripting) anymore. You took something horrible but optional and made it mandatory, and for that I'll hate you forever. "Good old-fashioned" forms don't have any of the problems with client side scripting. That takes care of 90% of your security checklist.

Re:Where the heck did this hype come from? (1)

ghostdancer (72944) | more than 7 years ago | (#17077394)

Get NoScript, https://addons.mozilla.org/firefox/722/ [mozilla.org]

Extra protection for your Firefox: NoScript allows JavaScript, Java and other executable content only for trusted domains of your choice, e.g. your home-banking web site.
This whitelist based preemptive blocking approach prevents exploitation of security vulnerabilities (known and even unknown!) with no loss of functionality...
Experts do agree: Firefox is really safer with NoScript ;-)

Re:Where the heck did this hype come from? (1)

chefjoeardee (1001809) | more than 7 years ago | (#17072774)

Well, think of this. It wouldn't be all that hard to setup some javascript, use AJAX and have it call to http://192.168.1.1/ [192.168.1.1] and try a random smattering of common admin logins to modems (I know my DSL modem @ home supports it) and then report back to the server the IP address of the user. You could easily get their PPPoE login right there provided some other details. At the very least you could take down their modem.

Sure this is kinda out there and the simple response is to change your modems password or turn off web administration on it but then again a quick wireless scan around my apartment reveals at least two people with open systems.

Not everyone is an IT tech and there will always be a market for the exploitation of insecurities just as there will always be insecurities. It's merely a matter of being preemptive, recognizing potential risks and doing what you can to both (a) lower risk to an acceptable level and (b) maintain usability depending on how important access to similar sites is for you/company.

Re:Where the heck did this hype come from? (1)

chefjoeardee (1001809) | more than 7 years ago | (#17073018)

Hah, well after posting this I decided to check out exactly how feasible it is. FF (2.0) w/Firebug will tell me that Firefox denied access to the call. I assume it sees any calls that start out with http:/// [http] that doesn't match the server and automatically denies it.

IE 6.0 on the other hand merely says "This page is accessing information that is not under its control" and gives you a Yes/No choice.

Re:Where the heck did this hype come from? (1)

chefjoeardee (1001809) | more than 7 years ago | (#17073112)

Gah. I hate to keep posting things repeatedly but my thinking is fragmented today :)

I don't think it's similar to a FORM at all, you can get the user to access other sites that they wouldn't normally access and get a parseable response from that site (as I mentioned above). I plan on testing this out some more with a friend of mine to see if I can grab their modems information remotely.

If you're using AJAX in a legitimate fashion (eg, requesting information from the original server) then yeah, it is as simple as a FORM request (maybe some session verification with PHP) but this manner I just outlined completely defeats that.

That article was a mixed bag (3, Interesting)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#17069606)

There's some justice in saying that Ajax doesn't introduce any new problems over and above Javascript, but that is faint praise and doesn't allow for the fact that buzzword-compliant organizations are now creating more web sites that require Javascript.

His advice about keeping web apps secure is sound and practical but incomplete. The last OWASP conference I went to, one of the speakers pointed out that there's an Ajax development toolkit out there in which you can't tell a priori whether a piece of functionality you program will end up on the client or on the server. "Avoid toolkits like that" should be on the list of security precautions.

>AJAX is a web browser (client-side) technology. It does not execute on the server.

The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?

Re:That article was a mixed bag (1)

tcopeland (32225) | more than 7 years ago | (#17069760)

> The XMLHttpRequest certainly does execute on the server

Hm... does it? Wouldn't that require a Javascript interpreter in the web server?

Re:That article was a mixed bag (1)

grcumb (781340) | more than 7 years ago | (#17073478)

> The XMLHttpRequest certainly does execute on the server
Hm... does it? Wouldn't that require a Javascript interpreter in the web server?

I doubt it. I suspect that it just needs an XML parser to read data from an HTTP Request.

Re:That article was a mixed bag (2, Informative)

PacoSuarez (530275) | more than 7 years ago | (#17069954)

The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?
The XMLHttpRequest looks to the server just like any other HTTP request, with parameters passed the exact same way as you would pass them to a CGI program. The only side that needs to parse a bunch of XML is the client, which is not much of a security problem.

Re:That article was a mixed bag (1)

DuckWizard (744428) | more than 7 years ago | (#17072304)

Well, judging from the fact that the default Content-Type for the request sent by an XMLHttpRequest is "text/xml", you're not quite correct. The default usage is to send an XML-encoded request in raw postdata which would be parsed by the server. You can override this and send urlencoded data (like your browser does when you submit a form), but you have to explicitly specify that this is what you're doing.

So it seems that it was intended for bidirectional XML-based communication.

Re:That article was a mixed bag (0)

Anonymous Coward | more than 7 years ago | (#17072942)

Well judging by the fact that you can change the content-type, it would seem that you're a pedantic asshole who makes useless posts.

Re:That article was a mixed bag (2, Insightful)

leighklotz (192300) | more than 7 years ago | (#17071158)

>Which would you rather validate, a set of CGI parameters or a blob of XML?
Um, a blob of XML. Quoting and escape characters are a big source of vulnerabilities. XML has well-defined quoting rules. CGI parameters have no structure, so structure must be done ad hoc. XML structure can be validated on the server using XML Schema or Relax, or other mechanisms.

Fortran in Haskell (3, Interesting)

Fahrenheit 450 (765492) | more than 7 years ago | (#17069712)

This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.

Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.

What are you guys talking about? (0)

Anonymous Coward | more than 7 years ago | (#17069998)

AJAX is just a convenient method for sending and retrieving data from the server without a full page refresh.

As long as the sever side still requires proper authentication for the AJAX requests as they would for any other web request, it is no less secure than a normal web site.

Client side, AJAX is just as secure as javascript. It can move things around and report about anything happening on the web page back to the server hosting the web page. If you are doing things on the website that you don't want reported back to the sever (completing a form but not submitting it), don't use the web site.

The security problem comes in when people design sites that trust communication between the client side of the application and the server side of the application. Anything can be modified client side, including the javascript of the ajax application. Always pass an opaque timeoutable token that identifies the user for all requests and check the permissions before doing anything and you are about as secure as a web application can be. Even if they hack the application to send requests that your application won't let them, the sever should limit the harm to only things that user should be able to do anyway.

Yeah - (1)

SageinaRage (966293) | more than 7 years ago | (#17070562)

It's your fault, jackass!

Definition of an Expert (0)

Anonymous Coward | more than 7 years ago | (#17070720)

Personally, I think Jeremiah Grossman is a wanker; this nonsense will come back to haunt him. But that's his rep, and not mine. Anyway, here's the definition of an expert.

"X" is an unknown quantity.
"spurt" is a drip of water under pressure.

Thus, an "expert" is an unknown drip under pressure.

Did someone say Mythbusting? (0)

Anonymous Coward | more than 7 years ago | (#17071180)

Where are the pics of Kari?

Re:Did someone say Mythbusting? (1)

eneville (745111) | more than 7 years ago | (#17081460)

Where are the pics of Kari?
this thread needs more pics of Kari

deadly cross-site scripting (2, Insightful)

gad_zuki! (70830) | more than 7 years ago | (#17071598)

I swear officer, he was alive a minute ago. He was just sitting in front of his PC trying to check his bank balance!

Attack surfaces plural (1)

starfishsystems (834319) | more than 7 years ago | (#17071782)

This is a worthwhile article to keep on file. Its offers a clear and practical analysis of AJAX in terms of security principles, though biased toward server security and dismissive or incorrect with respect to client security. Read it critically.

Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design has therefore always required that pages function correctly without use of JavaScript, rather than forcing a client to be configured for greater vulnerability in general for the sake of accessing one website in particular.

But AJAX pages, by definition, unconditionally require JavaScript on the client. Hardened clients need not apply. If your security policy is not concerned with client security, or if your operation can afford to exclude some client systems, then you can regard the security of the AJAX client, as an attack surface, to be out of scope.

However, a general analysis of AJAX security also has to consider tightly integrated applications where client and server security are interrelated. Many web services exist for account administration, inventory control, system configuration, and other operationally critical forms of information management. Note how these activities are controlled by the client. In this context it's fine for servers to perform client authentication and input checking, but the advice to "never trust the client" completely misses the point of developing these applications.

Therefore, the article is incorrect to suggest that AJAX solutions need not be concerned with client security. Moreover, it's evident that AJAX creates a larger attack surface on the client. There are environments where you can decide to exclude these issues from consideration. In a general analysis of security, you cannot.

My experience (1)

bryanbrunton (262081) | more than 7 years ago | (#17072006)

The first web game that I wrote in PHP 3/4, called Merchant Empires (www.merchantempires) was hacked mercilessly. Of course, those were the good old games of the web when SQL injection was possible on a large number of main stream sites.

My second web game, called Grand Strategy (www.denizengames.com), is a full fledged Ajax application (written using DWR and Dojo) and the game hasn't been hacked (that I know of). Of course, I can only hope if those same Russian hackers hit it, they are as kind as they were before and they send details after they get tired of toying with the game.

Re:My experience (1)

LittleBigLui (304739) | more than 7 years ago | (#17074538)

I can only hope if those same Russian hackers hit it, they are as kind as they were before and they send details after they get tired of toying with the game.


It looks like they fed your server polonium this time. :)

Yet another double negative? (1)

monkeyboythom (796957) | more than 7 years ago | (#17072054)

This type of legalese is just plain irritating. And the phase is begging the question, so if a phobia were to walk by...would that make Ajax insecure? This is like the backhand complement, "You are not unattractive."

Gmail vs. Outlook Web Access (1)

PianoComp81 (589011) | more than 7 years ago | (#17072206)

FTA: Furthermore, in my experience, AJAX-enabled web applications are no more functionally complex than standard web applications. ... Gmail is less complex than Outlook Web Access.

Gmail and OWA both use AJAX. Heck, Microsoft created the XMLHTTPRequest object. Comparing Gmail to OWA to prove this point just doesn't make sense.

Re:Gmail vs. Outlook Web Access (2, Interesting)

jascat (602034) | more than 7 years ago | (#17073536)

It amazes me how people have such a false understanding of what exactly "AJAX" is. People talk about how complicated it is, which leads to insecurity. You're making requests and passing information back to the server via GET or POST. The only difference from the "traditional" way is that rather than visiting a different page, or having a self-processing page, you're having Javascript handle the sending and updating of a portion of the page. When you look at it from this perspective, you could potentially see a gain in server side security because you could build in input validation at the client side and at the server side. In theory, you could do some small scale protection of the client by incorporating validation at the client side for what gets returned to the Javascript. It all depends on how thorough you want to make it. Laziness is going to get you anytime you are dealing with user interaction, no matter what the platform is.

Ajax NOT Insecure? (0)

Anonymous Coward | more than 7 years ago | (#17072428)

If that's true, then why does he have to carry around that HUGE shield?

Or were you talking about little Ajax?

If Bandwidth Were Infinite... (1)

littlewink (996298) | more than 7 years ago | (#17074084)

then AJAX would not exist.

In the long term bandwidth will be (practically) infinite and whether processing is done on the server or the client will become irrelevant except that server-based processing will always be more secure and controllable.

AJAX is a temporary tool to enhance client-server interactivity until almost everyone has a high-speed Internet connection. Once that occurs such hacks as AJAX will disappear.

And good riddance! Because of it's arcane nature, security problems and greater development cost, I look forward to the day when AJAX fades.

Re:If Bandwidth Were Infinite... (1)

Saganaga (167162) | more than 7 years ago | (#17078184)

I don't think so, necessarily. Limited bandwidth is not the only reason Ajax exists. The Ajax technique is also great for providing a "hands-off" user interface. Digg Spy, for example (http://digg.com/spy).

Although I suppose you could implement that by refreshing the whole page every time. But that would also use up a lot more CPU.

Re:If Bandwidth Were Infinite... (1)

grimJester (890090) | more than 7 years ago | (#17079478)

Bandwidth is not the issue, latency is. As long as we're limited by the speed of light, latency will be a problem. Hence the need for the 'A' in AJAX.

Lack of understandig (1)

kosmosik (654958) | more than 7 years ago | (#17074680)

I think that there are none "inherently insecure" things. Anything can get somehow secured. I think that given a program that is specifically designed to be insecure one can still somehow (maybe by modyfiyng the enviroment it runs it or whatever) relatively secure. Well security in fact is quite relative.

So it is not that using AJAX itself is insecure. It is that probably lot of people will try to make AJAX apps since it is trendy right now. But AJAX *is* quite complicated or just new stuff. Somebody without experience and deep understanding how these things (and for me they are quite complex) works will probably make mistakes using some code generator and generally don't understanding fully what is going on.

It is nothing new. Security is mostly about knowledge and understanding. You can't make something secure that you do not know deeply and don't understand.

It is not technical (like this technology is insecure) issue IMHO.

Oh good golly, come on ! (1)

unity100 (970058) | more than 7 years ago | (#17075142)

You allow excessive processes to be run on client side, yet you say its secure ?

anything relegated to client side is exploitable to hell.

I'll tell you now and I'll tell you again (1)

guruevi (827432) | more than 7 years ago | (#17075848)

HTTP doesn't support client-side security. Not a single server supports client-side security. The only thing you can do is try to secure a client but you can't rely on the client not being compromised.

Avoiding XSS and Drive-by scripting (1)

MikeSamuel (124522) | more than 7 years ago | (#17076672)

The original article is right that there aren't any really new problems with AJAX apps, but they are different, so some mistakes are easier to make and some mistakes are harder.

Two of the mistakes that I've found easier to make with Ajax apps are XSS and drive-by-scripting attacks.

XSS attacks arise when a user can put text on your site that runs with the domain privileges of your site. Once they can do that, it's easy to steal user information, cookies, etc. and send it back, or make modifications to user data on their behalf.
The way to avoid XSS attacks is by properly escaping all text converted to html or javascript. The difficulty arises for two reasons
1) DOM manipulation is just too slow, so you end up having to generate html. Generating html safely requires keeping a lot of escaping conventions in mind.
2) Users often want to enter rich text, so you end up passing around some strings that are plain text and some that are (hopefully properly sanitized) html.

The first can be addressed by templating -- use something PHP or JSP like to generate your html. You can make it fast, and make it obvious what's escaped and what's not. It's not a silver bullet, but it makes the problem manageable. If you want to get fancy, you can make it smart enough to know that substitutions in HREFs should be encodeURIComponented, and substitutions in onClick should be escaped as javascript strings. Just make sure that people don't have to work around the system for those rare, but necessary cases where they know they've got safe content. It's much better for there to be clear, easily-audited exceptions to the rule than for people to have to bypass your system entirely to "fix" a critical bug late on Friday night.

The second problem is harder. A good static type system for javascript might allow different types for Strings that contain plain text vs. html vs. CSS vs. javascript. Then some simple static analysis could warn you when you add plain text to html to compose a string. Unfortunately, there aren't many such tools, so my recommendation is to use naming conventions. I know everyone hates anything that smacks of Hungarian notation, but do you find it easier to spot the bug in
    var name = document.form.myform.elements.myinput.value; ...
    nameNode.innerHTML = '<div>' + name + '</div>';
or
    var nameAsText = document.form.myform.elements.myinput.value; ...
    nameNode.innerHTML = '<div>' + nameAsText + '</div>';

In the second case, you're documenting what a variable contains, so someone reviewing the code has a hope of knowing what escaping schemes need to be applied when.

Drive-by-scripting attacks occur when someone malicious finds that you're using some neat JSON-like javascript to communicate between the browser and the server. It seems like a good idea and it is, because eval is fast, and you need every bit of speed because javascript interpreters are dog-slow.

And the cross-domain policies ensure that noone can do an xml-http-request and get back the javascript, and if they do, it's safe because it has no side-effect.
Unfortunately, anyone can write a script tag, and they can replace the Array constructor. So if your message contains an array, and they can trick your user into visiting their site, then you're screwed.

What do you do? Instead of sending over
    [valuable, user data]
send over
    while(1); [valuable, user, data]

That way, the constructor for the data they were trying to steal never gets executed, and no other javascript on their site executes, so hopefully the user realizes that that's not a good site to visit.

How does that help you? Well, since you're using XHR, and obeying the cross-domain policy like the fine upstanding citizen you are, you can just get the response text, and strip the "while(1);" from the front and go about your merry way.

Finally, a malicious site can try and make changes on your user's behalf, again by embedding script or image tags, which cause the browser to send requests with the user's cookies. This is only a problem for sites that user's keep open all the time, and that use cookies for authentication. It's also a problem that affects traditional web apps. The solution is that your AJAX client needs a secret that it can pass back with any requests (POSTs only please). That secret should match a cookie, and then your server can refuse any requests where the cookie and the cgi param don't match. It works because, although the attacker can cause the browser to make arbitrary requests, they don't have access to the user's cookies, and so can't craft a URL with a param that matches the cookie.
This should be done for all actions that change user data.

Some of these attacks may sound obscure and so only worthwhile against applications that manage valuable data, and some of them are only feasible for applications that users keep open most of the day, but you should hope that your application becomes one of those, so start thinking about it now :)

cheers,
mike

It's not that it's inherently insecure (1)

Ant P. (974313) | more than 7 years ago | (#17079962)

It forces you down a design path that leads to insecure code. If you want to plug every hole, you've got to do ten times as much work.

I wish there was some HTML attribute or some simple way of telling the user's browser things like "Don't let any of this part of the DOM tree be scripted from outside", or "this script is only allowed to do AJAX from these domains". Sort of like SELinux for HTML.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>