Bug #20912
closedpage still indexed after cHash check fail
0%
Description
The headline pretty much says it...
If you submit a wrong parameter + cHash combination, the caching may be disabled and hence the table cache_pages is protected from being flooded.
However, at least in my configuration I was able to generate infinite bogus entries in the index_phash and other index tables by submitting random GET-parameters.
Typo3 v.: 4.0.11
(issue imported from #M11766)
Updated by Ralf Strobel over 15 years ago
Update: The issue only occurs if the cHash parameter is in the url. It doesn't have to be correct, though. If the request string does not contain the cHash, still one phash line is gnerated (although it shouldn't) but then at least varying the other parameters does not create any further.
There is a workaround that takes out most of the threat:
$TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError'] = '1';
But even that way, I can still create a double entry: one with the correct cHash and one entirely withough a cHash in the query. No attack potential, but I will still have two clone results in my search.
Updated by Ralf Strobel about 15 years ago
I agree with the removal of the DoS line in the summary, since this is more importantly a general issue... However, what made me investigate these things in the first place was that our server went down two weeks ago from being flooded with ten million indexed_search database entries - in this case it was because of the varying backPid in the query, but an attacker could have done the same if exploiting this issue.
Updated by Dmitry Dulepov over 14 years ago
Tested with TYPO3 4.3 and it is not reproducible. TYPO3 sets no_cache on cHash error now, so indexed_search will not do any indexing.