Support

"Why it was cold and now it's not?" What you make out of this question. Not much, really, as it's taken out of context. If I told you that I was talking about a beer bottle, you might entertain yourself a few speculations as to where the beer bottle was and what happened. If I told you that I'm talking about the beer bottle that I took out of the refrigerator three hours ago, you'd know exactly what is going on. In other words: context is of paramount importance to understanding and answering a question.

What you've given me is inadequate context. Just the URL tells me nothing much. Try visiting it on your site to see what I am talking about. It's the password reset form, the one a user must fill out to reset his account's password. Should it be generally blocked? No. Should it be blocked to spammers? Preferably yes. Is the user in the first case a spammer? I have no idea, there's not enough data to know within any degree of accuracy. Is the user in the second case a spammer? Likewise, I have no idea. So, based on the information you can give me, I'd say that I can see no problem whatsoever.

He he! That was a hack that worked on some early Joomla! 1.0.x versions (IIRC before 1.0.11) and Mambo sites. Of course it doesn't work on Joomla! 1.5.x, so there is no need to worry about that.

The difference you observed between the two releases of Admin Tools is that I decided to allow an empty referrer string, since many legitimate requests coming from modern browsers do not include it under many circumstances (private browsing, accessing HTTPS sites, etc). That said, you would be in no danger even if a similar hack succeeded because:
0. I doubt that the hack would even work, since it's very likely that a security feature like XSSShield, SQLiShield or Bad Behaviour would block the attack in its very beginning.
1. The back-end of your site can (and should be!) protected by a secret URL parameter
2. You get an email even if the user logs in so that you can turn on the Emergency Off-Line mode before he is able to do anything
3. You can whitelist only your IPs, so that nobody else has access to the back-end
4. Even if you have not turned on anything of the above and the attacker does log in to the back-end and does change the allowed MIME types to allow uploading of PHP files, the UploadShield protection will block him from doing so.
5. The .htaccess Maker's default settings disallow running PHP files even if the attacker manages to upload it.
6. Trying to change Admin Tools settings requires knowing the Master Password. Without it, he can't change any of the above settings.
7. Even an enterprising hacker, trying to circumvent all of the above restrictions by uploading a specially crafted extension installation file would have to leave empty handed, as installing extensions can be blocked using Admin Tools.

All and all, the default security settings put a series of barricades in the way of an attacker to hacking your site. While each of them, by itself, can not provide 100% protection of your site, combined they can be a strong deterrent for most attackers. The idea is that it will become so time consuming for the attacker to hack your site that, unless you are a very valuable site, will cause the attacker to leave your site in peace and seek a different victim. And that's exactly how security works, in all contexts. For example, buildings. A secure lock can be cracked using liquid nitrogen. A reinforced door can be blown away with dynamite (I've seen that on the news, five years ago!). Bars on windows can be pulled out of the wall using a very powerful track (happened to a friend with a house in a far-off location). 2-feet concrete walls can probably be demolished. But all of the cracking methods are so messy, time consuming and noisy that make them impractical. Therefore secure locks, reinforced doors, bars on windows and 2-feet concrete walls add to the security of a building.

Yes, indeed. The CSRFShield will always be triggered by users using Private Browsing on their browsers and if your site is using HTTPS as, in this case, the referrer HTTP header field will be blank. Some legitimate CSRF attacks will also be caught by the filter but, overall, treat CSRF notifications as warnings, not as grave security exceptions.

You're welcome!