WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #21113, comment 9


Ignore:
Timestamp:
04/05/13 12:27:56 (13 months ago)
Author:
kirrus
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #21113, comment 9

    initial v1  
    1 The reason the cache was poisioned was an interaction with the wp-SuperCache module, that was generating static pages with the poisoned urls in. These were then served to all users. I've turned that particular feature off in Supercache. I'm also doing this in the cache, which is really quite aggressive, but also handily effective in stopping the most egregious GET variables: 
     1The reason the cache was poisoned was an interaction with the wp-SuperCache module, that was generating static pages with the poisoned urls in. These were then served to all users. I've turned that particular feature off in Supercache. I'm also doing this in the cache, which is really quite aggressive, but also handily effective in stopping the most egregious GET variables: 
    22{{{ 
    33        if (!req.url ~ "_wp_http_referer") { 
     
    88}}} 
    99 
    10 In any case, this is still a bug; it is a vector that may be used to abuse other bugs in wordpress attack wordpress, it is a vector to attack any wp-SuperCache using site, and a vector to cause sites to show thousands of unique urls showing duplicate content to Google. Anything that allows a user to directly alter website content in this fashion should be treated with suspicion. 
     10In any case, this is still a bug; it is a vector that may be used to abuse other bugs in wordpress to attack wordpress, it is a vector to attack any wp-SuperCache using site, and a vector to cause sites to show thousands of unique urls showing duplicate content to Google. Anything that allows a user to directly alter website content in this fashion should be treated with suspicion.