开发者

index.php and protecting of its content

What are the chances hackers are able to download index.php file from the server (not the result, but the content of index.php file)? Do you recommend to put the content of index.php开发者_高级运维 to modules/index_content.php, where modules folder is .htaccess protected AND index.php contains the only string <?php require_once('modules/index_content.php') ?> ? Does it make sense?


Source code disclosure can happen on a well-configured server and is not as rare as you might think. As the others have said, if your server-configuration is sound, then there won't be a problem with people requesting PHP files directly.

However you could still be vulnerable to:

Script Source Accessible through Backup

Many editors leave backup files with common file extensions, such as ~ or .bak. Your server may not run these through the PHP interpreter as they are commonly configured to do so by file extension. Leave these backup files around and you could be disclosing your source.

Local file inclusion

There can also be a problem if you have a webapp that uses user-input to read other files. If the script is not validating the user input correctly, it could be vulnerable to LFI. Scripts such as these should only read whitelisted files, or at a minimum be restricted to a certain directory. If "../" is accepted, then you have a Directory Traversal vulnerability which will exacerbate the above two vulnerabilities to be even more serious.

Add to this, many servers have enabled

Directory Browsing

which is when your server will list the files in a directory if a default file is not present (index.html, index.php, default.htm etc.). This won't disclose any source in its own right but does allows many of the files (server-side processed or not) on the server to be enumerated to the malicious user, making it very easy to focus further attacks.

Source disclosure via alternate server

Another accidental scenario can be when two web servers are pointed (perhaps indirectly) at the same document root. If one of the web servers is not configured to process PHP, then the source can be disclosed. I have seen this happen by accident a number of times when a web-server is configured to reverse-proxy to a chained app-server for certain URL patterns (usually by directory). e.g. have Tomcat handle everything under /forum.

SQL injection

Pretty much every serious DBMS has a function that allows it to read files on the system. If you don't protect your database inputs (please just use parameterised queries) you may be vulnerable to source code disclosure through this mechanism. Mind you, in this scenario, source-code disclosure is your last concern.

I'm sure there's loads of others, but these are some of the most common ways I see this kind of disclosure. Just remember that security is a process and is wide-ranging in its scope. Often it is the interaction of concerns, systems or applications that were treated as separate entities that causes the problems.


If *.php files are being treated as PHP files by Apache (i.e., rendered as normal), then no, they can't access the source, at least not without access to the server through some other script or means (in which case adding the script to modules/index_content.php won't make a difference).


It has no sense.

If anyone has an access to your index.php source, he has also access to all of included files' sources.


There is no way for a .php file to be downloaded through http, assuming that your server configuration does not change (e.g the handler for PHP files is removed). If this does happen, then it is possible that .php files could be downloaded as plain text files.

You should put all core files outside of the public directory (public_html, htdocs etc.) and call them using their path.


They can't download php files if you have setup PHP on your webserver.

As a note: protecting with htaccess the folder modules and in index.php you are including a file from that folder when someone is accessing index.php they will have to provide a password and username to access the included file.


Chances are null. Two big exceptions though:

  • "Lost" machine (through SSH, FTP, etc,...)
  • Human mistake: If you have a script that reads files, be sure it can't be used to read your php files.
0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