SQL Injection Protection

[Hypertext]

Can somebody share there clean classes with me. I have quite a few things i need validating, and right now it's just at mysql_real_escape_string, it needs to process html though. Thats the only drawback, thanks!

[Agnostic Bear]

uhh, forget that apparently this wysiwyg editor is absolutely stupid, just use this:

http://pastebin.com/m2d7e3fd9

[Hypertext]

ty much

[QuickScriptz]

The link Dan posted will work just fine but could you not/wouldn't it be wise to use that in conjunction with some other string replace queries (eg. SELECT FROM, UPDATE, DELETE, etc.)?

[Agnostic Bear]

The link Dan posted will work just fine but could you not/wouldn't it be wise to use that in conjunction with some other string replace queries (eg. SELECT FROM, UPDATE, DELETE, etc.)?

Not really, with ''s out of the question any well formed SQL query wont have problems like that, I stopped removing stuff like that ages ago.

[Insedated]

Test the divs.

[Hypertext]

Who the heck are you? Oh Ivake, ok.

[Navicat]

Test the divs.

I have to agree, that was funny.

Just addslashes?

[Hypertext]

what about mysql_real_escape_string and htmlentities and all that jazz.

[Navicat]

You can use mysql_real_escape_string, but I advise against it.

htmlentities has nothing to do with HTML injection.. that changes ^&$&U^& and all those symbols to their HTML version.

[Tomm]

Actually I recommend you DO use mysql_real_escape_string. One diffrence between mysql_real_escape_string and the `standard` add slashes function is that the mysql_real_escape_string take account of the current character set used in the MySQL database. While its unlikely, your end user may be using a diffrent character set to the one you originaly designed for thus rendering your script vulnerable to SQL injection. Also you should also remember to take into account magic quotes as the data may already be escaped and by escaping it again you effectly corrupt the data.


uhh, forget that apparently this wysiwyg editor is absolutely stupid, just use this:

http://pastebin.com/m2d7e3fd9


You can use mysql_real_escape_string, but I advise against it.

htmlentities has nothing to do with HTML injection.. that changes ^&$&U^& and all those symbols to their HTML version.

[Navicat]

Actually I recommend you DO use mysql_real_escape_string. One diffrence between mysql_real_escape_string and the `standard` add slashes function is that the mysql_real_escape_string take account of the current character set used in the MySQL database. While its unlikely, your end user may be using a diffrent character set to the one you originaly designed for thus rendering your script vulnerable to SQL injection. Also you should also remember to take into account magic quotes as the data may already be escaped and by escaping it again you effectly corrupt the data.
I run into that the other day, fixed it with:



if (! get_magic_quotes_gpc ()) {
$var = addslashes ( $var );
}


I never thought about the char set, I just add slashes then pass it through an input filter.

[Hypertext]

Not too much need for tooo much validation on my part, how do I limit characters, I want to limit to like just a-z, 1-9, ',./;&$%@!()*" That's the sort of stuff i think of as dangerous, I don't use magic quotes tbh, I have ALOT of validation on the login, but I'm talking about inside, just so as to not corrupt the data, like I was doing a form, inside a form, which just closed the textarea element and screwed it all up, so on that note, all I need is addslashes and mysql_real_escape_string() if I want it?

[Navicat]

All I usually do is addslashes in input, stripslashes on display.

[Hypertext]

Okie dokie then, I'm making a site management system ;)

Wait, I.e.:

$input = addslashes($_POST['input']);

viewing:

$output = stripslashes($row['input']);