304 Not Modified Headers not returned in RSS2 feed

[gfmorris]

 Scott Sanders of FeedLounge noticed that IJSM.org's RSS2 feed was not 304-aware. IJSM.org is running WPv2.0.2. That sent me on a goose-chase around my box, knowing that I have WP installs at a variety of revision levels [bad, I know].

---

 v2.0 RSS2 feed shows up as returning 304.  v2.0.1 RSS2 feed shows up as returning 304.  WordPress.com RSS2 feed shows up as returning 304.  v2.0.2 RSS2 feed does not return a 304.

I have checked the  /rss/,  /comment/, and  /atom/ feeds for IJSM.org and they also show no 304 headers returned.

The  comments feed for the 2.0.1 install I have returns a 304 as it should.

I don't know if this is related to the security fixes of 2.0.1--->2.0.2; if so, I'm okay with it. I'll take the bandwidth hit on my box over the probability of my box being 0WN3d. That said, this is still an issue.

I'll leave those feeds untouched through until Sunday evening Central time so that there's time to check them. Past then, I need to secure my box.

Thanks for your time!

HTTP headers for each case outlined in Ticket 2597.

I made a typo with the comments feed in the third paragraph. Please accept my apologies. The appropriate feed to test:  http://ijsm.org/comments/feed/rss2/

Emil Sit may have  found the culprit, which seems to relate to either changeset:2699 or changeset:3572. The quick fix seems to be to add an extra stripslashes call on line 248 of classes.php.

It would probably be better to find a real fix; I think the intention is that $_SERVER is quoted once, either by PHP's magic_quote or by some calls to addslashes in WP. The problem is (I believe) that both are happening on some configurations/versions of PHP: PHP magic_quote's server, and then WP calls addslashes (and then at some point calls stripslashes).

Of course it is safe in this usage to stripslashes since the check that the ETags are the same is just a string comparison (not some SQL statement, e.g.) but I could imagine that there may be some potential deeper problems and this is only one possible manifestation.

I wonder if some php versions are magic quoting $_SERVER and others are not. We had a security bug where we were assuming $_SERVER was quoted by magic quotes when in fact it wasn't. That led to the current code where we assume $_SERVER is never quoted by magic quotes.

All my testing indicates that $_SERVER is, in fact, quoted by magic_quotes_gpc

There are a limited number of HTTP headers you can inject quotes into just by using a browser, so I opened up a telnet session and injected quotes everywhere that I could (without invalidating the HOST, for example) and found that all these places were slashed when magic_quotes_gpc was on.

I'm running PHP 4.3.10-16

The PHP documentation on this is wrong, or at best, incomplete.

Was the alleged vulnerability with $_SERVER ever tested? I don't see a ticket associated with the commit. It could have just been submitted to security@…

(In [3682]) Do a therapuetic double strip on HTTP_IF_MODIFIED_SINCE since we code in an imperfect world. fixes #2597

Needs fixing for 2.0.x

A minority is affected, but it's a pretty big deal for those folks.

(In [4715]) Backport of HTTP_IF_MODIFIED_SINCE double stripslashes() fix. fixes #2597

Related: #14169