I noticed something odd in my referral data the other day, let me explain:
I have a page that displayes webpages dynamicly from a database like this - www.mysite.com/page.asp?name=255

Each record in my database has a unique variable so the correct page is displayed, the above example is "255" my referral script picks up this data so I know which page has been visited and by which URL. (so whatever someone has typed after the = shows up. OK so I noticed someone had typed this:
www.mysite.com/page.asp?name=0 and ''=''>218' and user>0 and ''='

can anyone tell me what this individual is trying to do? is it a sql injection attack?

My site is not that well coded and any advice about improving security would be much appreciated.

Yep, that's exactly what an SQL injection attack is.
As for improving security, it's a so large field (and almost 4 am here) that I'm sorry to say that either someone else will give you advices, or I'll do later tomorrow...

Thanks for that Tripy, I was wondering what exactly the are trying to do? I keep the content for my website on a database which is readily viewable by anyone who cares to click through my site. I don't keep ANYTHING important on a online database.

Maybe they want credit card numbers you might have, or maybe they want to put something malicious in your database.

This is why MySQL sucks. All versions below 5.02 are begging for SQL Injection.

This is why MySQL sucks.

Bad workmen blame the tools.

If you do not know what your doing the perhaps you should not be doing it or you should bheusing something more developer friendly.

If you scrutinize any input (especially if its going to your DB) then you can catch it and make it friendly.

I find the PDO php-mysql API rather good at using the bindParam to get out of jail nicely however you can do it yourself by simply adding quotes to the input.

Even a simple addslashes would turn
www.mysite.com/page.asp?name=0 and ''=''>218' and user>0 and ''='

into
www.mysite.com/page.asp?name=0 and \'\'=\'\'>218\' and user>0 and \'\'=\'

rendering it rather useless for its purpose.

Ibbo

Originally Posted by ibbo

This is why MySQL sucks.

Bad workmen blame the tools.

Bad workmen choose bad tools.

Originally Posted by ibbo

If you scrutinize any input (especially if its going to your DB) then you can catch it and make it friendly.

The type you spend writing code to scrutinize any and all user input (not a small task) adds no value to your clients, it's just plumbing. Choosing a tool that forces you to spend a great deal of time doing something that adds no value to the project when you could simply choose proper tools from the start is the mark of the bad workmen you're bringing up.

There are many situations where some characters like ' or - are valid and appropriate. You can't just block any input of them, O'Leary, in-the-woods, so your "scrutinize user input" module either has to be very smart, or still leaves holes open.

On the other hand, when you can just save and precompile the SQL in the database and pass only parameter values who can't change the meaning of the SQL code, all of a sudden you don't have to spend weeks writing code to scrutinize your user input, you can just let your data rules govern what's acceptable. And charge your client a fair price, instead of charging them to buy a screw driver and forge a hammer out of it.

Originally Posted by Learning Newbie

This is why MySQL sucks. All versions below 5.02 are begging for SQL Injection.

It is very easy to sanitize values for MySQL queries. Only negligence or ignorance would leave room for SQL injection, and I don't think those are good enough reasons to say that anything sucks.

Originally Posted by frost

It is very easy to sanitize values for MySQL queries. Only negligence or ignorance would leave room for SQL injection, and I don't think those are good enough reasons to say that anything sucks.

Exactly. On top of that, MySQL 5.02 didn't do anything magical to stop SQL injection. Now if you want to talk about the PHP interface to MySQL then maybe he has a point but even then, there's nothing that requires the coder to use parameters and so on, right?