WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 14 months ago

#2597 closed defect (bug) (fixed)

304 Not Modified Headers not returned in RSS2 feed

Reported by: gfmorris Owned by:
Milestone: 2.0.7 Priority: normal
Severity: major Version: 2.0.2
Component: Administration Keywords: 304 http headers feed RSS2
Focuses: 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 (1)

2597-trac-gfmorris-20060324@2027CST (11.9 KB) - added by gfmorris 8 years ago.
HTTP headers for each case outlined in Ticket 2597.

Download all attachments as: .zip

Change History (12)

gfmorris8 years ago

HTTP headers for each case outlined in Ticket 2597.

comment:1 gfmorris8 years ago

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/

comment:2 dougal8 years ago

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.

comment:3 sit8 years ago

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.

comment:4 ryan8 years ago

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.

comment:5 markjaquith8 years ago

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@…

comment:6 ryan8 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:7 markjaquith7 years ago

  • Milestone changed from 2.1 to 2.0.7
  • Resolution fixed deleted
  • Status changed from closed to reopened

Needs fixing for 2.0.x

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

comment:8 markjaquith7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:9 hakre4 years ago

Related: #14169

comment:10 nacin14 months ago

In [23573], I've removed this second strip.

I don't know exact timelines or history, but long before PHP 5.2, magic_quotes_gpc stopped affecting $_SERVER. We have never stripped $_SERVER when magic_quotes_gpc was on, and only added unconditionally. This resulted in double slashes.

Now that magic_quotes_gpc never affects $_SERVER, we always end up with exactly one level of slashing.

Thus, [3682] can go.

comment:11 nacin14 months ago

As found by Jon Cave, https://github.com/php/php-src/commit/0f3a0dfa52983db76df9149f75bc63608efd4d57. PHP 5.0, $_SERVER magic quoting was removed.

Note: See TracTickets for help on using tickets.