Plugin security issue
4 posts,
4 voices
291 posts
|
I was noted in the forum (can not find the post anymore) about possible security issue which affects almost all plugins. You can access enable and disable scripts directly. For example: http://www.example.com/frog/plugins/dashboard/enable.php Although this usually fails because of non included libraries there are cases when it might succeed. Easy fix is to check for a constant which is defined somewhere in Frog itself. I ended up adding the following lines to the begnining of all enable.php and disable.php files in all my plugins. Check an example commit. |
1 posts
|
Well, this was me. I’ve seen no reply on my post and came to same conclusion as you. Without the proper classes included the script terminates. (Shame on me: So I deleted this stupid post. I know I shouldn’t do this) On the other hand it should be clear to every one that all files from a plugin are directly accessible. PS: I don’t think “FRAMEWORK_STARTING_MICROTIME” is a good idea ;) Regards |
|
291 posts
|
There are possible cases where enable and disable scripts might execute. It is better to be on the safe side and make the check.
Why? It is an constant which is defined when Frog framework is run. If that constant is defined we can safely assume the script was not called directly.. |
650 posts
|
I was already thinking along the same lines and added a cautionary INSTALL_SEQUENCE constant to Frog’s schema files in 0.9.5. The idea tuupola had is sound… ALL php files belonging to Frog should have some sort of if defined in there unless they are specifically intended to be callable outside of Frog. I’d suggest adding: and adding this to index.php At least, that was the direction I was thinking of. |
69 posts
|
I think the problem arises when someone things “FRAMEWORK_STARTING_MICROTIME” should be dropped or renamed. So this is never to change. Also using “MICROTIME” for plugin ‘security’ is not obvious to every one, too.
If this is clear to everyone, fine for me. Regards |