1

(6 replies, posted in General discussion)

I'm not allowed to run IE7 beta.

On my work laptop, Windows Genuine Disadvantage fails, even though I have a legal copy of Windows XP.

At home, it won't work becaues I have a 64-bit version of Windows and they only have a 32-bit IE7 beta. I have a 32 bit Windows too, but I'm not allowed to use it because I bought a new CPU.

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

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.

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

Rickard wrote:

I think Smartys was being ironic. Having the poster column in the database solely to prevent a join in one script (that isn't even accessed that often) is of course idiotic smile

Heh, looks like a [irony] BB tag would have come in handy there! wink

6

(121 replies, posted in PunBB 1.2 discussion)

Thanks, that helps a lot. I'm in the early stages of redesigning my site and forums so I don't mind developing against a beta version... someone at work decided to get me into West Wing and I'm catching up on all the seasons on DVD so I don't have a huge amount of free time for coding anyway! wink

Thanks for the replies guys...

Smartys wrote:

In a quick glance, here was one query I found (from post.php):

$result = $db->query('SELECT poster, message FROM '.$db->prefix.'posts WHERE id='.$qid) or error('Unable to fetch quote info', __FILE__, __LINE__, $db->error());

So, it prevents having to join the users table into the query when fetching a quote smile

What's wrong with joining the users table? It's a single lookup in a BTREE index. The cost should be negligible.

On the other hand, every time the posts table is accessed in a way that can't be wholly covered by the index, all those username fields are being read from disk and taking up any memory cache space. This probably has a higher overall cost than the above.

I'm not saying you're wrong (I only joined today so it would be a bit rude anyway!), but I would caution against assuming joins are bad (unless it's already been performance tested). In general, smaller tables and more joins is better.

Rickard wrote:

The poster column is needed for guest posts.

Oops, I'd forgotten about this functionality (because personally I probably won't use it...)

Well I guess if the column were made nullable and only used for anonymous posts, then it shouldn't hurt. smile

8

(121 replies, posted in PunBB 1.2 discussion)

Connorhd wrote:

the first rule of punbb club is you do not ask when the next version will be released.
the second rule of punbb club is you do not ask when the next version will be released.
the third rule of punbb club is you DO NOT ask when the next version will be released.

tongue

Given the above, and that pinning down a project like this to specific dates would be futile, where should a newbie like me be looking to get a sense of the following:

1. Are there any general policies used with respect to release cycle? e.g. the GNOME (Linux desktop) project releases every 6 months regardless; phpBB promise 1,000 features and lock themselves away in a dark corner for years on end with nothing usable to show for it... basically different projects have different approaches.

2. Scope of 1.3 release - it seems that actual features are not what it's all about, but making plugins/mods -> extensions highly managable. This is IMHO a Good Thing because I've seen the pain of maintaining a heavily modded BB while trying to cope with security updates (or even benefit from new features). But anyway, will there be much more in 1.3 beside all that?

3. At what approximate stage of development is 1.3? Sandbox, alpha, beta, beta and feature complete? Or is this unknown?

4. Is there a time frame in mind at all, or is this just totally taboo? I'm thinking in terms of Q4 2005, Q1 2006, etc. and not expecting anything firm.

Obviously the developers have a life, and forums shouldn't be clogged up with the same question, but if you look at it from the user's point of view, a little bit of insight can be helpful. I need to decide if it's worth migrating my phpBB forum to PunBB, and if so, whether to go with the 1.2 or 1.3 branch.

I started playing with PunBB today, thought I'd have a look at the database... one of the first things I noticed was that the posts table has a poster varchar and a poster_id integer... only the latter one seems to be needed if you ask me.

As my forum (currently a phpBB) has over 500,000 posts, that's a lot of repetition! wink

I couldn't find any topics debating the issue except this one... so what's the reason for doing it like this? Perhaps if there's a problem query that required breaking "normal form" (whatever that is!) then I'd be interested to take a look...

OK this is a very small thing, but my development environment uses port-based rather than name-based virtual hosts. So I have sites like http://localhost:8001 etc. When I ran install.php I noticed it missed off the port, ie. just giving http://localhost/forums instead of http://localhost:8001/forums.

Here's a patch if you want one:

--- upload/install.php  2005-11-01 00:31:04.000000000 +0000
+++ temp/install.php  2005-11-13 17:37:04.000000000 +0000
@@ -228,7 +228,7 @@
                                        <legend>Enter the Base URL of your PunBB installation</legend>
                                        <div class="infldset">
                                                <p>The URL (without trailing slash) of your PunBB forum (example: http://forum.myhost.com or http://myhost.com/~myuser). This <strong>must</strong> be correct or administrators and moderators will not be able to submit any forms. Please note that the preset value below is just an educated guess by PunBB.</p>
-                                               <label><strong>Base URL</strong><br /><input type="text" name="req_base_url" value="http://<?php echo $_SERVER['SERVER_NAME'].str_replace('\\', '/', dirname($_SERVER['SCRIPT_NAME'])) ?>" size="60" maxlength="100" /><br /></label>
+                                               <label><strong>Base URL</strong><br /><input type="text" name="req_base_url" value="http://<?php echo preg_replace('/:80$/', '', $_SERVER['HTTP_HOST']).str_replace('\\', '/', dirname($_SERVER['SCRIPT_NAME'])) ?>" size="60" maxlength="100" /><br /></label>
                                        </div>
                                </fieldset>
                        </div>

I'm new to PunBB - and to submitting patches - so just yell if I'm not going about it the right way, or if the above fails to work...

Fair enough... I'm sure after a 24 hours have passed I'll have adjusted to a world where PHP scripts don't end in ?> wink

12

(0 replies, posted in Test forum)

PunBB Home

Bold and italics with deliberately out-of-order tags

<?php

echo 'this is some test php code';

?>

Just curious what sort of problems it causes? I've never heard of omitting ?> before...