https://kotlinlang.org logo
Join Slack
Powered by
I'm playing around with server/backend dev. mostly...
# random
c
I'm playing around with server/backend dev. mostly with ktor at the moment. i basicallty just generated a project and am outputting a raw string of json. I didn't update the headers to specify json even though it does return json. just out of curiosity, would most things still work fine (like a consuming app or web app)? or are response content type headers like critically important to the client?
e
It depends, but it's usually a good decision to send back the correct response headers.
c
yeah. i definitely will update it. but was just kinda curious if anyone more experienced with backend dev just kinda knew if it like breaks everything or what.
i think one difference i can notice is that it looks like chrome will render json as monospaced (i dont have any json plugins or anything)
which is sorta interesting
but not sure if my eyes are deceiving me
kinda just fascinated by backend dev hoenstly. ive never done it. and its kinda cool to just throw a service up that does stuff. 😅
➕ 1
i guess ive been in android land too long
e
I think it kind of puts you in undefined territory so there's no telling what might happen since it depends on the implementation
👌 1
e
browsers have had varying implementations of content type sniffing
c
yeah. thats what it seems like. my first task i suppose is to figure out how to return proper headers with ktor. lol. should be a piece of cake. but anyway. im havin fun. is this what not being burnt out feels like? lmaoooo
e
which has long been a source of security issues on the web so you should avoid it
👍 1
c
wait ...? are you saying that i shouldn't set content type headers, or are you saying that i shouldn't supply the "wrong" content type header?
e
you should always send the correct mine type and never allow the client to guess
👍 1
c
gotcha. TIL. lemme add it to the list of stuff to read. thanks
if anyone else is following along. to update headers in ktor you can update the response with a param of contentType = ContentType.Application.Json or contentType = ContentType.parse("application/json")
s
„Content Sniffing“, nice… finally I have a word for detection by magic number. 🙂 It really has its limits. While some formats like JPEG & PNG have proper magic numbers, a lot don’t have that. For instance many photo RAW formats based on TIFF just have a TIFF magic number and tools need to look for specific byte values in specific places to guess if it’s a NEF, ARW, DNG or just a regular TIFF. But of course this is only applicable for binary formats. But it lets me wonder why JSON does not have a short identifier string. HTML could have a doctype header to identify, but this is also optional AFAIK. So yes, sending proper mime type seems to be obligatory.
e
it's even worse when you also have to do charset detection and some formats contain executable code (e.g. html, svg, and pdf all can contain js)
👀 1
e.g. an attacker just has to smuggle enough rubbish into a text field to cause that site's json api to be interpreted as a page with code to exfiltrate private user data
👍 1
that is why you need to disable content sniffing across your whole domain
s
Yes, and all this content sniffing implementations may vary and conclude to different formats. While magic number detection is not too bad the other methods seem to be very flaky.
e
some json-based formats do require a specific prefix (such as JWT) but generally… since they're not executable the danger isn't so great
👍 1
s
Reminds me a lot of Internet explorers quirks mode. So something that was meant to deal with bad HTML implementations, but actually widespread them, because devs did not notice their errors. I’m always in favor for strict modes and fail fast. With Kim I have the same problem. The established metadata readers ExifTool & Exiv2 compensate a lot of errors, so there are a lot of faulty metadata writer implementations that may caused by devs even not noticing their mistakes (because tested with ExifTool). If you write a metadata reader reading strict according the specs you see how bad it really is. 😄
c
"that is why you need to disable content sniffing across your whole domain" oooh. any links to that?
e
the mdn link above
😍 2
s
So I’m not sure if Postel‘s law “Be conservative in what you send, be liberal in what you accept.” was the best idea overall.
Maybe it should have been a „be always strict“
e
s
Nice to see others noticed the problem, too 😄
e
but yes, it was something that was "obviously correct" back in the early days of computer networking, but is leaning towards "obviously incorrect" now
s
We devs should really stop doing that, but I’m not sure if we can turn the boat around. To not fall behind existing metadata reader implementations I needed to add code to Kim to compensate faulty metadata like ExifTool does, because there are by now millions of faulty files people expect to be read. Some cameras even produce broken JPG.
And we know how well Operas „be strict“ worked out of for them back in the browser war days
„Fail Fast and Hard“ as the RFC by Mozilla suggests is what I think, too.
5 Views
Open in Slack
PreviousNext
Powered by