4 ms·
Strongly disagree here because JSON can come from untrusted sources and this has security implications. It's not the same kind of problem that the bloat article
by klysm 1y ago
Strongly disagree here because JSON can come from untrusted sources and this has security implications. It's not the same kind of problem that the bloat article discusses where you just have bad contracts on interfaces.
- leptons 1y agoJSON does not necessarily come from untrusted sources if you control the entire system. Not everything needs to be absolutely 100% secure so long as you control the system. If you are opening the system to the public, then sure, you should strive for security, but that isn't always necessary in projects that are not processing public input. Here's an example - I once coded a limited JSON parser in assembly language. I did not attempt to make it secure in any way. The purpose was to parse control messages sent over a serial port connection to an embedded CPU that controlled a small motor to rotate a camera and snap a photo. There was simply no way for any "untrusted" JSON to enter the system. It worked perfectly and nothing could ever be compromised by having a very simple JSON parser in the embedded device controlling the motor.
- userbinator 1y agoYou probably didn't control the other end, as otherwise you would've used something more sane than JSON?
- leptons 1y agoI controlled both ends. There is nothing "insane" about JSON. It's used far and wide for many purposes. The system sending the JSON was based on Nodejs, so it was pretty natural to use JSON. And I did it with JSON just because I wanted to. I'd have had to invent some other protocol to do it anyway, and I didn't feel like reinventing the wheel when it was quite simple to write a basic JSON parser in assembly language, which is what I am comfortable with on the embedded system (been coding assembly for 40 years).
- userbinator 1y agoFor something that simple I'd choose a custom binary protocol or something like ASN.1 instead of JSON. It's easier to generate from a HLL and parse in a LLL (I've also been writing Asm for a few decades...)
- leptons 1y agoI've done plenty of custom binary protocols before. I can't say they were any better or easier to deal with. I also can't say that the "parser" for a binary format was any easier than a simple, limited JSON parser. For this specific project I chose JSON and it worked perfectly. Sending JSON from the embedded CPU was also really simple. Yes, there was a little overhead on a slow connection, but I wasn't getting anywhere near saturation. I think it was 9600 bps max on a noisy connection with checksums. If even 10% of the JSON "packets" got through it was still plenty for the system to run.
- johnisgood 1y agoI would love to use ASN.1 if other programming languages would match up to Erlang's ASN.1. :(
- Yeask 1y agoEven if is not popular here .NET does support ASN.1, not sure if at the same level as Erlang.
- cozzyd 1y agoIt depends on the use case. JSON has a lot of tooling making it convenient in a lot of cases
- boramalper 1y agoUntrusted doesn’t always mean adversarial IMO, even a bitrot can invalidate your entire input and possibly also trigger undefined behaviour if you aren’t prepared to handle that.
- interstice 1y agoMassively agree. Remember this thinking being everywhere with databases back in the day, not every text field is hooked up to a Wordpress comment section.
- ghurtado 1y ago> Not everything needs to be absolutely 100% secure so long as you control the system. Isn't that a bit like saying "you don't have to worry about home security as long as you are the only person who has the ability to enter your house"?
- Yeask 1y agoNot at all.
- Mogzol 1y agoI mean yeah if you're truly the only person that has the ability to enter your house then why should you worry about home security? Nobody else has the ability to get in.
- ncruces 1y agoSure. I don't password protect my (Android) TV like I password protect my (Android) phone, despite both of them allowing authorized access to the same Google accounts, because if someone entered my house I have bigger things to worry than them using my TV.
- johnisgood 1y agoI agree. I knew that the JSON is not going to change, so I wrote a 10 lines long parser for it. It is not a JSON parser by any means, but it parses properly what I need it to.
- cozzyd 1y agosscanf as a parser definitely has its uses
- johnisgood 1y agoI used strchr() in a function I named get_pair(). So, all in all, I used strchr() and strcmp() only!
- Brian_K_White 1y agoPublic facing interfaces are their own special thing, regardless if json or anything else, and not all data is a public facing interface. If you need it, then you need it. But if you don't need it, then you don't need it. There is a non-trivial value in the smallness and simplicity, and a non-trivial cost in trying to handle infinity problems when you don't have infinity use-case.
- klysm 1y agoThis is a serialization library. The entire point is to communicate with data that's coming from out of process. It should be safe by default especially if it's adding a quick check to avoid overflow and undefined behavior.
- Brian_K_White 1y agoIncorrect assumption. If you are reading data from a file or stream that only you yourself wrote some other time, then it's true that data could possibly have been corrupted or something, but it's not true that it's automatically worth worrying about enough to justify making the code and thus it's bug surface larger. How likely is the problem, how bad are the consequences if the problem happens, how many edge cases could possibly exist, how much code does it take to handle them all? None of these are questions you or anyone else can say about anyone else's project ahead of time. If the full featured parser is too big, then the line drawing the scope of the lightweight parser has to go somewhere, and so of course there will be things on the other side of that line no matter where it is except all the way back at full-featured-parser. "just this one little check" is not automatially reasonable, because that check isn't automatically more impoprtant than any other, and they are all "just one little checks"s. The one little check would perevent what? Maybe a problem that never happens or doesn't hurt when it does happen. A value might be misinerpreted? So what? Let it. Maybe it makes more sense to handle that in the application code the one place it might matter. If it will matter so much, then maybe the application needs the full fat library.
- Yeask 1y agoYou would use this for parsing data you know is safe. Using a "tiny library" for parsing untrusted data is where the mistake is. Not in OP code.
- president_zippy 1y agoIt's too bad this header-only JSON library doesn't meet your requirements. How much did you pay for your license to use it? I'm sure the author will be happy to either ship security fixes or give you a refund. You should reach out to him and request support.
- account42 1y agoThere is only a problem with these checks here if you pass along arbitrarily large JSON strings as all of these counters are advanced at most once per input byte. If you don't limit the input to reasonable sizes you have a potentional denial of service problem even without the UB so you should be checking for reasonable sizes which depend on your application but are likely much lower than the 2^31-1 bytes the library can safely parse.