Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQL injection search

github.com

Post reply on HN
Print view View original

91–100 of 114 posts

Re: SQL injection search

#91

Post by astrodust »

ratsbane wrote: post #80
astrodust wrote: post #23

Earlier quoted context omitted.

That's an example of hazardously bad programming practices. You're one mistake away from complete disaster. You should be sure that it takes more than one mistake to expose you to that sort of risk. Casting to int is not a general purpose escaping system, and further, if you miss even one of these your entire application can be trashed. Using mysql_query at all is a sign there's something severely wrong with your app…

There is an opposing viewpoint, i.e. if you actually need an int, casting to int is one of the most reasonable ways of getting it.

In this case, you don't "need an int", you need a value that's safe to put in a database query.

If you're inserting a value in a database, you always, always, always use the proper escaping mechanism. No exceptions.

That's why using a library with a reliable, well-defined, easy to use escaping system is absolutely imperative.

Re: SQL injection search

#92

Post by ratsbane »

astrodust wrote: post #91
ratsbane wrote: post #80

Earlier quoted context omitted.

There is an opposing viewpoint, i.e. if you actually need an int, casting to int is one of the most reasonable ways of getting it.

In this case, you don't "need an int", you need a value that's safe to put in a database query. If you're inserting a value in a database, you always, always, always use the proper escaping mechanism. No exceptions. That's why using a library with a reliable, well-defined, easy to use escaping system is absolutely imperative.

In any case the real problem with this line of code is not the int cast, it's that it's using a GET request to delete a record.

Re: SQL injection search

#94

Post by smsm42 »

DanBC wrote: post #47
diminoten wrote: post #38

There is a huge need in the space for a well marketed quality assurance contractor who can find problems like this and fix them. "We found these issues, and we can fix them all. Pay us for finding them or pay us some more for fixing them, too." sort of thing. Why don't you see QA shops popping up like this?

That feels a bit like "We found these vulnerabilities. You should pay us. It would be a shame if anything happened to your website "

If you do it right, it won't. Many security audit companies are asked to do test audits, and I've seen security audit contracts starting with responsible disclosure of vulnerabilities. Of course, certain amount of trust is necessary so the sides have to behave in a way that is conductive to the establishment of the trust.

Re: SQL injection search

#95

Post by porker »

pointyhats wrote: post #50
diminoten wrote: post #38

There is a huge need in the space for a well marketed quality assurance contractor who can find problems like this and fix them. "We found these issues, and we can fix them all. Pay us for finding them or pay us some more for fixing them, too." sort of thing. Why don't you see QA shops popping up like this?

There are loads of companies already doing this, at least in the UK. They find the holes and you fix them.

List please? I've tried Googling and not found them.

Re: SQL injection search

#96

Post by smsm42 »

astrodust wrote: post #23
PanMan wrote: post #13

Nice example, but not all are insecure. For example, the second one here is: $result = mysql_query('DELETE FROM saves WHERE id = '.(int)$_GET['delete']);

That's an example of hazardously bad programming practices. You're one mistake away from complete disaster. You should be sure that it takes more than one mistake to expose you to that sort of risk. Casting to int is not a general purpose escaping system, and further, if you miss even one of these your entire application can be trashed. Using mysql_query at all is a sign there's something severely wrong with your app…

Depends on the purpose of the code. If it's one-page script then it's fine. If it's the context of the bigger app, mysql_query is probably a problem.

Re: SQL injection search

#97

Post by brokenparser »

hcarvalhoalves wrote: post #79
postfuturist wrote: post #62

This isn't a search for SQL injection, its a search for a couple things that you often find in older PHP code that is generally hacked together and likely to have SQL injection vulnerabilities for historical and cultural reasons. However it's perfectly easy to avoid SQL injection even using these things. $id = mysql_real_escape_string($_GET['id']); $res = mysql_query("SELECT foo FROM bar WHERE id='$id'"); That may be…

"mysql_real_escape_string" is the silliest function name ever. I assume there is a "mysql_escape_string" function that doesn't do what you expect it to do?

Surprisingly, no one mentioned that mysql_real_escape_string still fails to properly escape a string when the character set has been changed using a SET NAMES or SET CHARACTER SET query. Never mind the big yellow warning sign in the manual.

The search goes like this: https://github.com/search?q=mysql_query+%22SET+NAMES%22+mysq...

Re: SQL injection search

#98

Post by jarofgreen »

martinml wrote: post #16
PanMan wrote: post #13

Nice example, but not all are insecure. For example, the second one here is: $result = mysql_query('DELETE FROM saves WHERE id = '.(int)$_GET['delete']);

It still doesn't check if a particular id belongs to the user, so you can delete all the items in the table. But I agree that's different kind of problem :)

Your assuming it's a system where data belongs to set users - maybe any user is allowed to delete any piece of data.

Re: SQL injection search

#99

Post by jarofgreen »

orangethirty wrote: post #24

Looking around I found a simple CMS sold to small online stores. Through their links you can find a listing of their customers (people who use their CMS). Problem is the CMS is open to SQL injection everywhere. If a script kiddie found this info they could take down a lot of online stores. Not good.

Did you tell them?

Re: SQL injection search

#100

Post by jarofgreen »

smsm42 wrote: post #94
DanBC wrote: post #47

Earlier quoted context omitted.

That feels a bit like "We found these vulnerabilities. You should pay us. It would be a shame if anything happened to your website "

If you do it right, it won't. Many security audit companies are asked to do test audits, and I've seen security audit contracts starting with responsible disclosure of vulnerabilities. Of course, certain amount of trust is necessary so the sides have to behave in a way that is conductive to the establishment of the trust.

> I've seen security audit contracts starting with responsible disclosure of vulnerabilities.

But was that

"We found a hole, here it is." "Thanks! Your good at that" "I know, want to hire us?"

or

"We found a hole. Pay us and we'll tell you."

Because those are very different approaches.

Post reply on HN