126 (edited by lj 2005-11-14 22:43)

Re: INFO: Bad HTTP_REFERER

Rickard wrote:

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. wink

127 (edited by Smartys 2005-11-15 00:08)

Re: INFO: Bad HTTP_REFERER

lj wrote:
Rickard wrote:

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. wink

I saw someone get around a MySpace requirement just like this. If you want, I'll find the page of how they did it
To be clear, "this" means a hidden form field that needed to be passed

128

Re: INFO: Bad HTTP_REFERER

Yeah I'd be interested to see that... I'm having trouble seeing how a hidden form field would be less secure than a cookie. In normal circumstances a cookie is more convenient for tracking sessions, but otherwise the principle is the same.

129

Re: INFO: Bad HTTP_REFERER

Well, problem number one with that solution is that right now, we don't use sessions at all.

This might be worth a read by the way.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

130

Re: INFO: Bad HTTP_REFERER

http://namb.la/popular/tech.html
#9 on that list

131 (edited by lj 2005-11-16 20:59)

Re: INFO: Bad HTTP_REFERER

Smartys wrote:

http://namb.la/popular/tech.html
#9 on that list

I'm about 90% through getting my head around this totally, so could still be wrong. wink

It looks like the above is only possible because the 'attacker' was able to run Javascript code in the context of the MySpace site. As a result, this code could know any cookie information it needed, and create an HTTP GET request supplying that cookie info in order to obtain the 'secret' token MySpace include in the form.

If I merely follow a link from my PunBB forum - even while logged in - to a malicious site, that site can send an HTTP request to my PunBB forum admin pages, but where will it get the cookie from? Without the cookie, PunBB won't give it the secret token; it can make my browser submit to the PunBB admin section, but the submission will lack the secret token, and nothing will happen.

Edit

The reason why I'm not keen on all this referrer checking is because I long since learned that you can't rely on the referrer to be there when you want it, and it's just too easy to falsify.

The MySpace exploit uses XMLHTTPRequest to do all the 'clever' stuff... and guess what, one of the options you have is to set any HTTP header. So, you could just make up an HTTP Referrer.

Try this URL or Google for xmlhttprequest:
http://en.wikipedia.org/wiki/XMLHTTP

132

Re: INFO: Bad HTTP_REFERER

The problem with adding some kind of token to the form that is then validated when the form is posted is that it needs to be stored somewhere. This token could be created once per "session" though (maybe stored in the online table). One potential problem with that is that if an administrator opened up a form, the went away for 15 minutes and came back and posted it, it would have "expired". I'm not that fond of the referrer check either, so if anyone has any bright ideas, I'm all ears.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

133

Re: INFO: Bad HTTP_REFERER

lj wrote:
Smartys wrote:

http://namb.la/popular/tech.html
#9 on that list

I'm about 90% through getting my head around this totally, so could still be wrong. wink

It looks like the above is only possible because the 'attacker' was able to run Javascript code in the context of the MySpace site. As a result, this code could know any cookie information it needed, and create an HTTP GET request supplying that cookie info in order to obtain the 'secret' token MySpace include in the form.

If I merely follow a link from my PunBB forum - even while logged in - to a malicious site, that site can send an HTTP request to my PunBB forum admin pages, but where will it get the cookie from? Without the cookie, PunBB won't give it the secret token; it can make my browser submit to the PunBB admin section, but the submission will lack the secret token, and nothing will happen.

You're probably right, it's probably only possible because they're on the same domain (well, almost, but the cookie is set to .myspace.com).

lj wrote:

Edit

The reason why I'm not keen on all this referrer checking is because I long since learned that you can't rely on the referrer to be there when you want it, and it's just too easy to falsify.

The MySpace exploit uses XMLHTTPRequest to do all the 'clever' stuff... and guess what, one of the options you have is to set any HTTP header. So, you could just make up an HTTP Referrer.

Try this URL or Google for xmlhttprequest:
http://en.wikipedia.org/wiki/XMLHTTP

Yes, you could
But, like you said, he was in the context of the MySpace site. Like #8 said: "No big deal, however XML-HTTP won't allow GETs/POSTs to sites with a different domain name". So, the request wouldn't work. You might be able to do it using XSS vulnerabilties, but if there's an XSS vulnerability, you can also grab cookie values directly smile

134

Re: INFO: Bad HTTP_REFERER

My problem comes from the firewall zonealarm, anyone has already fixed the problem with this firewall ?

135

Re: INFO: Bad HTTP_REFERER

Hi

I am getting the same problem with:
Bad HTTP_REFERER. You were referred to this page from an unauthorized source. If the problem persists please make sure that 'Base URL' is correctly set in Admin/Options and that you are visiting the forum by navigating to that URL. More information regarding the referrer check can be found in the PunBB documentation.

or to say the admin user is, while i am not, even if i use the same link as her, or a complete other one.

I have looked into the point made on this topics first inlay. The lady is just trying to do point number number 3 about the firewall, and i hope and think it would be this since i do not have a problem.
What do you think?

136 (edited by Leonch05 2006-02-28 23:50)

Re: INFO: Bad HTTP_REFERER

FYI:

