Sign up ×

Possible Duplicate:
Can a computer be infected by malware through web browser?

It is common knowledge that you can get a virus just by visiting a website. But how is this possible?

Do these viruses attack Windows, Mac and Linux users, or are Mac/Linux users immune?

I understand that I obviously can get a virus by downloading and executing a .exe in Windows but how can I get a virus just by accessing a website?

Are the viruses programmed in JavaScript? (It would make sense since it is a programming language that runs locally.) If so, what JavaScript functions are the ones commonly used?

share|improve this question

migrated from Jun 27 '11 at 18:05

This question came from our site for professional and enthusiast programmers.

marked as duplicate by ChrisF, Kyle, Nifle, Sathya Jun 29 '11 at 5:52


It is most often a combination of various techniques, and security leaks of browsers. – Paŭlo Ebermann Jun 27 '11 at 18:05
Good question, and IMHO, since it is web, it depends on HTTP and it no longer affected by the OS, the browser instead matters more than OS. – Kenan Deen Jun 27 '11 at 18:08
Very broad topic, browser vulnerabilities can change as they are discovered and vary from browser to browser. – Moab Jun 27 '11 at 20:47
On a related note:… – BloodPhilia Jun 27 '11 at 22:33
@LordCover: while initial scare tactics may be http, the payload must be an executable targeted to specific systems in order to get beyond a simple annoyance and become a true virus. Because Linux and Mac can't run exe's (without help, anyways) and Win can't run executables written for the other OSes, it is still an OS-dependent system. Recent hack-fests have shown Win7 to be comparable to (and in some ways, better than) Mac and Linux regarding security. Currently it is still the fact that most people run Windows that makes it a popular target. – music2myear Jun 28 '11 at 16:22

8 Answers 8

It is common knowledge that you can get a virus just by visiting a website. Can anybody explain how this is possible ?

Examples in parens. There's a bug in the browser (IE), the javascript interpreter, or in a plugin (like flash or java). This bug leads to code execution - that part can be really complicated but it often involves a use-after-free bug and heap manipulation.

Then I've got some shellcode running. The shellcode must escape whatever protections the browser has - for a V8/Chrome bug you'd have to escape chrome's sandbox and defeat DEP and ASLR. For IE, you'd have to beat DEP and ASLR and then bust out of the low integrity mode. For Java you'd have to... do nothing - you're all golden. (That's why there's been a spate of java bugs.)

So now that I've got arbitrary code running on your machine, as you (you're not running as admin, right?), I can go download a file from the internet and run it, dropping some malware on your machine.


Specifically - no. Javascript is an attack vector people will use to find a bug in a browser. They could also use Flash, Java, or Silverlight as an attack vector. In javascript's case, they write javascript to trigger the browser bug, and then the virus is eventually pulled down from the internet.

share|improve this answer
This is inaccurate. Viruses often do that, but are not required to (download extra code). They may have a payload embedded into the javascript-based exploit. That payload would be assembly code, but would be presented as javascript. It all depends on the bug, and the specific exploit implementation. – Merlyn Morgan-Graham Jun 27 '11 at 20:57
Did you just write that Java has no sandbox? Because it really does in every browser I'm aware of. – CarlF Jun 27 '11 at 22:13
@CarlF: No, this is not about the Java sandbox (which still exists). This is about bugs in Java - if these allow you to break out of the sandbox, there is little additional security (such as DEP) to stop an attacker. – sleske Jun 28 '11 at 0:08
Java is a major exploit-hole, it's bitten me twice. I disable it religiously now:… – Jeff Atwood Jun 28 '11 at 3:24
@Merlyn Yes, it is possible to put the entire payload into javascript and not download additional code (for instance all of the metasploit modules like 'Add an additional user to the system' or reverse_tcp). But sophisticated malware will usually use the shellcode in javascript as a stager to pull down more complicated, more sophisticated code. Everything depends on the bug and exploit - all the logic and shellcode could be in an image that busts an image parser - I'm just saying the most common route. – Tom Ritter Jun 28 '11 at 11:56

Unfortunately and perversely, there are any number of ways this could happen.

You are absolutely right to be astonished that a "reading device" like a browser could actively manipulate your own system (and do harm). Reading a book doesn't deplete your bank account and opening a newspaper doesn't hurt your children, so why can opening a website do all that and more?

