What Malicious Things has Javascript Done To You?

Question

I asked the question: What's with those Do-Not-Use Javascript People and many people said that Javascript allows security exploits through client-side attacks.

So I need to follow up and understand the how bad the nature of these attacks are:

I'd like to hear some detailed descriptions of actual attacks or damage caused to your computer or your network that was directly or indirectly caused or allowed via Javascript.

Specifically, was there any physical damage caused to your computer or network? Did you lose any data? Was any of your software damaged? If any damage happened, how long did it take to fix, and how much did it cost?

Or was the attack stopped before it did any damage and how was it stopped? How long did this take and how much did it cost?

I don't consider popups an attack. They are simply an annoyance that can easily be blocked without disabling Javascript.

Please only detail attacks that you personally have attended to. I trust your wisdom as programmers, but I don't trust third party stories as much, where the cause might have been something else.

Answer 1

Well, any malicious JavaScript is ultimately going to be acting through browser capabilities, so this proof-of-concept demo might fit what you're looking for. It exploits the fact that a page can dynamically create a link to a given URL, then check what color it is to find out if your browser considers that site to be part of your browsing history. All that link does is try to guess your gender, but the same idea could be used for attacks - say, it could test for URLs of major banks, and present you with a phishing attack customized to whatever bank you use.

Of course this may be (ought to be) fixed in future browser releases, but then that's true of most exploits.

Answer 2

Hmm... Can 0wn you. I mean literally can own the whole computer, install a trojan.

I've seen and done so many XSS attacks successful which caused to steal administration's session and control the whole application. I've seen and done delivering a client side attack such as the link above, which caused installing another application (a RAT) and control the whole box.

After this point as an attacker you can start to attack internal network, such as you can own the router and then control the whole company traffic, you can attack the domain controller, or you can use pass the hash tool or a similar tool to steal local credentials and attack other systems with those credentials. After this point it's all about the security of the other computers (and the local computer if the browser was running as a least privileged used instead of an administrator account)

Answer 3

Don't let your end users insert HTML markup that allows either a < script > tag, < style > tag, the style attribute or any on_? event attribute... and watch the content of href and src attributes

E.g. if you have a blog, don't just let them comment with any HTML.

Why?

1.) script tag is obvious, they can do whatever they want

2.) style tag and style attribute isn't so obvious, but in IE, they can use the behavior or expression properties to invoke script content

3.) any onclick, onmouseover, etc. attribute can obviously include script content so avoid it too.

4.) watch href and src attributes, if they contain the "javascript:" protocol, you are exposing script too.

Update: throw in < iframe >, < object > and < embed > as dangerous tags too...

Answer 4

On my site nizzote.com/welcomeSO

I use <textarea> to collect text which i sanitize but someone saved </texarea><script> for (var i = 1; i > 0; i++) {alert("press ok one more time");}

and when the page was loaded again it would get you stuck in an alert box that you would have to close the browser to get out of.

I saw it pretty soon and htmlencoded all inputs to solve the problem. (c# httputility.htmlencode(string) ) no real damage or cost and the fix was quick.

Answer 5

Look at this post here at SO, that uses javascript to trick IE to run something it shouldn't.

Answer 6

An injection attack on a vulnerable input script on a client site caused a trojan-loading script body to be appended to each and every text field in their database via an automatic MS SQL script. We ended up using the script to negate itself to clean it up, but quite a few people got some sort of infection through a server in China before the hole could be plugged.

This applies to this in that the injection hole was one created through a javascript reference (an AJAX call) and the deliverable was also caused via the subsequently injected javascript.

Answer 7

I personally haven't had any problems except for a few browser crashes here and there (and that's mostly from poorly-written code). Don't read too much into this, I definitely understand that javascript is a pretty wide attack vector; I'm just saying what is true for probably 80-90% of internet users and not web app developers.

Answer 8

Spoiled me from enjoying statically linked strongly typed languages. And forged an involuntary bond of dependency on some guy named Crockford.