+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Development Area (/forum-1.html)
+--- Forum: Suggestions (/forum-2.html)
+--- Thread: Probably a security hole! (/thread-10093.html)
Probably a security hole! - koko92_national - 03-20-2010 11:34 PM
Log on in the panel as a client and then enter in the url:
themes/omega_original/admin/index.tpl
Notice that you can see the admin templates! I'm not sure if this is a security hole but still it is not right to look at the admin templates.
RE: Probably a security hole! - Nuxwin - 03-20-2010 11:53 PM
Hello ;
It's not a security hole because that is not a real view script but just a template that contain replacement variables. But right now, the better is to hide the raw content of these.
Best Regards
RE: Probably a security hole! - kilburn - 03-21-2010 07:59 PM
Maybe we could add an .htaccess in the "templates" directory, stating:
Code:
deny from allRE: Probably a security hole! - Nuxwin - 03-21-2010 08:13 PM
Hello Marc ;
Why not, but we can also act as Zend no ?
RE: Probably a security hole! - kilburn - 03-21-2010 08:39 PM
I don't know what you mean by "acting like Zend" nux :?
RE: Probably a security hole! - Nuxwin - 03-21-2010 08:54 PM
Sorry Marc :
Separate public directory for reachable files (css, images, js, index.php) and all others not inside the DocumentRoot.
RE: Probably a security hole! - ephigenie - 03-22-2010 10:18 PM
+1 for this - this would be a much better approach (no non-public visible files & libraries below document_root )
RE: Probably a security hole! - kassah - 10-31-2010 02:29 AM
it's not a bad idea, I've always wondered about programs constantly putting their code in /var/www/ which is the default root directory of most apache servers by default. I would think this would be a liability if somehow the configs got reverted to package defaults without PHP (thus showing off php sources). I'd have to look it up, but I'd swear there was a case made public on slashdot where a company's records were put up for all the public to see because of a similar error to the case presented in my post.
This is why I've always used /srv for that, I have no idea if that's the "proper" use of that directory. It could be I'm ignorent and it's apart of the LSB spec.