Support

Admin Tools

#14821 Selectively assign exception for EasyBlog

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by nicholas on Tuesday, 29 January 2013 09:30 CST

Tuesday, 29 January 2013 07:03 CST

careytech

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? No\yes
Have I searched the tickets before posting? yes
Have I read the documentation before posting (which pages?)? yes
Joomla! version: 2.5.8
PHP version: (unknown)
MySQL version: (unknown)
Host: (optional, but it helps us help you)
Admin Tools version: 2.4.2

Description of my issue:

My issue seems identical to what is listed in ticket 14272 - To stop blocking users of EasyBlog due to DFISheild.  The DFIShield occurs upon this URL: /index.php?option=com_easyblog&lang=none&Itemid=<some number>   and the recommendation is to create an exception for the entire component com_easyblog.  I understand how this stops the blocking problem.

 

My question: Is this exception too broad?  Is there a way to stop logging DFIShield incidents just for the specific scenario that is causing them?  

I'm not well-enough versed to understand what exactly is triggering the DFIShied (and why).  But I do resist turning off all security checking on a component that can interact heavily with public traffic and even public input.

Tuesday, 29 January 2013 07:26 CST

nicholas

The exception is necessarily too broad. This is because the URL does not specify a view. Normally, Joomla! components specify both a view and a task in their URL. Admin Tools' security exceptions are defined against a component, a view and a specific query parameter. Since there is no view, you have to specify a security exception against the entire component.

As to why DFIShield is triggered, what's the point? You're not the first to ask. You'll not be the first to ask the developer to fix that. You'll not be the first one to be told that the component is secure and no change is required. You'll not be the first to come back to me and ask me what he can do. And you'll not be the first one to be told to either use a different component or add a security exception for the entire component. You see the problem here, right?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 29 January 2013 07:44 CST

careytech

Yes, I see the problem.  I just wondered if you knew of a solution - partially because I'm sure you've dealt with this before.  

So when evaluating a call against the exception list, does AdminTool check hidden input values or just the values found in the URL?  (I ask because it seems that whatever is triggering it might have some hidden inputs.  And I ask because I like to learn how tools work so I can leverage them better.)

Tuesday, 29 January 2013 08:08 CST

nicholas

In order to really see what's triggering the protection you need to use something like Firebug or Chrome's Developer Tools to take a peek at the POST data of the request. Most likely you'll find a local (usually relative) file path in there, e.g. ../insecure/kind/of/coding.php or /home/myuser/public_html/this/is/a/mortal/sin.php. That's what is triggering DFIShield.

Here's the thing. If the developer is using a relative (with double dots) or absolute (with a drive name on Windows or starting with a slash on other OS) path he will trigger the DFIShield. That's the least of your problems. The biggest problem is what hidden behind that. The developer is using an unsafe practice which is well known to be prone to opening vulnaribilities in the face of the tiniest bit of bug in path handling. This kind of bugs is easy to make because the code is written by humans, who are prone to errors, hence prone to bugs. Moreover, absolute paths (if any are used) give out information about your server's and your site's folder structure. Allowing any of these to happen is considered a mortal security sin.

So, my advice has always been: if you have a component which triggers DFIShield, contact the developer. If the developer isn't interested in dealing with the problem, use a different component. For me it's security first.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 29 January 2013 08:28 CST

careytech

OK. I'll post a request on their forum.  As you said, I won't be the first, but if enough people post the same request, we can hope that they will reailize it is an issue to address.

EasyBlog is too good for me to ignore.  But I understand your approach of looking elsewhere when a component does not meet good practices.  For me, one of those important things is good ACL.  I refuse to give escalated privileges to a backend user group just because an extension does not care to implement adequate ACL - better to find an alternate component.  But I always let the developer know why I chose a different extension - if I don't them them why I'm leaving, they'll never realize the importance consumers place on ACL and security.

Tuesday, 29 January 2013 09:30 CST

nicholas

That's a good attitude and I have to applaud you on it. Very few people do that.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!