The problem occurs whenever there is a possibility that foreign data from the internet, which we must always assume to be crafted with the utmost malicious intent, somehow manages to be executed by your system.

If you just sit at the command line and type wget, the wget HTTP client will simply write a binary dump of the request to your disk and nothing bad has happened (other than perhaps your disk filling up). But if you type the address into your browser, your browser is free to do whatever it wants -- format your hard disk, send your credit card details away, etc. It's up to you to trust your browser not to do that. Most browsers indeed attempt not to do those bad things, but we, the sheepusers have demanded that browsers be able to do ever more "clever tricks" and exhibit automatic behaviour based on instructions from the internet. Our demands have led to the creation of client-side code execution technologies like JavaScript and Flash, which download arbitrary, foreign, untrusted, malicious code and execute it, all for our pleasure.

The reason that the people who came up with those technologies weren't immediately lynched is because a) it made bunnies dance on our screens, and b) they claimed that they put sufficient safety checks into the design to prevent the arbitrary malicious code from manipulating the local system (e.g. not allowing to read/write the local disks, read/write the clipboard, read/write form fields in other tabs).

Unfortunately, the design approach to "first allow everything and then patchily cover up a few bad spots we can think of" is fundamentally flawed, and now we are facing a never-ending stream of new ways in which our client-side convenience features can be used to compromise our systems.

The only moderately safe way out is to disable JavaScript and plugins in your browser. Safe like we were in 1995.

share|improve this answer
+1 for strikethrough sheep – JYelton Jun 27 '11 at 20:37
Wget isn't "safe", nor are the drivers that run your machine, nor are any of the kernel level systems. There are mitigations, but ultimately every piece of code is potentially subject to attack. – Merlyn Morgan-Graham Jun 27 '11 at 20:52
@Meryll: I was omitting one whole class of problems, namely those coming from faulty code. Yes, there is definitely a threat from broken image libraries and MP3 header parsers and such things. I didn't want to go too far. I found the problems arising from the design of modern internet technologies far more pertinent to the OP's question. – Kerrek SB Jun 27 '11 at 20:58
@Kerrek: Their question was "can I get a virus from visiting a web page," and you went on to say that they couldn't get a virus from wget. You also talk about trust. But the question is not about "how do I protect myself", but more about "how would an exploit work". Attack surface seems to be your main point, which is a great one, but clouded by these inaccuracies and tangents. – Merlyn Morgan-Graham Jun 27 '11 at 21:02
Yeah, I was simplifying a bit ... I didn't want to clutter the argument with a detailed "in principle there could be a fault in wget that causes it to behave unexpectedly" aside. You're right of course. I figured that the OP appears to be new to the field and wanted to focus on the more fundamental and conceptual problems of our IT society rather than problems due to technical faults. – Kerrek SB Jun 27 '11 at 21:04

The point that's really been sidestepped in these answers, that I really want to beat home, is this: the reason you can get a virus from a webpage is that some software you're running has a bug - a security vulnerability.

In every step of the process of creating the software, the creators of Flash; of your browser; of your operating system have tried to make sure random, malicious code from the internet can't just figure out a way to execute itself. Unfortunately, doing this is hard. Really hard.

So, like all humans, the developers of this software are bound to make mistakes: the HTML parser accidentally overwrites one byte in the stack when you end the html with </p. They accidentally used a signed int instead of an unsigned int. The javascript JIT-compiler accidentally tries to dereference an array-index into a null-pointer. All of these vulnerabilities plus millions more occur all the time in software, either because of lack of security knowledge, or an oversight, or even just a simple mistake. Software is simply way too complex to catch them all.

Because of this, operating systems have built-in mechanisms to prevent damage to the system, even when a vulnerability is found. Your OS probably has DEP and ASLR. Programs can have various protections added by the compiler. Browsers run at lower priveledges. Programs are run through automatic analysis and testing that can catch a lot of these vulnerabilities.

My point is, nobody is letting this happen - but it's impossible to design completely secure software, just like it's impossible to design a completely secure safe. Someone with enough time, knowledge, money and incentive will always find a way to crack it open. And the problem with this safe is, once some hacker cracks open their copy of it, they can easily open other copies around the world without leaving their room.

