Have I got it the right way around?

Yup :). The output of time() is the time in seconds since the unix epoch. You're presumably recording $_SESSION['lastMailed'] every time a message is sent therefore if the last time() the message was sent plus 10 minutes (600 secs) is after (greater than) the current time(), the last message must have been sent less than 10 minutes ago.

If it's not working, post the whole script and we'll take a collective gander :).

Edit: I'm assuming of course that you allow the message to be sent if the if statement evaluates to true and not the opposite.
 
You won't be able to prevent them starting a new session, all they need to do is clear their cookies are remove the session ID from the url (if it's present) and wallop, a new session for them.

You'd be better off assigning the time sent in your database and link it with the user ID, that way even if they lost the session (which can happen accidentally/legitimately but is also exploitable) the timelimit will still be in force.

Though you would then have to worry about spammers creating multiple accounts.
 
You do realise mailbots just don't send the cookie or any other header info, right?

Sessions are entirely reliant upon the user agent transmitting the session ID.. mailbots aren't so generous..
 
No, mailbots don't transmit their IP address either, and guess what.. that is the only way PHP receives a users IP address.

User account is the way, otherwise you'll need to heavily scrutinise the emails before sending them.

If you are experiencing problems with mailbots exploiting your mail form and sending to 3rd parties, you need to scan the headers and body of the message more thoroughly.
 
Well *** site hasn't gone live yet, i am just trying to avoid problems.

Currently there are only two fields.

Their Email and their message.

The Email has to be a blah @ blah . com

and the message is already scanned for headers uysing this, which i can't check if it works and i don't know how to put in headers myself :|

this is what i have:

Code: 
	$valid = "false";
	$crack=eregi("(\r|\n)(to:|from:|cc:|bcc:)",$comments);
	if(eregi('^([0-9a-z]+[-._+&])*[0-9a-z]+@([-0-9a-z]+[.])+[a-z]{2,6}$',$email) && !$crack){
		$valid = "true";
	}

What more should i do?

Thanks.
 
Dj_Jestar said:
No, mailbots don't transmit their IP address either, and guess what.. that is the only way PHP receives a users IP address.
Click to expand...
How can you not transmit your IP address? IP isn't sent though HTTP headers, so is it a case of modifying packets - a fire-and-forget type of thing?
 
I don't know the ins and outs of it, all I do know is that $_SERVER['REMOTE_ADDR'] is relatively easily spoofed, and can be spoofed with _any_ string the user agent likes, which can include blank.

Also add that mailbots can use public proxies to get around IP checking and it becomes doubly useless.
 
How exactly would one spoof REMOTE_ADDR :confused:

If they went to the trouble of creating packets from scratch with a forged IP in, it would never actually send the mail.
 
I believe the problem lies with the way PHP composes the $_SERVER['REMOTE_ADDR'] variable, rather than the user agent spoofing their actual address. Much in the likeness that $_SERVER['PHP_SELF'] can be tainted by simply adding a particular char to the URI.

For example, if your PHP setup runs as CLI, you don't get a $_SERVER global at all, apart from ARGV and ARGC.

There is also the issue of which Webserver is this on - some do and some don't have REMOTE_ADDR.

I'm looking into how it's spoofed, but I am rest assured it can be spoofed and quite easily on the grand scale of things - i.e. I don't think it requires packet spoofing.
 
Dj_Jestar said:
I'm looking into how it's spoofed, but I am rest assured it can be spoofed and quite easily on the grand scale of things - i.e. I don't think it requires packet spoofing.
Click to expand...

I have just googled IP spoofing and it has come up with a plethora of so called "software" to spoof ips
 
Dj_Jestar said:
I believe the problem lies with the way PHP composes the $_SERVER['REMOTE_ADDR'] variable, rather than the user agent spoofing their actual address. Much in the likeness that $_SERVER['PHP_SELF'] can be tainted by simply adding a particular char to the URI.

For example, if your PHP setup runs as CLI, you don't get a $_SERVER global at all, apart from ARGV and ARGC.

There is also the issue of which Webserver is this on - some do and some don't have REMOTE_ADDR.

I'm looking into how it's spoofed, but I am rest assured it can be spoofed and quite easily on the grand scale of things - i.e. I don't think it requires packet spoofing.
Click to expand...

Well there is no other way the server can get the user's IP apart from by looking at the source of the packets--read the HTTP spec. If a user spoofed their IP at a packet level, none of the packets would be returned to them--useful if you want to DoS someone, but not useful if you want to execute someone's PHP script.
 
Is there still not a problem with the people that are behind proxies (i suppose its just their fault - something i can live with)

.......but there are people that are behind a proxy which is isp side i think which would cause a problem.

Also with dynamic ips who get a new ip everytime they connect to their isp.
 
You must log in or register to reply here.
Back
Top Bottom