Bug #20913
closed
cHash-checking does not include target page
0%
Description
This issue is potentially dangerous if, for example, you have a website with both a lot of pages and a lot of tt_news entries.
All I need to do is to copy a working parameter combination I can simply get from any news item link. For example "&tx_ttnews[tt_news]=1115&cHash=a6b265ec4d"
Then I submit that query string to all pages on the website. When I tried this, additional cache lines were always generated. So if a website has 1000 news items and 1000 pages (like ours), I could generate 1.000.000 bogus entries. If the webmaster decided to use the backPid and other dynamic parameters, the number of working query combinations I could harvest as an attacker is almost infinite.
I think there should at least be an option to include the page id of the link destination into the generation of the cHash.
(issue imported from #M11767)
Updated by Ralf Strobel over 15 years ago
Thinking again, I'm not sure if this is a major issue any more...
It's still annoying, for another reason, though: It generates double indexed_search entries for a page. For reasons I don't understand I already had some crawlers trying to submit queries to other pages.
Updated by Marcus Krause about 15 years ago
I don't see why this should be a DoS issue. It's just a normal page processing.
Increasing number of requests
- might fill sys_stat entries
- might fill you default logfile
- might use up transfer volume
This is all pretty normal stuff and imho does not qualify for DoS.
Updated by Ralf Strobel about 15 years ago
I basically agree... but let me quote from Kaspers own explanation as to why cHash was introduced:
"Well, that would provide the basis for a major DoS attack. What if someone requests 1 million URLs with random parameters like “?id=123&USELESS_PARAMETER=[any random number]” - that would spam our database with gigabytes of cached instances of... the SAME page!"
I think what I'm saying here adresses that same issue. I showed literally how you could spam the database with one million cache instances.
Updated by Alexander Opitz over 11 years ago
- Status changed from New to Needs Feedback
- Target version deleted (
0)
The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?
Updated by Alexander Opitz about 11 years ago
- Status changed from Needs Feedback to Closed
- Is Regression set to No
No feedback for over 90 days.