Ticket #2597 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

304 Not Modified Headers not returned in RSS2 feed

Reported by: gfmorris Assigned to: anonymous
Priority: normal Milestone: 2.0.7
Component: Administration Version: 2.0.2
Severity: major Keywords: 304 http headers feed RSS2
Cc:

Description

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!

Attachments

2597-trac-gfmorris-20060324@2027CST (11.9 kB) - added by gfmorris on 03/25/06 02:31:53.
HTTP headers for each case outlined in Ticket 2597.

Change History

03/25/06 02:31:53 changed by gfmorris

  • attachment 2597-trac-gfmorris-20060324@2027CST added.

HTTP headers for each case outlined in Ticket 2597.

03/25/06 02:33:43 changed by gfmorris

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/

03/30/06 16:05:43 changed by dougal

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.

03/30/06 17:48:34 changed by sit

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.

04/01/06 23:16:20 changed by ryan

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.

04/03/06 05:11:17 changed by markjaquith

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@wordpress.org

04/03/06 05:59:05 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

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

01/10/07 13:48:59 changed by markjaquith

  • status changed from closed to reopened.
  • resolution deleted.
  • milestone changed from 2.1 to 2.0.7.

Needs fixing for 2.0.x

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

01/10/07 13:50:33 changed by markjaquith

  • status changed from reopened to closed.
  • resolution set to fixed.

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