2

Malicious JavaScript (generated by malicious hosted PHP code for example) can lead to attacks. What are the types of attack that malicious javascript could perform? Are the drive-by download attacks the only ones that malicious javaScript performs?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320

3 Answers3

1

To see an explanation of typical methods of exploiting Javascript, it would be better to get a book on the subject, rather than rely on fragmentary answers here. There are many such books, for example:

"The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" by Dafydd Stuttard, and Marcus Pinto.

"XSS Attacks: Cross Site Scripting Exploits and Defense" by Seth Fogie

If you would like a quick summary of past and known exploit types involving Javascript, you can check out MITRE's CVE (common vulnerability) database using the keyword "javascript":

MITRE CVEs involving Javascript

There are about 1,000 Javascript CVEs and perusing them will give you a complete view of the normal range of hacks using Javascript.


Perhaps a better way to approach your question, is not so much to provide a zoology of "attack types", but to understand why a web page containing Javascript is more likely to be able compromise a web client, than a page which has just plain HTML.

Javascript presents an increased security risk for two main reasons: (1) it is much more complex than HTML, and (2) it allows for more sophisticated interaction with the user, hence more opportunity to trick the user. Thus, there are two basic vulnerability surfaces, the client code and the human/social engineering factor.

When the client parses and reacts to HTML content, the range of possible actions is much more limited than the range of possible worlds that may arise after parsing and running Javascript. To protect against malicious code, the client programmer must anticipate every possible thing that could happen and avoid any bad consequences. Obviously, this is much harder to do for a computer program, than for page layout instruction.

Tyler Durden
  • 1,116
  • 1
  • 9
  • 18
0

There are many possible attacks, which all depend on the JS engine, the available API and the execution environment. JS is a language after all even though I suspect you only are interested in the Web uses. I know next-to-nothing about Web security, but for instance JS is also part of the PDF format

5 years ago you could load DTD's in a XML document in your JS code on Acrobat Reader, and make an external entity of your DTD point to local files on the system so you could get to read them if they were XML-like or plaintext. Obviously this was an unintended consequence of the API, which was changed. No engine bug in that cause though. Nowadays the same attack with the same API would also be impossible because the execution environment changed: Acrobat Reader now sandboxes the PDFs it opens (in Protected Mode).

In short, even though I can't really answer your question I can still tell that someone who doesn't cover all of this is not properly answering:

  • bugs in your engine allow a (resourceful) attacker to do anything they want
  • flaws in the API allow an attacker to do small unexpected things (cross-site scripting, clickjacking, keylogging fields you fill and then delete)
  • a permissive runtime environment favours or enables attack
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
-1

Most of the Vulnerabilities in the browsers are in the complex parts, such as the dynamic DOM-tree building.

This is something that Javascript does, when a programmer makes a mistake (such as a use-after-free) people can exploit this. And by writing specific javascript you can groom the heap to hold the exact values you need to make the browser do what you want (as an attacker).

The other thing is like the beef exploit framework, uses the tricks the browser allows you to do (like Steve DL notices).

Stolas
  • 333
  • 1
  • 13