User Controls
Web apps and shit.
-
2017-03-05 at 2:28 PM UTCSo if you go to this link http://www.edubookplus.com/addons/pager/jquery.tablesorter.pager.js you will see the page source. If this is normal behavior please let me know because i don't think it is.The following users say it would be alright if the author of this post didn't die in a fire!
-
2017-03-05 at 9:36 PM UTCIt's just a javascript file. Are you expecting your browser to download the file rather than display it?
-
2017-03-05 at 9:49 PM UTC
Originally posted by SBTlauien It's just a javascript file. Are you expecting your browser to download the file rather than display it?
I don't know what i am supposed to expect, i ain't no web developer. It just seems weird to me that it would display source like that because generally source code disclosure is considered to be bad. -
2017-03-05 at 11:17 PM UTCI see javascript files, css files, txt files, all the time. I believe it's more of php files, pl files, that you're suppose to hide. Javascript is running client-side so you can't really hide it unless you're really trying.
-
2017-03-05 at 11:46 PM UTC
Originally posted by SBTlauien I see javascript files, css files, txt files, all the time. I believe it's more of php files, pl files, that you're suppose to hide. Javascript is running client-side so you can't really hide it unless you're really trying.
This. Well further actually, many people argue you should assume all your source is available to an attacker, trying to hide implementation in the name of security is called security through obscurity, which is sorta kinda mostly considered a bad practice but not always. Sorta.
Javascript files are always served to the client, there is no way to avoid disclosing their contents. You can minify source which makes it harder to read, like we do here: http://niggasin.space/static/js/thread.7b8b50ef9cb5.js but you can mostly reverse the process and it's not _that_ hard to read, sometimes bad things happen to good people you end up needing to debug minified code. Minification is primarily used to bring transfer sizes down and also to feel 1337.
Also when we talk about "page source" we're usually referring to the HTML document that backs a page (which is what you see when you use your browser's "view source" control). The primary function of a browser is to render a document, that is transform it from source to something on you screen, so for every document there's a visual representation and a source representation. Javascript doesn't have the same duality. You can execute a javascript file but the effects of that are only visible through altering an HTML document somehow, there is no real visual representation of a javascript file other than its source, so that's why following the url to a javascript document will (unless there's some server side fuckery involved) display its contents.The following users say it would be alright if the author of this post didn't die in a fire! -
2017-03-06 at 12:53 AM UTCAh, well now i feel stupid and a little smarter at the same time, it's an abstract sort of feel.The following users say it would be alright if the author of this post didn't die in a fire!
-
2017-03-06 at 2:22 AM UTCSomeone can also hide javascript inside an image(polyglot) and have their server serve that image using "text/javascript" in the 'Content-Type:' header. They could place this image on one of their webpages where your browser ultimately requests that image from their server and the javascript is executed(if you have it enabled) without you knowing where it came from(unless you know to look at the contents of an image). This actually worked really well for me on my server that I occasionally run from my phone.
Chapter 7: https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf
Not sure if you already knew this though. Also this isn't what you were talking about but I wanted to share. -
2017-03-06 at 2:50 AM UTCwaaat? That shouldn't be possible. That's like a really fucking serious exploit if true. Time to read
-
2017-03-06 at 3:02 AM UTCOh, I see, it looks like it's just a way of delivering a secondary payload? Maybe useful for avoiding heuristic detection but it doesn't look like you can get JS execution by simply serving some manipulated image.
-
2017-03-06 at 3:58 AM UTC
Originally posted by Lanny Oh, I see, it looks like it's just a way of delivering a secondary payload? Maybe useful for avoiding heuristic detection but it doesn't look like you can get JS execution by simply serving some manipulated image.
The image is served by the web server as text/javascript, so it's basically the same as serving a legit .js script, except that the typical user wouldn't be able to see/detect it. Furthermore, one can obfuscate the javascript within that image...
http://utf-8.jp/public/jjencode.html
Edit: Do you think it's possible to attack someone from this site, through an image posted on this site?
Post last edited by SBTlauien at 2017-03-06T04:55:57.070803+00:00 -
2017-03-06 at 5:26 AM UTC
Originally posted by SBTlauien Someone can also hide javascript inside an image(polyglot) and have their server serve that image using "text/javascript" in the 'Content-Type:' header. They could place this image on one of their webpages where your browser ultimately requests that image from their server and the javascript is executed(if you have it enabled) without you knowing where it came from(unless you know to look at the contents of an image). This actually worked really well for me on my server that I occasionally run from my phone.
Chapter 7: https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf
Not sure if you already knew this though. Also this isn't what you were talking about but I wanted to share.
Isn't that basically how drive-by payload drops work? Load some spooky hidden random ass JS that downloads the malware binary or whatever. -
2017-03-06 at 5:33 AM UTC
-
2017-03-06 at 5:57 AM UTC
Originally posted by SBTlauien The image is served by the web server as text/javascript, so it's basically the same as serving a legit .js script, except that the typical user wouldn't be able to see/detect it. Furthermore, one can obfuscate the javascript within that image…
http://utf-8.jp/public/jjencode.html
That shouldn't happen, if a resource isn't requested as an image it should never make it to the js parser. For example, take this asset: http://niggasin.space/static/js/thread.7b8b50ef9cb5.js It's served with Content-Type: application/javascript, if we try an embed it via an img tag:
Nothing, it doesn't run. It couldn't, even if can induce the browser to request an asset it won't be anywhere in the DOM as a script.Edit: Do you think it's possible to attack someone from this site, through an image posted on this site?
Post last edited by SBTlauien at 2017-03-06T04:55:57.070803+00:00
If it works as described then yes, but that couldn't be, every site that allows user embedded images would be exposed, if you can load JS then you can take arbitrary user actions, the whole browser security model is built around the assumption that only the host, client, and trusted parties can execute client scripts.
Originally posted by aldra I've been able to get some sites to do it with php in the past - php file renamed to .jpg with the php script presenting base64 image data at the end of program flow
You mean for inducing the server to execute the php file? A poorly written upload/serve strategy could produce this but in this case I think we're talking about loading scripts to run on the client via images. -
2017-03-06 at 6 AM UTC
Originally posted by Lanny You mean for inducing the server to execute the php file? A poorly written upload/serve strategy could produce this but in this case I think we're talking about loading scripts to run on the client via images.
the idea is that when the php script finishes running it presents standard jpg data - so you could upload the php file where it requests an image (ie. an avatar upload option), upload the php file and by default, when it's parsed it runs the php script that outputs the image data
I have no doubt that most places will protect against it in one way or another but I got it working with an old version of SMF at least -
2017-03-06 at 7:24 AM UTC
Originally posted by Lanny If it works as described then yes, but that couldn't be, every site that allows user embedded images would be exposed, if you can load JS then you can take arbitrary user actions, the whole browser security model is built around the assumption that only the host, client, and trusted parties can execute client scripts.
http://niggasin.space/thread/8183
So when the op in the above thread posted his giant image, the tag is...
<img src="http://i.imgur.com/Uht7g2R.png">
Doesn't this tag request that particular image from that server(i.imgur.com)? And wouldn't that mean that that server(if it were malicious) could serve that image as text/javascript?
Right now on my server, if you request the image below, I have it set up to serve the image as "text/html". The URL shows it as a .png image, but when served from my server, the css shows a little box moving around and when it's clicked on, it displays "SBTlauien". You can see the css code within the image, I didn't hide it.
http://www.angelfire.com/un/sbt/images/hat.png
On AngleFire it obviously wont work because I can't choose to serve it as "text/html".
Would you be willing to host this image so that I could try to display it on my AngleFire site to see if the css script works? -
2017-03-06 at 8:24 AM UTCOh, I see what you're saying. Hmm, I guess yeah, if you load the image by punching it into your address bar and the server responds with an html content type then yeah, maybe the browser will interpret it as a document, and maybe the parser will find some way to discard the binary slop. But it won't work if you embed it in another page. Content type is largely ignored when loading images from an img tag in some other page. Once you load it on a separate page then the page takes on that domain as its origin, so you can't like inject a malicious script to make posts on niggasin.space because that's now a cross-domain request.
Is there a use case for this? XSS is out and if you have some exploit that requires JS execution you already have the user on the page, so you can just serve a regular document. Is the idea that it's easier to get a user to click an image than lure them to a shady webpage? -
2017-03-06 at 9:50 AM UTC
Originally posted by Lanny Oh, I see what you're saying. Hmm, I guess yeah, if you load the image by punching it into your address bar and the server responds with an html content type then yeah, maybe the browser will interpret it as a document, and maybe the parser will find some way to discard the binary slop. But it won't work if you embed it in another page. Content type is largely ignored when loading images from an img tag in some other page. Once you load it on a separate page then the page takes on that domain as its origin, so you can't like inject a malicious script to make posts on niggasin.space because that's now a cross-domain request.
Is there a use case for this? XSS is out and if you have some exploit that requires JS execution you already have the user on the page, so you can just serve a regular document. Is the idea that it's easier to get a user to click an image than lure them to a shady webpage?
I see. So it wouldn't work if it were cross domain, unless the user for some odd reason had that enabled. I was thinking that when my browser loads the page that your server serves, and it comes across that specific tag(<img src="http://i.imgur.com/Uht7g2R.png">), that it does a full request of the image's URL from that server. -
2017-03-07 at 2:52 AM UTCYeah. I mean it does do a full request, but not every request is loaded onto the page. Like an AJAX request for example, it returns some data but it's up to the requestor to actually do something with it. Like open your dev tools, look at the network tab, and put this into the console:
$.get('/')
You'll see a request made to the home page but nothing is done with it. Same thing with the image, it will trigger the request but it won't execute the embedded script -
2017-03-08 at 3:08 AM UTCHere is a polyglot that Lanny agreed to host for me...
http://168.235.79.36/hat.png
Edit: Normally the "‰PNG IHDRp–û-N¹iTXt" wouldn't be there but I messed up making it...