share|improve this answer
+1 for the bolded sentence at the top. – Breakthrough Jun 28 '11 at 14:03
But in many cases the bug is there because users "demanded" it. Ie, the spec for HTML3.14159 is defective in that it allows some behaviors that are inherently risky. And site designers use the specific features that provoke these behaviors, requiring that browser designers implement the "feechurs" (or risk being left behind in the "browser war"). The browser designer likely attempts to mitigate the risky behavior somehow, and antivirus implementers pile on additional checks, but something always gets through. – Daniel R Hicks Jun 28 '11 at 17:26
@DanH: Do you have any specific examples of security holes that are intentionally left in all browsers, because users demanded it? – BlueRaja - Danny Pflughoeft Jun 28 '11 at 17:42
I'm not saying that the holes are left there intentionally. Rather, poor specs lead to "risky" implementations, and in too many cases the implementation is (obviously) not provably correct, from a security standpoint. (And it's not provably correct because the spec doesn't enable it.) – Daniel R Hicks Jun 28 '11 at 18:31
Ah yes, computer science... The science in the world where there are cars driving the wrong way on a one-way street half of the time, and teleport to the opposite end the other half. – Breakthrough Jun 28 '11 at 18:38

Your specific questions


Your browser is executing code all the time (it is made of code). When it downloads web pages, that code is downloading and displaying arbitrary data (pixels, characers, etc).

Code is also data (at the processor level).

Since code is data, if your browser tries to execute the data (no matter what the file extension or format), it might actually run (if crafted correctly).

Normally your browser won't be so foolish as to try to run random data it downloaded. However, this can happen.

One way to do this is to form the data in such a way that when read, it will "leak through" and overwrite the data that makes up the browser's executable program. This requires the browser to have a bug (most commonly in this case, allowing a buffer overrun).

Your browser also runs programs on top of web pages. Javascript, as you mentioned, is one such type of code. But there are dozens. ActiveX, Flash, add-ons, grease monkey scripts, etc. are all code which you are running while visiting web pages. This code can contain bugs that cause security breeches.

Do these viruses attack both Windows, Mac and Linux users or are Mac/Linux users immune ?

No platform we use is completely immune to bugs, because they are all using processors that treat data as code. This is simply how our existing computer architecture works.

The reason for this myth is that Mac and Linux have much lower adoption rates compared to Windows machines (at the desktop level). So desktop software on these machines is not as common a target for virus makers.

Viruses don't occur by magic, or by happen-stance evolution (as biological viruses do). It is software written by individuals, or teams of developers. And they want to target the biggest market share, the same way regular software vendors do.

As for whether one virus can target multiple platforms; All browsers are running different code, so will have different bugs (even the same browser on different platforms). But there are some code libraries that are shared across platforms. If such a library contains the bug, it is possible that the exploit could exist on multiple platforms.

But, depending on the type of attack made, a virus written for a non-Intel Mac might not work on an Intel Mac, and vice-versa, because they have different processors. For different processors, the data that represents the code has a different format.

When you're talking about a virtual machine or scripting language, though, attacks might be platform independent. That leads us to the next question...

Are the viruses programmed in JavaScript?

Some viruses are. The information I stated above (about buffer overrun exploits) would usually be used as an attack outside Javascript, but could equally well apply to a virus crafted to attack an exploit in a Javascript interpreter.

Javascript will also have its own set of exploits, at an operating level that is above buffer overruns. There are a whole host of ways to attack any piece of software. The bigger the software is (lines of code), the more varieties of user input (in this case, types of code) it is likely to receive, and the more bugs it can contain.

Also, the more exposed a running piece of software (e.g. software running a server), the more vulnerable it is to attack.

In general, this is called Attack Surface

Exploits in general

Microsoft has a mnemonic for common exploit types, and they all have their own interesting properties, and different levels of software that they can attack - STRIDE, which stands for:

Spoofing (of user identity)
Information disclosure (privacy breach or Data leak)
Denial of Service (D.o.S.)
Elevation of privilege

Some of these are more likely to be used in an attack based on Javascript than others, some on servers, some on data files (such as images).

But security is a big and evolving field. There is really too much information to completely answer all of your questions.

