Quote:
Originally Posted by Redcoder
Okay. If you have random values for form names, don't you think that thats overkill?
|
You're the one who is adamant about defending the site.. coming from you I'm rather shocked that you're now saying another layer of defence is overkill
Quote:
Originally Posted by Redcoder
How will you figure them out during data retrieval?
|
Store the names and actual name-values in the session or database. It doesn't matter as long as they're on the server.
Quote:
Originally Posted by Redcoder
Storing them in session cookies? The attacker can see those too. Remember, anything in session cookies is viewable to the user mate.
|
Erm.. No!
I get the impression that in your eagerness to be a coder, you've scrimped on certain bits along the way. Sessions are kept on the server side. Cookies are kept on the clients PC. Session data is written to a session file on the servers hard disk (unless of course you change the default sessionhandler to use a database instead which actually avoids a lot of session timeouts and garbage clearance issues). The only session information that is sent to the client, is the session identifier - also known as the PHPSESSID. PHP does not set any other cookies with session information. Yes, some sites set other things in a cookie but those are minor things that shouldn't affect security.
Even with the PHPSESSID (a name that can be changed) value, you still can't gain access to the session data thats been stored / change it etc. It's only available to the scripts themselves.
If you want to see more about how cookies and sessions are handled via http, check out my reply to nomanics thread a while back:
http://www.codingforums.com/showpost...64&postcount=7
Before you even think about quoting me on cookie theft, it would make no difference here as the bot master you're speaking of still wouldn't know the random form names that were output in order to submit any spam data. *HOWEVER* if they've stolen a cookie, it's highly probably that your attacker has been sniffing your TCP traffic and stolen that form anyway which then could in theory be used to submit a form. Checking against IP addresses would be pointless as they can be spoofed. In reality while it is possible, not many people are going to be monitoring visitors to your site for TCP traffic and given that you described a scenario in an internet cafe where someone is on the computer AFTER the last user, it wouldn't be a threat.
The bottom line here is that there are advanced ways to attack a site that advanced attackers can use. People like us don't stand a chance against the real pro's from the old-skool and if they do attack your site, you've pi**ed off someone somewhere. People like us will never defend against the real pro hackers but we can defend against the script kiddy wannabies.
Quote:
Originally Posted by Redcoder
The thing is...you have to agree, Ajax is the way to go.
|
I don't have to agree to anything. Sure, an ajax call every 10 - 30 seconds may be a good idea but if you were to do it every 1 - 5 seconds it drives up the CPU usage to stupid levels (just check out any page with comments on the suns website - open up 3-4 stories in different tabs and you'll soon see the effects). While it can contribute towards solving the problem, it isn't a solid cure for it.
You're still up at this time too?
