Not a bug Variable debugging is not available in development / debug mode

[kick]

Affected version

2.1.4

As for me, to leave a function that allows you to debug variables that are not available in development / debug mode is a source of security problems. It is enough to insert into any template with the condition by nickname and receive the same data from the database without problems. That allows kidnappers a faster way to access. just do an example {{ dump ($xf)) }} and go down lower and lower. We can immediately write and receive data {{ dump ($xf.app.config.db) }} from the database. Thus, an administrator, another administrator or user, does not need to have access to ftp at all. Since he already has access in his hands. For good, this function must be disabled if the development or debugging mode is turned off.

 

[Chris D]

This isn't a bug. If you give someone access to templates it is feasible that they can inject all sorts of nastiness into your templates. They can inject JS code which harvests cookies, or passwords and, indeed, it gives them access to echo out config variables or perform (usually) read only queries.

It's a matter of ensuring that admins have access only to the functionality that they need.

 

[kick]

Really? This is just a serious vulnerability, and well, if you understand what you are giving to a person or you really have a real team assembled. But you do not know that every person in the head and at any moment he may want to do a dirty trick. And okay, this is all the lyrics. Additions to XenForo can also contain XSS vulnerabilities and even in XenForo they are. And what will this vulnerability give us? But the fact is that XenForo contains a session identifier in the cookie and there are scripts thanks to which you can log in using the session identifier as an administrator. It is enough for the user to find the vulnerability due to which he will receive this session further and will be able to further go to the database thanks to this magic function that will open him access. When this feature is available in development or debugging mode then this will reduce the attacker's chances of gaining access.

 

[Kirby]

While I do agree with @Chris D that limiting dump() to be only available in debug mode doesn't add much security in terms of protecting against malicious humans, it would indeed add a layer of complexity to protect against mistakes.

Assume an Add-on developer accidently left debug code in of the templates, this could place all users of the affected Add-on(s) at risk.
Does anyone remember the vBulletin faq.php database credentials leak?
This is exactly what could happen and limiting dump to debug only would limit the surface of such oversights.[/icode]

 

[kick]

@Kirby, This also happens and processing it in non-debugging or development mode will simply create problems. Hacking development options with an open function will make it much easier for an attacker to gain access

 

[Lukas W.]

Alright, so if I can't use dump() anymore to "hack myself through the variables", then I'll just use {$xf|json|raw} and get a nicely printed JSON object instead. As the core software isn't a big black box either, I could also just - which a little bit of knowledge - go ahead and print whatever I am looking for directly. If it was worth to me, I even could buy a license and find them in debug mode on my own install, then go and have them printed on the production site, given I had the access.

Ultimately it always comes down to the malicious person having access to the templates in the first place. It is the same with having FTP/file access. If you cannot 100% trust them on that, then don't give them template edit rights. Disabling dump() does not achieve anything in a security context here.

 

[Kirby]

Disabling dump() does not achieve anything in a security context here.

Well, one could say the same about automatically escaping variables (unless outputted as raw) - it is always possible to output them as raw.
Yet this is being done because it is a) convenient and b) does reduce the likeliness of a developer forgetting to manually escape a variable.

So in a nutshell:
Would this help against malicious users? No.
Would it help against mistakes that could lead to accidental data leaks? Yes.