share|improve this answer
When you're dealing with interpreted (versus compiled) languages, the exploits are usually architecture independent. An application (or virus) compiled for a different processor architecture will simply not run (unless the processor contains a compatibility layer). – Breakthrough Jun 27 '11 at 18:43
@Breakthrough: Them asking "are they programmed in javascript?" doesn't make what I said any less true, especially when applied to "how can I get a virus just by accessing a website". They asked multiple questions, and what I described applied to part of the question, if not all of it. – Merlyn Morgan-Graham Jun 27 '11 at 20:34
@Breakthrough: I added more information about Javascript specifically, and threats in general. – Merlyn Morgan-Graham Jun 27 '11 at 20:43
@Merlyn Morgan-Graham, I was specifically referring to when you said "...a virus written for a non-Intel Mac might not work on an Intel Mac, and vice-versa, because they have different processors." and not your entire answer. – Breakthrough Jun 27 '11 at 22:09
@Breakthrough: Oh, yes that is a good point. I'll fix that, although again, it depends on what sort of exploit it is. If it is a buffer overflow, then the payload code would be processor dependent to have a useful effect. – Merlyn Morgan-Graham Jun 28 '11 at 0:20

The term is called "Drive By Download"

Here is a nice example of how it happens without you doing anything but visiting a website.

Schneider said that the company's team of researchers discovered a piece of JavaScript on the page that was injecting an iframe that pointed to a malicious site. Closer inspection revealed that it was using a previously unknown (0 day) exploit of IE capable of crashing a fully patched version of that browser and executing malicious code. The 0-day was short lived though, as Microsoft soon released details on the vulnerability.

Further analysis of the shellcode revealed a clear-text URL pointing to a known malicious server, which was stored in M86’s repository as having exploited the well-known iepeers.dll vulnerability, MS10-018.

share|improve this answer
+1 for being the only answer so far to use the proper term. – Breakthrough Jun 28 '11 at 18:40

The trick is that virus makers / security experts find loop-holes in browsers. In simple words, they find a hole in the security of the browser and they are able to use this hole to do something to your system. There are cases that Adobe Flash had holes and with specific code it could be exploited. There are also javascript strings that can trigger these security holes.

Nevertheless if you keep your browser up to date it is very unlikely that you get infected by just visiting a website (download files and executing them is another story!)

share|improve this answer
There are security bugs in every piece of software that exists. Not all of them get found. Microsoft Paint had a nasty bug for a long time, for example, that was easily re-producable (within minutes) by simply throwing randomly generated data as "images" at the "file->open" dialog. – Merlyn Morgan-Graham Jun 27 '11 at 18:27
Well, I'm sure there has been some bit of software written somewhere without security bugs. (I think I've maybe written one or two myself.) But you have a good point. About 35 years ago someone demonstrated dozens of bugs in Unix by simply feeding random characters into the shell command parser. Crashed the machine within minutes. – Daniel R Hicks Jun 28 '11 at 18:35

Viruses like the ones that infect you by visiting a web site exploit a flaw in the visiting system. For instance, a browser or plug-in might have a flaw in its programming so that an image might be allowed (accidentally, from the perspective of the browser developer) to run an arbitrary command on the visiting computer.

As such, supposedly every operating system is a potential victim, but virus writers usually frame their attacks based on economies of scale - the more users, the better. That's why Windows and Internet Explorer are more often targeted.

Any part of a browser or plug in might be targeted by a virus. The above mentioned image-that-caused-a-virus was a real example. Flash is a common target. The JavaScript engine in browsers is too. There are a lot of different things that can go wrong.

Your best bet is to run a quality virus scanner. I used NOD32 by Eset. Also, don't click on something if it is too good to be true. Use NoScript in Firefox, and AdBlock.

share|improve this answer


If a website manages to breach your browser's security, it could muck with anything that belongs to you on the computer. However, if it can escalate its privileges and gain administrative access, then it could muck with anything on the system at all.

It has long been held that it is harder to gain administrative privileges on a Unix machine (e.g. Linux, Mac, or BSD) than on Windows. However, the recent (as of Windows Vista) revamp of security features by Microsoft may have made Windows much more secure than before--or at least, that's what they'd have you believe.

share|improve this answer