Earlier quoted context omitted.
Seems like some bits are missing on that page, e.g. I see nothing between "What is the bootstrap? Well, it's what turns our PNG into code and runs it. Here's the one I use:" and "The 4968 here is really the size of the decompressed data in bytes times 4"
Good catch -- thank you! Imported this from an older blog and must've lost that code block somehow.
This JPEG is also a webpage
91–100 of 236 posts
Re: This JPEG is also a webpage
#92You can see this in action for yourself on a unix cli: $ curl -o squirrel.html http://lcamtuf.coredump.cx/squirrel/ $ file squirrel.html squirrel.html: JPEG image data, JFIF standard 1.01, comment: " body { visibility: hidden; } .n { visibilit" Open the file in a browser and read the page. Then: $ mv squirrel.html squirrel.jpg Open the renamed file in a browser and only the image appears. I'm not sure what the securi…
You can use this technique to phish signatures. Send someone a document that reads "X" in format A and "Y" in format B. The victim signs file.A thinking they are endorsing X but you can plausibly claim that they signed file.B (because it's the same file) and hence endorsed Y. This is why digital signature standards need to include meta-data, e.g.:
https://github.com/Spark-Innovations/SC4/blob/master/doc/fil...
Scroll down to "bundle files"
Re: This JPEG is also a webpage
#93This site uses the xmp tag (deprecated in HTML 3.2, removed in HTML5) which I found interesting and had never seen! https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xm... It's similar to the pre tag but doesn't require the escaping. I guess you just have to make sure you don't have a closing xmp tag :)
"User agents must treat xmp elements in a manner equivalent to pre elements in terms of semantics and for purposes of rendering. (The parser has special behaviour for this element though.)" — https://html.spec.whatwg.org/multipage/obsolete.html#require...
Re: This JPEG is also a webpage
#94That's a chipmunk, not a squirrel.
Re: This JPEG is also a webpage
#95A testament to one of the worst decisions in computing history - not to fail displaying a web page with an error message in case it is not a valid HTML document.
I kinda agree, but one has to concede that XHTML has failed for a reason.
I often wonder how different the internet would be if Postel's prescription never gained traction and fail-fast behavior were the norm instead.
Re: This JPEG is also a webpage
#96You can see this in action for yourself on a unix cli: $ curl -o squirrel.html http://lcamtuf.coredump.cx/squirrel/ $ file squirrel.html squirrel.html: JPEG image data, JFIF standard 1.01, comment: " body { visibility: hidden; } .n { visibilit" Open the file in a browser and read the page. Then: $ mv squirrel.html squirrel.jpg Open the renamed file in a browser and only the image appears. I'm not sure what the securi…
Re: This JPEG is also a webpage
#97Earlier quoted context omitted.
Good catch -- thank you! Imported this from an older blog and must've lost that code block somehow.
Looks like some non-ascii characters didn't make the jump to hyperspeed, either, unless your friend really is named Nicolás Alvarez
Re: This JPEG is also a webpage
#98Earlier quoted context omitted.
Yeah, imagine if processors gave best effort to processing binaries... what could possibly go wrong :/ The decision to allow this was made early and the liberal accept/strict transmit paradigm has in general made the web a mess. On the plus side, the consistent failure of browser vendors to apply strict controls to input means that as an application security person I will probably never be out of work :D Even though…
> as an application security person I will probably never be out of work How many security flaws are the result of malformed HTML?
To take this article as an example, according to the HTTP specification, the `Content-Type` header is supposed to have the final say in what media type is being served. Internet Explorer decided it would be better to use heuristics. I think the idea was that if a web host was misconfigured, rather than have the web developer fix their bug, it would try to guess its way out of the error.
Which kinda worked. The problem was, it opened it up to abuse. If you had a web host that allowed untrusted people to upload images (e.g. profile photos), you could construct an image that tricked Internet Explorer into thinking that it was an HTML document, even if the server explicitly told clients that it was an image. The main difference between images and HTML, of course, is that HTML can contain JavaScript, which would now execute in the security context of your web page.
So all of these web hosts, thinking they were only giving people the ability to upload images, were now letting people execute JavaScript on their domain – simply because Internet Explorer tried to be lenient.
The workaround ended up being forcing downloads with `Content-Disposition` headers instead of displaying inline. That's why, for example, visiting the URL of an image on Blogger directly triggers a download instead of showing the image.
Other examples that spring to mind:
Netscape interpreting certain Unicode characters as less than signs. People were correctly escaping `Browsers ignoring newlines in pseudo-protocols. Want to strip `href="javascript:…"` out of comments? No problem… except some browsers also executed JavaScript when an attacker placed a newline anywhere within the `javascript` token.
Being lenient in what you accept has caused security vulnerabilities over and over again and there's no reason to think that it will stop now.
Re: This JPEG is also a webpage
#99Re: This JPEG is also a webpage
#100So in theory, can analytics platforms be compromised so that JPEG tracking pixels could turn into full-fledged sites interfering with the parent page at, say, a bank website? Firing off credentials in the background?
If these tracking pixels are in iframe elements instead of img elements.