Unauthorized db inputs

[Clinton]

Ok, so everyday when I check my users list, the only db where you can insert something (as you are registering) without having to login, and there's a bunch of gibbrish as if somebody signed up but played around. But when somebody signs up I get an email approving or denying them yet I don't get any e-mails. It was happening repeatedly and I thought I blocked the IP address. I'm pretty sure it's a bot. If you google '[email protected]' you will see it happens everywhere.

 

1) How exactly is this happening?

2) How do I prevent it from happening?

[webent]

Have you looked into possibly using CAPTCHA?

[rarebit]

Do you escape data before putting it into the db?

[Clinton]

No, I have not looked at either but I certainly will.

 

What exactly is this person looking for by doing this?

[webent]

Used to happen to me all the time, so

What exactly is this person looking for by doing this?

 

Just to drive you bonkers! LOL

[Clinton]

LoL. Did CAPTCHA solve your situation or did you use the escape string as well?

[rarebit]

Just see them as a teacher, cracking your site before it really matters (like when theres sensitive data or payment details, etc)

 

also look for xss on wiki, that'll also lead you elsewhere...

[webent]

Yeah, I just create one of these bits for every variable being passed into the form processor, put it at the top, prior to any processing...

 

$from=$_POST['lname'];
if (eregi("\r",$from) || eregi("\n",$from)){
die("Why ?? ");
}

 

This is by no means sufficient enough for anything that requires higher security.

 

 

[Clinton]

Thanks rarebit, I definitely do. That's why I'm here. :-)

 

Webent, I'm looking in the manual about eregi, also ereg, and it says that it searches the string for a regular expression. How does it know what a regular expression is and how does that really stop it from doing anything? Just curious. :-)

 

Appreciate the help. I've never had to really worry about this but I putting something together that I don't need others looking into. :-)

[webent]

It just stops injections...

[Clinton]

OK, i'll give it a shot.

 

RAREBIT, I was looking into the mysql_real_escape_string and it looks like it relies on get_magic_quotes_gpc which is discontinued in 6.0 :-|

[rarebit]

what if this is from a textarea?

if (eregi("(\r|\n)?",$from))

and it doesn't stop injections, because there not used to jump out of the statement...

[rarebit]

I generally ignore magic quotes because I know my site doesn't have them turned on but you could add then to the following function which I use to get vars (there are also ones for GET & POST specifically)

 

function get_REQUEST($name)
{
$sret = NULL;
if (isset($_REQUEST[$name]))
{
	$sret = $_REQUEST[$name];
	$sret = mysql_real_escape_string($sret);
}
return $sret;
}

 

What magic quotes does is basically the same, but just a little more (and not required), but if you were then to escape the string, the escapes would also get escaped (if I remember correctly)

[Clinton]

Ok, not I am primarily using POST on my site. Those are not cookies right? They are just being stored on the server being passed from page to page?

 

If I was to use that script below would I just replace REQUEST with POST?

[rarebit]

Yeah, replace REQUEST with POST, or if COOKIES, change it to those... any form of user input, it's all hackable...

[webent]

rarebit, would passing it via a session array be more secure, then only retrieving that data from the session array?

[Clinton]

Ok, will do. And I use that for every variable being POSTed, correct?

 

Also, I read this:

 

This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSS attacks. Converting < and > to < and > is also suggested when it comes to script output. Remember XSS holes can be damaging and costly to your business if abused. Often attackers will disclose these holes to the public, which can erode customer and public confidence in the security and privacy of your organization's site. Filtering < and > alone will not solve all cross site scripting attacks. It is suggested you also attempt to filter out ( and ) by translating them to &#40; and &#41;, " to &#34;, ' to &#39, and also # and & by translating them to &#35 (#) and &#38 (&). 

 

Is this saying that everywhere I have " in my website, such as a query statement that I should replace it with "?

[rarebit]

http://uk3.php.net/manual/en/function.htmlentities.php will help with xss.

 

Session variables are stored on the server, just the session cookies is stored of the client machine... (so no they don't need to be cleansed, other than the seesion id itself)

[Clinton]

Could you post your entire code for this:

 

function get_POST($username)
{
$sret = NULL;
if (isset($_POST[$username]))
{
	$sret = $_POST[$username];
	$sret = mysql_real_escape_string($sret);
}
return $sret;
}

 

I tried using it but I kept getting fatal errors. Something about it not being able to recall get_post for a second time.

 

I tried using this at first:

 

$username = $_POST['username']; 

function get_POST($username)
{
$sret = NULL;
if (isset($_POST[$username]))
{
	$sret = $_POST[$username];
	$sret = mysql_real_escape_string($sret);
}
return $sret;
}

 

So I took out the $username = $_POST['username'];  and it still gave me the same error.

[Clinton]

Bump for Rarebit