Comment by wglb
2 months ago
The parser isn't shown there, so it isn't clear what would happen with weird input.
Have you had anyone do a penetration test on it?
2 months ago
The parser isn't shown there, so it isn't clear what would happen with weird input.
Have you had anyone do a penetration test on it?
Well, I would suppose that you pick an existing parser that is well tested and battle proven. No need to write your own. For most languages those parsers already exist. I would also not write my own json parser, so why would I do that for SQL, which is even more complex?
But in any case, the weird input would just be rejected. In my case I'd get a "parser error" from my library and then wrap it into my own "query not supported" error and return that as a 400.
> Have you had anyone do a penetration test on it?
Actually, yes. The pen-testers were surprised about the technique but did not find any problems with it.
> Actually, yes
That is good. I have long believed that "if it is not tested, it is broken"
I mean, there are still different reputations for certain techniques. And SQL sanitization has a bad reputation for good reasons. But SQL parsing, whitelisting and then reserialization still has a bad reputation in the eyes of many people, but that's only because they don't understand the difference between the two.
No one would say "parsing json is broken if it's not tested" right? Then for SQL the same would be true.
So if you were to use this technique in a business that doesn't mandate regular pentests, it would not change how well the technique works and how secure/safe it is.
2 replies →