Changes between Initial Version and Version 1 of Ticket #21113, comment 9
- Timestamp:
- 04/05/13 12:27:56 (13 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #21113, comment 9
initial v1 1 The reason the cache was pois ioned 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:1 The 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: 2 2 {{{ 3 3 if (!req.url ~ "_wp_http_referer") { … … 8 8 }}} 9 9 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.10 In 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.
