Radicore Forum: Framework » OWASP standards vs. Radicore Framework

Home » RADICORE development » Framework » OWASP standards vs. Radicore Framework

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

OWASP standards vs. Radicore Framework [message #120]

Thu, 29 June 2006 11:32

andy
Messages: 7
Registered: June 2006
Location: Reno, NV, USA

Junior Member

Greetings,

Finally I have the opportunity to review this full release of the Marston web framework. I've been busy working with Python the last few months, giving me a new perspective on things Shocked

.

Q: Recently I was taken to task for using extensions such as ".inc" rather than standard ".php". The problem, related to OWASP security recommendations for php applications, is that if your server is not configured correctly then .inc files will dump as plain text to the browser. This is a potential security hole. The premise of OWASP philosophy, for background here, is that one should never trust a server configuration. Being that web application code can be deployed on any server, many of which will be hosted and of course the developer may very likely have no influence on server (Apache) configuration settings.

Wondering why this framework code still uses the ".inc" extension?

Shouldn't the OWASP recommendation be heeded?

Report message to a moderator

Re: OWASP standards vs. Radicore Framework [message #121 is a reply to message #120]

Thu, 29 June 2006 11:48

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

I use the .inc extension to indicate that that a file can only be included and not executed in its own right. This is an important difference to most people.

I include in my installation instructions the means to tell Apache not to allow access to any files which end in the '.inc' extension.

Even if these instructions were to be ignored there should be no security issues as all the critical .inc files are held in a directory which is outside the web root and are therefore totally inaccessible even if Apache were to be mis-configured.

Those .inc files which are not outside the web root are in their own separate directories which could easily be password protected or set to be inaccessible via the web server.

The OWASP recommendation does not take these other options into account, so the "security hole" is not as bad as they would make out.

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Re: OWASP standards vs. Radicore Framework [message #122 is a reply to message #121]

Thu, 29 June 2006 12:09

andy
Messages: 7
Registered: June 2006
Location: Reno, NV, USA

Junior Member

Hey Tony,

you are on top things, that was one fast reply Surprised

I am onboard with using extensions to differentiate file usage, it makes sense to me. However, my employer (as a company) is security paranoid (obsessed, maybe).

Your instructions do clearly layout the usage of non-web path placement of the includes folder.

But nonetheless, one must consider the programmers daily battle against the "idiot factor". Even that the idiot may be the next developer, who may not configure a server correctly.

I don't quite get this point,

Even if these instructions were to be ignored there should be no security issues as all the critical .inc files are held in a directory which is outside the web root and are therefore totally inaccessible even if Apache were to be mis-configured.

... when I did a simply unzip and drop into my web root, the "includes/config.inc" is readily viewable. The only thing stopping a text display of the is the .htaccess setttings.

IF (the bit about .inc files is omitted)you_have == trouble;

Don't get me wrong, I'm not trying to bash. I'm a fan of your work, have been for some years now. Just seems to me that by using the .php extensions, with entry point checks (not to get off on a tangent) one could have a framework that is secure regardless of server configurations.

Report message to a moderator

Re: OWASP standards vs. Radicore Framework [message #123 is a reply to message #122]

Thu, 29 June 2006 13:17

AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK

Senior Member

By default the INCLUDES folder in the zip file is within the same directory as all the other files for the simple reason that the unzip facility can only create a single directory structure. I cannot force the INCLUDES folder to be outside the web directory, but I do advise it when the software is installed on a publicly-accessible web server.

You must also bear in mind that the software is a development tool and should be installed on a development server to begin with. When developing and testing on either of my two Windows PCs, a desktop and a laptop, the INCLUDES folder is not outside the web root, but this does not cause a security issue.

I assume that developers who are going to deploy software on a publicly-accessible server are aware of all the security implications and know what steps to take. It is not my responsibility to educate developers on how to configure and use a web server, how to configure and use PHP, or how to configure and use a DBMS. I assume they already have this knowledge.

I should also point out that if a web server is mis-configured enough to send back a .inc file as plain text it can also do the same thing to a .php file. Any file which is accessible to the web server has the *potential* to be sent back without being processed, so if your web server is mis-configured you are likely to spot it very quickly. Saying that it only applies to .inc files is a little naive.

Tony Marston
http://www.tonymarston.net
http://www.radicore.org

Report message to a moderator

Previous Topic:	metadata vs. business logic
Next Topic:	Framework Version

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Jul 05 03:10:29 EDT 2025

Total time taken to generate the page: 0.19224 seconds