Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This JPEG is also a webpage

lcamtuf.coredump.cx

Post reply on HN
Print view View original

111–120 of 236 posts

Re: This JPEG is also a webpage

#111

Post by alanh »

EGreg wrote: post #99

Can someone explain in simple English how this works?

1. HTML is very forgiving. HTML also provides a comment mechanism between which anything will be ignored from a browser perspective.

2. JPEG also allows for comments and other embedded metadata which won't show up in the displayed image.

3. Start the file with a JPEG header and metadata section, then switch between HTML and JPEG using the comment functionality mentioned above

Essentially!

"But wait, why is it shown as an image in one context and as a web page in another?"

The answer is in the question: Context. If you expect a JPEG you will get a JPEG, and same for HTML.

Re: This JPEG is also a webpage

#112

Post by sctb »

gkya wrote: post #60

C'mon, don't be so stingy, give him a Ben at least :) _____________________________________________________________________ | | | =================================================================== | | |%/^\\%&%&%&%&%&%&%&%&{ Federal Reserve Note }%&%&%&%&%&%&%&%&//^\%| | | |/inn\)===============------------------------===============(/inn\| | | |\|UU/ { UNITED STATES OF AMERICA } \|UU/| | | |&\-/ ~~~~~~~~ ~~~~~~~~~~…

We detached this comment from https://news.ycombinator.com/item?id=12262995 and marked it off-topic.

Re: This JPEG is also a webpage

#114

Post by JimDabell »

dpark wrote: post #108
JimDabell wrote: post #98

Earlier quoted context omitted.

Malformed HTML? None. Browsers attempting to be lenient in what they accept? Loads. 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…

> 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 prob…

> I think this is a fair bit different than being lenient on HTML interpretation.

It's not. There are two areas where the leniency was a problem here. Firstly, the leniency in rendering one media type as a completely different media type because the browser heuristic thought it was being lenient. Secondly, the leniency in parsing HTML out of an image file – you can't do that with valid HTML.

> Accepting malformed HTML doesn't seem to pose much of a problem.

I've literally just given three specific examples of it causing security vulnerabilities.

> This doesn't sound like being lenient. This just sounds like a bug.

No, it was intentional. It was specifically Unicode characters that looked like less than and greater than signs, but weren't.

> I don't understand the scenario being described here.

Somebody noticed that href="java\nscript:…" wasn't being parsed as JavaScript, and it was causing some malformed pages to fail to work properly. Rather than let it fail, they tried to fix it by stripping out the whitespace, and caused a security vulnerability.

If these three examples aren't enough, take a look at OWASP's XSS filter evasion cheat sheet. There's plenty of examples in there of lenient parsing causing security problems:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...

Re: This JPEG is also a webpage

#115

Post by throwanem »

oldmanjay wrote: post #95
arcatek wrote: post #45

Earlier quoted context omitted.

I kinda agree, but one has to concede that XHTML has failed for a reason.

XHTML failed because doing the old, broken, tag-soupy mess still worked exactly as well from the user perspective. You just can't get people to work harder for invisible benefits. In a sense, it's a reason, but it doesn't mean that tag soup is a good thing. I often wonder how different the internet would be if Postel's prescription never gained traction and fail-fast behavior were the norm instead.

It would probably be a lot smaller!

Re: This JPEG is also a webpage

#117

Post by amavisca »

gsnedders wrote: post #93
amavisca wrote: post #54

This 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 :)

Removed? "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...

I was just going off what the MDN page said about it being removed in the HTML5 standard. It looks like WHATWG just has a "living standard" and W3C still uses the versioning, so it's probably removed from W3C standards. I'm not too familiar with the reality of these standards.

Re: This JPEG is also a webpage

#119

Post by throwanem »

michaelmior wrote: post #109
deathanatos wrote: post #16

Earlier quoted context omitted.

> I wonder what are the security implications of that. At least any terminal escape sequence can be executed if you run `file` on a JPEG, it seems, since this: curl -s 'http://www.imagemagick.org/image/fuzzy-magick.png' | convert - -set comment "$(printf 'asdf\x1b[1;31mTest?\x1b[0m hmm')" test2.jpg file test2.jpg Results in red text on my terminal for me. (It also results in file writing a 0xff 0xdb to the terminal,…

I just get the following so it seems like my version of file has been patched to handle this case. test2.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 72x72, segment length 16, comment: "asdf\033[1;31mTest?\033[0m hmm", baseline, precision 8, 320x85, frames 3

Same here with file(1) version 5.22 from the Debian jessie package repo. I'd be interested to know in which versions this kind of thing actually works.

Re: This JPEG is also a webpage

#120

Post by gkya »

sctb wrote: post #112
gkya wrote: post #60

C'mon, don't be so stingy, give him a Ben at least :) _____________________________________________________________________ | | | =================================================================== | | |%/^\\%&%&%&%&%&%&%&%&{ Federal Reserve Note }%&%&%&%&%&%&%&%&//^\%| | | |/inn\)===============------------------------===============(/inn\| | | |\|UU/ { UNITED STATES OF AMERICA } \|UU/| | | |&\-/ ~~~~~~~~ ~~~~~~~~~~…

We detached this comment from https://news.ycombinator.com/item?id=12262995 and marked it off-topic.

Why? I mean as if the parent was on topic... and this is a little joke, jokes don't kill.
Post reply on HN