Just installed 1.2.11 and got a 'Bad referer' error in Admin, saving changes, checked the info on here and although I don't use Norton, I do use NetBarrierX3 on a Mac running 10.3.9 and once I'd disabled 'Information Hiding' it saved the changes without the 'Bad referer' error.

I repeated the situation twice for confirmation that it was NetBarrier.

137 (edited by franke 2006-03-10 17:21)

Re: INFO: Bad HTTP_REFERER

Is there any way of adding a base url so that you can have 2 ?

I have my forum at  foo.mine.nu  , but I cant access that url from my Lan, I have to go via

hostname/web/foo.mine.nu,, when I do that I cant for instance move any threads or so, I get "bad referrer",

I dont want to chance the referrer to "hostname/web/foo.mine.nu" every time I need to change something, since I also want to be able to access it from outside the LAN.

I tried to use a proxy, but I read that doing so, the proxy strips out the referrer-arguments or something, and u still get "bad referrer".

Edit: I inserted 192.168.1.5 foo.mine.nu   in my  hosts-file on my windows machine I surf on and now I can access foo.mine.nu directly.

138 (edited by AndersB 2006-03-30 19:55)

Re: INFO: Bad HTTP_REFERER

I want to add support for another internet browser, where do I do that?
As it is, the forum complains about bad HTTP_REFERER, so I guess I need to
add this browsers referer somewhere.

139

Re: INFO: Bad HTTP_REFERER

hi guys..i have tried all that u said about the http bad referrer..
i have no firewall enabled, and also, in the admin panel, the base url is the same as i visit the forum..please help me solve this problem..i did all what u said but i am still getting this bad http referrer..please help me...thanks..

140 (edited by RAHster 2006-09-18 21:39)

Re: INFO: Bad HTTP_REFERER

Same problem caused by Zone Alarm ("ZA").  Changed ZA's privacy settings specifically for just the site with the forum, so all protection is still in place for everything else.

Under ZA's Privacy section, Site List tab, you can allow Private Header information in the cookie transmission (see last column). 

You may need to upgrade ZA to the newest version.

RICK

Re: INFO: Bad HTTP_REFERER

Ow, that's OK. thanx!

Michael aka Emilien @ My Opera Community: http://my.opera.com/michael_aka_emilien

142

Re: INFO: Bad HTTP_REFERER

I have a badHTTP refer error when I try to set my base URL in admin_options page. Please tell me what to do.

143

Re: INFO: Bad HTTP_REFERER

What's your base URL set to and what URL are you accessing the page from?

Re: INFO: Bad HTTP_REFERER

RAHster wrote:

Same problem caused by Zone Alarm ("ZA").  Changed ZA's privacy settings specifically for just the site with the forum, so all protection is still in place for everything else.

Under ZA's Privacy section, Site List tab, you can allow Private Header information in the cookie transmission (see last column). 

You may need to upgrade ZA to the newest version.

RICK

THANKS!

145

Re: INFO: Bad HTTP_REFERER

Just installed the latest version 1.2.14 and also followed the options->base_url guide.. everything seems ok but I still get "Bad request. The link you followed is incorrect or outdated." this message would only appear whenever I click/view on a topic link. Every other link on the forum works just fine.

Things i've done:
a. make sure i follow the base_url set on my site
b. check if no firewall or antivirus running.

although I noticed that 'cache' folder dont have write permissions to modify a setting... Can this be the cause or related issue?? btw this the site im working on http://buzz.filmschool.ph/forum Need Help!!! Thanks

146

Re: INFO: Bad HTTP_REFERER

Rickard wrote:

First of all, you really should consider disabling Norton Internet Security before disabling the referer check in PunBB. However, if you insist on disabling it, here's how.

Replace confirm_referer with the following piece of code:

function confirm_referer($script)
{
    // Do nothing
}

Then, in admin_options.php, look for:

// Lazy referer check (in case base_url isn't correct)
if (!preg_match('#/admin_options\.php#i', $_SERVER['HTTP_REFERER']))
    message($lang_common['Bad referer'].' <a href="mailto:'.$pun_config['o_admin_email'].'">'.$pun_config['o_admin_email'].'</a>.');

and remove it.

Ok amn i knew where to find the  admin_options.php it's in the Ftp...

But Replace confirm_referer with the following piece of code... what php. file is that is.. where can i find it to edit it..


like what is the name of the file i have to edit..


Thank you

Re: INFO: Bad HTTP_REFERER

PSPpimp: include/functions.php

Looking for a certain modification for your forum? Please take a look here before posting.

148

Re: INFO: Bad HTTP_REFERER

I was getting this error because I had set Firefox to not send referrers at all. Certain websites would block you if you came from other website, like google image search. Disabling the referrer had the effect of making image search work 100% again smile To enable/disable this in firefox, type in about:config to the url bar and search for: network.http.sendRefererHeader  set the value to 1 to send referrers, 0 to block them. If someone else already posted this, sorry for duplicating.

149

Re: INFO: Bad HTTP_REFERER

If Im using mini portal and my main forum page is /forum.php not /index.php then what do I set my base url to?

150

Re: INFO: Bad HTTP_REFERER

The base URL doesn't depend on the page you're looking at