我不了解上周的安全补丁：https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2016-022/。我有一个旧的TYPO3 6.2安装。我已经截断了所有cf_ *表并使用UID 2-6打开了页面。没有哈希。结果，我看到了13个cf_cache_hash-entries。
现在，我已经从前端的列表页面中打开了一个详细信息页面。我在URL中看到一些参数，例如动作，控制器，当前显示记录的UID以及导致cHash的UID。
然后，我将这些参数（不包括id = x）复制到我的页面2-6的URL中。在cf_cache_hash中，我还有13条记录。因此，没有缓存溢出。
或我必须如何解释此报价：
具有有效cHash参数的链接会导致新生成的页面缓存
条目。由于cHash未绑定到特定页面，因此攻击者
可以对多个页面使用有效的cHash参数，从而导致
其他无用的页面缓存条目。
下一个问题：
如果使用了诸如realurl之类的扩展名，则需要刷新它们的扩展名。
缓存（以及TYPO3缓存）
您能告诉我我/我们应该清除哪些表吗？
tx_realurl_urldecodecache
tx_realurl_urlencodecache
可能还可以。但是tx_realurl_pathcache呢？当然，我可以清除这一点，但是对于较早的realurl配置而言，较旧的条目呢？如果我截断该表，这些旧条目将不再有效，并且不会再次构建。因此，旧的搜索引擎结果无效。
我们的一位客户提出的问题：清除后端的系统缓存是否足够？还是应该单击Installtool中的“清除所有缓存”？真好IMO，这还不够，必须直接在DB上将表截断。对。
下一个：
这意味着，如果此类URL被搜索引擎索引，则来自
该搜索引擎将最终显示在无法正常工作的页面上。
嘿，酷。现在？解决办法是什么？保持原样？在IMO中，它依赖于一个名为InstallInstall的设置：pageNotFoundOnCHashError。对？
请告诉我们该怎么做，并请添加更多详细信息以解决该问题。
斯特凡
最佳答案
对我来说，它可以归结为（安装更新的TYPO3版本之后）：
如果您不使用realurl：启用
$GLOBALS['TYPO3_CONF_VARS']['FE']['cHashIncludePageId'] = true;
＆，您可能“完成了”。当然，所有旧的Google匹配都将完成，但是在“公共”网站上，如果您没有运行realurl（或类似的URL），您很有可能永远不会关心Google。
如果您在6.2上使用realurl 1.X
不要启用配置（可能永远不会有合适的补丁程序）
两种选择：
冒DDOS的风险
使用https://github.com/mogic-le/typo3-realurl中的1.x版本
如果我对它的理解正确，那么如果在缓存表上没有命中，它将把TYPO3设置为no_cache模式。虽然这是一个性能问题，但它将阻止进行高速缓存表项的创建（作为副作用）
如果您运行7.6+和realurl 2
等待realurl 2.1（冒险吗？）
更改缓存
类似memcached的框架（有些建议
行之间：如果您有一个无法使用的缓存后端
对于DDOS，您实际上不必在意）
使用前叉
helhum（尽管我认为这对您没有帮助
链接）