31–38 of 38 posts
It seems that PostgreSQL is missing from this cheat sheet. Does anyone know why?
Hey Esnard! I'm one of the people who worked on the wiki at NetSPI. We're planning on adding more DBMSs in the near future. Was there anything specific you're looking for about PostgreSQL?
The only successful SQL injection attack I've encountered in the wild was interesting, because the injection point had no visible output. But by injecting timing calls (eg "SLEEP()") and appropriate conditionals, the attacker was able to extract a few bits of information each request. Their script executed some tens of thousands of requests, and they managed to extract all the table names, and start to extract data f…
One time I decided to test his inputs, and surprisingly- one of those inputs contained a vulnerability in that it allowed you to post ANY text script or characters without sanitization. I quickly hobbled together a cookie-stealing script and proved how serious this hack was by stealing the password of an alternate dummy account just by visiting my poisoned user/info page.
I told my friend about it, and it took him a surprising long amount of time to actually get around to fixing it.
Earlier quoted context omitted.
I'm getting SSL errors on that link: it is presenting GitHub's wildcard certificate which obviously doesn't match. The site is accessible as plain http (or https if you skip the warnings, of course).
I thought that was sketchy too but it occurred to me that they probably are hosting this site with github but are using their own domain name. sqlmap.org turns out to me an A record for an IP address owned by github.
That is exactly what they are doing, and in itself this is not at all a problem.
But presumably the link worked for the original poster, so either there is a dynamic DNS problem (we are being sent to an address that serves the .github.com certificate an not the "right" one but he was sent somewhere that does have a certificate for that name) or* someone is resigning content and his machine is set to trust their CA certificate. This latter cause could be normal/expected (his company having a MiTM policy for regulatory monitoring reasons) or his machine could be cracked by an external entity.
Earlier quoted context omitted.
> parameterized queries can (potentially) give better performance. Yep! More accurately, parameterized queries almost always give better performance. The simplest way parameterization helps (and there are many) is query plan caching. When a DB server sees a query for the first time in awhile, it has to turn the SQL text into a query plan ( https://en.wikipedia.org/wiki/Query_plan ). That takes time and resources (lex…
Wow! Thank you so much for the explanation! > I have seen folks add pointless "1 = 1"-type clauses to their text I have seen something like that, too, and I have always wondered if that was just job protection or if there was some arcane reason to it. The code in question was part of a view, though, so it ran unaltered countless of times. That view also contained numerous "1 1" clauses, apparently to disable branches…
> It was the one time I took over someone else's code and felt like swearing.
The one time? Y'all hiring?
Earlier quoted context omitted.
Wow! Thank you so much for the explanation! > I have seen folks add pointless "1 = 1"-type clauses to their text I have seen something like that, too, and I have always wondered if that was just job protection or if there was some arcane reason to it. The code in question was part of a view, though, so it ran unaltered countless of times. That view also contained numerous "1 1" clauses, apparently to disable branches…
I think you hit the most likely reason for the "1 1" clauses: it was basically "commenting out" branches of the query (or something programmatically generated the query in a way that needed to switch branches on and off without changing the query text so much that the query builder would have to understand more SQL syntax). > It was the one time I took over someone else's code and felt like swearing. The one time? Y'…
I was exceedingly lucky, I guess, because except for that hairy SQL view, they were all gems of clarity.
Earlier quoted context omitted.
> parameterized queries can (potentially) give better performance. Yep! More accurately, parameterized queries almost always give better performance. The simplest way parameterization helps (and there are many) is query plan caching. When a DB server sees a query for the first time in awhile, it has to turn the SQL text into a query plan ( https://en.wikipedia.org/wiki/Query_plan ). That takes time and resources (lex…
Wow! Thank you so much for the explanation! > I have seen folks add pointless "1 = 1"-type clauses to their text I have seen something like that, too, and I have always wondered if that was just job protection or if there was some arcane reason to it. The code in question was part of a view, though, so it ran unaltered countless of times. That view also contained numerous "1 1" clauses, apparently to disable branches…
Let's assume you start with "SELECT * FROM ITEMS" like query. Now you're adding the WHERE clause. Do you keep track if you have the WHERE already present? Do you then keep track of if you need the "AND" or if it's the first entry that cannot take the "AND"?
With 1=1 you're guaranteed to have the WHERE clause and you're guaranteed to be able to use AND in your statement.
Do you have a better way?
Earlier quoted context omitted.
Wow! Thank you so much for the explanation! > I have seen folks add pointless "1 = 1"-type clauses to their text I have seen something like that, too, and I have always wondered if that was just job protection or if there was some arcane reason to it. The code in question was part of a view, though, so it ran unaltered countless of times. That view also contained numerous "1 1" clauses, apparently to disable branches…
SQL with 1=1 makes sense to me. Let's assume you start with "SELECT * FROM ITEMS" like query. Now you're adding the WHERE clause. Do you keep track if you have the WHERE already present? Do you then keep track of if you need the "AND" or if it's the first entry that cannot take the "AND"? With 1=1 you're guaranteed to have the WHERE clause and you're guaranteed to be able to use AND in your statement. Do you have a b…
There were two reasons I was mad:
1. Using "1 1" to disable a branch of a WHERE clause is not something I would have done. I would have commented it out. If you are used to this idiom, it might feel like the natural thing to do, but I think commenting it out makes the intention clearer.
2. I understand that queries can get a little convoluted when you start experimenting with them until you get the results you need. It is perfectly natural, and it is how the views I have written started out, as well. But before I put my views into production, I cleaned up the code, removed the parts I did not need or added a little comment to explain why the code was there.
Actually there were three: 3. The entire view was written in such a convoluted way that I was pretty sure the person who had written it was drunk at the time (he was an alcoholic, so this is probably true in the literal sense). When I inherited it, the view had about 700 lines and was mostly unreadable. When I was finished cleaning it up, I had reduced that to about 300 lines. I checked very carefully, but it still gave the exact same results. It still was not pretty, but if I could throw out more than 50% of the original code without affecting the result, you can probably imagine what a mess it was.
When I did firewall/network support for managed hosting customers, the number of customers' custom/vendor apps that were vulnerable (and exploited!) by SQL injection attacks was astounding. Of course the very first thing they said was "but we have a firewall, why can't you ACL it?" Sorry, your Cisco ASA doesn't work that way. It's like people never expected their code to run in a hostile world.