Re: INFO: Bad HTTP_REFERER
Aha. Maybe that was in a different topic.
Without the referrer check, it would be possible for a malicious user to construct a web page somewhere and then trick an admin or a moderator to visit that page. On the page, a hidden form would be posted via Javascript that posts to a page in the forums (an admin page or maybe someones profile). It would be easy to e.g. upgrade a user to admin status. However, with the referrer check, this wouldn't be allowed because the forums would check the referrer and notice that the form was posted from somewhere outside the forums.
I've been thinking about this problem.
I haven't tested it, but... the above scenario seems to be possible because when our hapless admin posts a form hosted on rogue.example.net site to punbb.example.com, their browser will helpfully send back cookies related to punbb.example.com and not rogue.example.net; the session will be valid, the form submission will go through. There's nothing in the form itself to validate whether it's genuine or not.
So, on the genuine admin page forms, why not output the session id in a hidden form field? This can then be checked with the form submission. The rogue site can't know in advance what session id to hack up in their nasty little form - and if they do know, then they don't need the form in the first place. You're already sending these cookies out in the clear in the HTTP headers, so having an admin being able to see it via View Source is no worse than being able to see it via View Cookies.
A variant on the above is to generate (and track) some new token especially for the purpose, perhaps cryptographically related to the session id. But I'm not sure that's necessary.
I think this would be less problematic than the referrer checking... which just bit me because I have more than one way of getting into my test site.