451–460 of 463 posts
Earlier quoted context omitted.
There is a whole sub-field of software security dedicated to retrieving information from SQL injections that don't directly return results. This is not a plausible objection.
Well, again, you make your attack and you retrieve the schema. Why did you do that?
Some may use their newfound education for good while others use it for evil, as with any education.
Earlier quoted context omitted.
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…
That is good. I have long believed that "if it is not tested, it is broken"
Kurt posted this to troll me. Just know my audience here was, mostly, non-technical people involved in politics in my local Chicagoland municipality. Permit me a PSA about local politics: engaging in national politics is bleak and dispiriting, like being a gnat bouncing off the glass plate window of a skyscraper. Local politics is, by contrast, extremely responsive. I've gotten things done --- including a law passed…
Man, I remember your & Maciej's effort to get FIDO keys to the campaign staffers, and how depressing that was
Earlier quoted context omitted.
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…
> Actually, yes That is good. I have long believed that "if it is not tested, it is broken"
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.
Earlier quoted context omitted.
There is no way you get Wilmette to change zoning. They've fought with Small Cheval about the size of their sign for like 9 months. I doubt you'd get any village in the NT district to rezone - the Optima project was pulling teeth, everyone is worried about overcrowding NT, which as a single HS is pretty packed now
New Trier can just build another campus like they did for freshmen.
Earlier quoted context omitted.
I don't want to take away any steam from your sails but giving bad information in regards to case law shouldn't be taken lightly. Your "expert witness" did you a disservice. Schema is very much a critical field in terms of AuthZ privileges. Just knowing the structure is not far off from knowing the max entropy a password may hold. In regards to InfoSec, table structure is the recon phase which limits effort and minim…
> Just knowing the structure is not far off from knowing the max entropy a password may hold Not if the password is hashed, as it should be. Unless the schema somehow indicates that it uses a hash algorithm such as bcrypt that has a maximum password length. And even then, if they pre-hash the password, the password itself could have more entropy than that. And if there is a maximum password length, then you can proba…
Look at how RSA is implemented. Look at the intentional obscurity of S tables and lack of detailed information.
There is a reason information is withheld. DB schema is just that, information that increases increases the threat.
And running a DB on someone's infrastructure doesn't necessarily give you access. You need to read up on AuthN and AuthZ.
If you listed an open source example I'd take the time to poke holes in your strawman argument but you honestly just need to take a step back and think about what you are really arguing.
Do you really think not having the schema is as inconsequential as having the schema when attacking something? I mean what is the first step most folks do in reverse engineering? I honestly can't believe I'm having to say this.
Earlier quoted context omitted.
> 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 tru…
Earlier quoted context omitted.
It happens from time to time. https://www.theverge.com/2017/10/19/16503076/oracle-vs-googl... ( https://news.ycombinator.com/item?id=15834800 42 comments) > These days, he often looks for some kind of STEM background for the IP desk. It’s not necessary, but it helps. Bill Toth, the IP clerk during Oracle v. Google, didn’t have a STEM background, but he told me that the judge had specifically asked him to take a compu…
I'm the referenced Bill Toth. Just thought I'd mention the funny fact that in private practice I've actually argued about the significance of database schema (less for security reasons, more for analyzing the outputs of the database).
One of the things that this also reminds me of is the impression that "learn to code" meant "everyone should be a software developer" when your experiences demonstrate a "learn to code" was part of "becoming a better legal professional".
Do you have other examples of how learning to code improved your abilities as a legal professional?
Earlier quoted context omitted.
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 tru…
Is the parser available for review?