Hacker News Reader

Comment by scott_s | Hacker News Reader

I'm trying to square this with the fact people pointed out downthread, which is that iPhones will automatically convert HEIC images to jpeg from an HTML input form. Perhaps it's the `isAllowedExtension` check? If `e.target.files` is the actual file names on disk (and not whatever temporary file the browser made out of the HEIC file), that would cause a problem.

View on HN

Apparently somebody claims to have been able to change the extension and submit the picture, but got "file corrupted" later:

"Senior Dave Spencer took a demo test before his Calculus AB exam to make sure he understood the process for uploading photos. He Airdropped an iPhone image of his responses to his Mac and tried to convert it by renaming the HEIC file to PNG. Changing a file’s extension does not guarantee that it will be converted, but Spencer was still able to submit the demo test with no problem.

Spencer used the same process on the real exam and thought it went through, but he received an email the next day saying the files were corrupted and that he needed to retake the test."

As someone who started their career in QA and volunteered with IT support for non-technical organizations, this is one of the first test cases I would have thought to try.

Never trust user input!

Frontend validation can never be trusted. It’s only good for giving faster feedback for a nicer user experience. You should always have backend validation.

I’ve seen people do some weird stuff before because the majority of users don’t really understand much about file types. Users rename file extension all of the time thinking it’ll magically convert a file into something that can be opened by their program of choice.

This is just poor QA by the College Board.

Anyone who says that young people are better with computers these days needs to keep this paragraph on file.

I can’t really blame the college board for this kind of mistake. Like would he assume that taking a .docx and renaming it to .pdf converts it?

On the other hand, I think there's an argument to be made software should ignore file extensions whenever possible. Is really that hard for the backend to check if the file starts with "\xFF\xD8\xFF\xE0\0\x10JFIF\0\1" or "\x89PNG\r\n\x1A\n"? That would have caught this problem.

Yes, just hardcode what is hopefully the magic bytes for the formats we expect, what could possibly go wrong /s

The biggest joke here is that this wouldn't have helped the students either. I don't think any of them will pass the "there is a minute left on the timer and the website tells you your picture isn't JPEG or PNG" challenge.

I did some more research and it looks like I got the one for JPEG wrong, so maybe you have a point.

That anecdote is inline with my explanation: the student manually changed the file extension on disk, then uploaded that. That would pass all of the checks, but it would still be in the wrong format, as manually changing the file extension does not cause a conversion to take place on disk, and that probably prevents the automatic conversion of HEIC to jpeg the iPhone itself does on such input fields.

all the checks - a proper check would be reading the contents and parsing the image.

Yes, but that's not what the written code does.

I think the issue is that accept is specified only with extensions rather than mime types.

I wondered that, too, but I couldn't find any HTML documentation that blessed one form as superior to the other. And I would be surprised if Apple automatically converted images for "accept=image/jpg" but not "accept=.jpg".

Here's the spec:

https://html.spec.whatwg.org/multipage/input.html#attr-input...

> Authors are encouraged to specify both any MIME types and any corresponding extensions when looking for data in a specific format.

> User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.

Reply on news.ycombinator.com