JavaScript injections

[Wso]

Not sure if someone made this already but anyone know any cool JavaScript injections? Thought it would be cool to have a place to share some good ones. Personally I like:

 

Javascript:document.body.contentEditable=%22true%22;document.designMode=%22on%22;void0

 

It lets you locally edit the we page.

[Endy0816]

I think you are talking about bookmarklets or their big brother equivalents(Greasemonkey, Tampermonkey).

 

JavaScript injection typically refers to having your code run by someone without their permission or knowledge. Can have a lot of fun with this, but so too can the bad guys.

 

I did make a Userscript(Greasemonkey) that did almost exactly what you've posted above. Local storage is another fun one to play with, along with passing messages between tabs. Most of my stuff is more for game improvements though. The only actual bookmarklets I have, I made for rapid equipment of game items.

 

ie. javascript:adoptThing(309,%20false);adoptThing(318,%20false);adoptThing(302,%20false);adoptThing(534,%20false);adoptThing(363,%20false);adoptThing(348,%20false);

 

Best way, I think, if you just want something quick, without spending alot of time mucking about with the site's innards.

Edited February 23, 2014 by Endy0816

[AtomicMaster]

Let's talk about javascript injections And as much as i love talking about specific injections, javascript and javascript obfuscation (heck i wrote a parser/obfuscator/reassembler), since we are in the CS section, let's actually talk about XSS from the perspective of comp-sci.

 

Let me start with classifying the type of attack/error, then dig deeper to cause, find relatives of the errors. Or at least that's where i will start, if anyone wants to have an intelligent discussion on the topic, hopefully they will jump in and we can go for it

 

Classification

 

LangSec Inter-Language Interoperability Error

 

Injection of code by making a parser think of user data as code is the typical trait of any Language Security Issue, thus its a LangSec error. Furthermore, this does not necessarily occur as a result of a poor language implementation, but rather due to language interop (see cause), and thus it's an inter-language interoperability error.

 

Cause

 

Because the internet is a tangled web of unrelated technologies, which all speak different languages, to be successful at providing programs that operate within the internet paradigm we haven't a choice but to use multiple programming languages to combine necessary technologies for the software to work.

 

e.g. When we pull up scienceforums.net (leaving the low-level languages aside), our HTTP request gets processed by the web server (most likely apache), which extracts data from the request and passes it on to PHP, PHP needs some data, which it doesn't store, so it talks to a back-end (most likely) MySQL (though it could also have other things it talks to, like Memcache), but let's keep it simple, we have PHP and MySQL. When MySQL is done it replies back to PHP, which then finishes processing our request. Since the page is not simple, PHP replies in JSON to the JavaScript which made the request, which then parses the JSON and puts it in the corresponding context(s) of the DOM as HTML and CSS. So we have HTML talking to PHP which talks to MySQL, which talks to PHP which talks to JavaScript which outputs to the DOM.

 

The problem with these technologies is that most of them have no way of communicating to each other what is user-data, and what is not. There is no standard, there is no special back-end way to share state-machines, so the only thing that all these languages ultimately understand is strings... (this has been changing with some of the mentioned languages, but let's forget that for a minute). Since it is a string, the next language in line has to build it's own state based on the input it has, which to it seems all like programmer input, so as soon as you reach this gap in language interop, the next, and every other language after that looses the exact notion of what the user input originally was. And of course none of these languages speak any of the other ones, and so they can't know what is a good and what is a bad input (i.e. to sql the string of alert(1); means really nothing, well syntax error, while to JS, the same string means something entirely different)

 

So following this issue from a cause perspective we learn that XSS is actually caused by the same core issue that causes SQLi errors. They are, in fact, twins

[Wso]

Let's talk about javascript injections And as much as i love talking about specific injections, javascript and javascript obfuscation (heck i wrote a parser/obfuscator/reassembler), since we are in the CS section, let's actually talk about XSS from the perspective of comp-sci.

 

Let me start with classifying the type of attack/error, then dig deeper to cause, find relatives of the errors. Or at least that's where i will start, if anyone wants to have an intelligent discussion on the topic, hopefully they will jump in and we can go for it

 

Classification

 

LangSec Inter-Language Interoperability Error

 

Injection of code by making a parser think of user data as code is the typical trait of any Language Security Issue, thus its a LangSec error. Furthermore, this does not necessarily occur as a result of a poor language implementation, but rather due to language interop (see cause), and thus it's an inter-language interoperability error.

 

Cause

 

Because the internet is a tangled web of unrelated technologies, which all speak different languages, to be successful at providing programs that operate within the internet paradigm we haven't a choice but to use multiple programming languages to combine necessary technologies for the software to work.

 

e.g. When we pull up scienceforums.net (leaving the low-level languages aside), our HTTP request gets processed by the web server (most likely apache), which extracts data from the request and passes it on to PHP, PHP needs some data, which it doesn't store, so it talks to a back-end (most likely) MySQL (though it could also have other things it talks to, like Memcache), but let's keep it simple, we have PHP and MySQL. When MySQL is done it replies back to PHP, which then finishes processing our request. Since the page is not simple, PHP replies in JSON to the JavaScript which made the request, which then parses the JSON and puts it in the corresponding context(s) of the DOM as HTML and CSS. So we have HTML talking to PHP which talks to MySQL, which talks to PHP which talks to JavaScript which outputs to the DOM.

 

The problem with these technologies is that most of them have no way of communicating to each other what is user-data, and what is not. There is no standard, there is no special back-end way to share state-machines, so the only thing that all these languages ultimately understand is strings... (this has been changing with some of the mentioned languages, but let's forget that for a minute). Since it is a string, the next language in line has to build it's own state based on the input it has, which to it seems all like programmer input, so as soon as you reach this gap in language interop, the next, and every other language after that looses the exact notion of what the user input originally was. And of course none of these languages speak any of the other ones, and so they can't know what is a good and what is a bad input (i.e. to sql the string of alert(1); means really nothing, well syntax error, while to JS, the same string means something entirely different)

 

So following this issue from a cause perspective we learn that XSS is actually caused by the same core issue that causes SQLi errors. They are, in fact, twins

Thanks, this was very helpful and informative. Id love to have a discussion, I don't know much about these errors/attacks but I'll give it a try anyway. What I was wondering is how these types of attacks can be detected. I understand you may block certain strings that can be mistaken as code by another machine using a different launage, but how can you tell, say, what IP adress sent out that specific request. And if the user/hacker were clever enough could they send a string to the server that would mask their IP? Or are some commands too powerful for any system to allow outside strings to influence. If this reply didn't make any sence at all then sorry, like I said I'm still pretty new to this. Edited March 4, 2014 by Wso

[AtomicMaster]

I understand you may block certain strings that can be mistaken as code by another machine using a different launage

That is however a poor approach to solving this problem, short of implementing a full parser for a language, which is impractical, the programmer way is to use regular expressions, but those can be either too broad, or have potential to be bypassed. That part actually goes with a language theory; you can't parse a context-free expression with a regular expression. Simple example if you would like to ponder, ask yourself if you can parse html with a regular expression?

 

 

but how can you tell, say, what IP adress sent out that specific request.

Networking 101, HTTP is an application layer protocol.

 

 

 

And if the user/hacker were clever enough could they send a string to the server that would mask their IP?

No, they can change their ip other ways, but they can not send a string that will mask their ip on the server, networking 101.

Edited March 4, 2014 by AtomicMaster