I am having a problem. I have this code:
$theUrl = $_GET["url"];
include("$theUrl.php");
This gets the url, for example: http://mywebsite.com/index.php?url=test
But what if someone puts in:
http://mywebsite.com/index.php?url=http://theirwebsite.com/someEvilscript
How to avoid this? I want only scripts that i have on my server to be executed and not from other websites. Thanks for help.
One of the good way to handle this is to define a white list of file that can be included. If anything isn't in that list, it should be considered evil and never included.
For example :
<?php
$allowed = array('file1', 'file2', 'file3');
if (in_array($_GET["url"], $allowed)) {
// You can include
} else {
// Error message and dont include
}
?>
Note : As suggested in the comment, the allowed list can be populated dynamically by scanning allowed directory.
You really shouldn't have any code that looks like that. And I mean really. What are you trying to achieve with this? I'm sure there's another way to the same without the risks (and let's say general uglyness).
Like HoLyVieR suggests, whitelisting what can be included is the key to making your current code safe.
Why don't you just create test.php on your site, and use http://mywebsite.com/test.php in the link? This way you can include your initialization script in test.php (and in the other scripts) if needed.
Related
i have a php code for my website and a friend told me that my code has a local file inclusion vulnerability because im using the " include " method.
can someone help me in fixing it or lead me to where i can find help? i tried a couple of possible ways of fixing it but that didn't work.
the problem is with including the language file in my code.
here is the code below to be more clear :
<?php
if(isSet($_GET['lang']))
$lang = $_GET['lang'];
else $lang='en';
include 'languages/'.$lang.'.php';
include("header.php");
?>
P.S i only have 2 language files and they are English = "en.php" and Arabic = "ar.php"
i would really appreciate it if someone could help.
Do not EVER trust user inputs!
<?php
if ( isset($_GET['lang']) && $_GET['lang'] == 'en') {
$lang = 'en';
} else {
$lang = 'ar';
}
include 'languages/'.$lang.'.php';
include("header.php");
?>
Or, preparing for possible additional languages, I would go like this:
<?php
$lang = !empty($_GET['lang']) ? $_GET['lang'] : 'en';
switch($lang) {
default:
case 'en':
include 'languages/en.php';
break;
case 'ar':
include 'languages/ar.php';
break;
}
include("header.php");
?>
This way you can easily add extra languages later on and also always make sure, that only the required file is included.
The vulnerability is that one could send any kind of relative path in $lang. This is especially dangerous if users can upload files and figure out their real path on the server.
Example:
A hacker may use some file upload functionality of your site to upload evil.php. The hacker may know/have found out/guess that it's stored at /var/www/uploads/evil.php, and that your application runs in /var/www/html.
Now, normally nobody could run this file if /var/www/uploads is not accessible through HTTP.
But, it would be possible to open http://example.com/index.php?lang=../../uploads/evil and guess what, it would include languages/../../uploads/evil.php which would resolve to /var/www/uploads/evil.php!
This of course also works without file upload if there are any other files which can be used for exploiting something by getting access to them and calling them, such as maybe files in a normally password-protected directory (phpMyAdmin for example).
And if you now think "that's quite a lot of assumptions and 'may's and 'if's in there, you would need to be very lucky to succeed with this" then watch out - although there are some obvious blatantly open vulnerabilities where you do one URL call and you can, let's say, overtake the server or delete the database, the most dangerous ones are the ones which require multiple puzzle pieces to make an exploit work, because they go undetected for a long time and it can be hard to understand how the server got actually hacked once it happens, and you will naturally have a more experienced and therefore more dangerous (possibly stealth) hacker at your doorstep. If somebody is determined to find a security hole (either because they have an actual goal attacking your site or you, or because they just enjoy owning poor webmasters to push their own ego), they will keep searching and puzzle together whatever is required to achieve what they want.
There are multiple solutions.
As suggested by u_mulder, if you have only ar and en then just check if it's either one.
If you have more languages, you could just create an array with a list of allowed values and check if the sent language is in that array, for example:
$languages = ['de', 'en', 'ar', 'jp', 'fr'];
if(in_array($_GET['lang'], $languages)) {
$selectedLanguage = $_GET['lang'];
} else {
$selectedLanguage = 'en'; // default
// Note that you could also show an error "invalid language" instead
}
If you want to control this by just allowing only the files existing in the folder, you could also just validate that the language contains only letters (or whatever you need, as long as you make sure it may not contain dots or slashes or such):
if(preg_match("/^[a-z]*$/", $_GET['lang'])) { ... }
Note that with this approach you should definitiely also check if the specified file exists, otherwise it would still be possible to have a language-less site by specifying an invalid language (especially since include doesn't throw an error on non-existing files, unlike require).
What I am trying to do is change a variable in fileb from filea. Kind of like using fileb as a config file in a way.
Example:
File A:
require_once "fileb.php";
if($power == 'off') {
exit;
}
if($test1 == 'one') {
echo "The first option is selected";
} elseif($test1 == 'two') {
$power = 'off';
}
File B:
$power = 'on';
So in this example a user id prompted for $test1, if they reply with "one" they get a echo. What I want to do is make it so if they reply with "two" it shuts down the page, and not just for them but for everyone. I am trying to do all of this without using a DB, that would be too easy lol. Thanks for the help!
I am trying to do all of this without using a DB, that would be too easy
There's a reason using a database for this is easy. It's the correct way to accomplish this task. Modifying actual PHP code files is a famously bad idea. (And one that somebody on Stack Overflow has almost weekly, it seems.)
If you include the file as part of the executing code, you can use the variable as any other. This allows you to manipulate the variable in a transient way, but not manipulate the code which creates the variable.
What you're trying to do is persist that changed variable. In order to do that, it needs to be written somewhere outside of the application. Databases are really good for that sort of thing. You could also write to a simple text file (a string of text, structured XML, etc.) though in that case you'll have to manually watch out for concurrent writes and other such errors. (Databases are really good at that too, which makes them ideally suited for multi-thread/multi-user applications like web apps.)
I suppose you could treat the PHP file itself as an editable text file like any other. (Since PHP is, after all, just text.) But, again, that's a really bad idea. For one thing, parsing out exactly the value you want and writing back a change only to that value is going to be very difficult. Also, you run the risk of breaking a file which is treated as executable code which opens up all sorts of potential risks.
Just write to a database, or to a file, or to any other simple data persistence medium outside of the application.
Your fileb is lacking the <?php ... ?> tags. Without those, you "code" is never seen as code. it'll just be treated as plain text.
file b:
<?php
$power = 'on';
file c:
Hello
<?php
$foo = 'world!';
file a:
<?php
include('fileb.php');
echo $power;
include ('filec.php'); // "Hello" is immediately output
echo $foo; // tell PHP to put the $foo var, which will print out "world!"
OK, so I have searched around for long enough to finally post this one here. Sure enough, it has been asked before a zillion time...
What I have, is one file, which includes another. No magic here. The trouble is, the included file then includes another file, which... includes yet another... Yep, a pain. Actually it's all working quite nicely, except that I now wanted to read the URL of the original file in the last of the included files.
So I thought in the original file, file_1.php I just say
$var_foo = dirname(__FILE__);
or
$var_foo = $_SERVER['SCRIPT_NAME'];
and then read that value in the first include, file_2.php, passing it on like
$var_foo_2 = $var_foo;
then in file_3.php
$var_foo_3 = $var_foo_2
etc, until I arrive at the final file, file_4.php, where I'd like to know the exact value of the original file's URL. Passing it on the first level works OK, but then it gets lost somewhere along the way. Tried going GLOBAL in file_1 -- to no avail.
Since file_3 and file_4 must both execute to produce data, setting a breakpoint a la echo / exit to spoof the current value (if any) is no option. I can live without that particular value, but I just would like to have it -- for the fun of it... Any ideas how to accomplish this?
Your examples use filesystem paths, not "URLs";I am assuming the filepath of the parent file is what you actually want.
You don't need to "pass" the variable on each included page. It will automatically be available to the code on the new page.
(If it is not, you may not be in the right scope: e.g., if you're inside a class or function, you'll need to pass it deliberately or use some other method - global, maybe, or even define the filename as a constant instead of a variable.)
main script
$parent_filename = __FILE__;
// alternatively
// define( 'PARENT_FILENAME',__FILE__ );
include "other-file.php";
other-file.php
include "other-dir/somefile.php";
other-dir/somefile.php
print $parent_filename;
// alternatively
// print PARENT_FILENAME;
/* prints something like:
/path/to/main.php
*/
As mentioned before, the issue has been solved like so:
set variable before the first include
add variable to query string
Thanks all for the input, appreciated.
I want to make a programming environment. I will explain it with an example.
One programmer will write that code;
<html>
<head>
<?php definedMetaTags(); ?>
</head>
</body>
Programmer will save this file and then upload to my system. That file will be executed at server side and then they system will turn generated code back.
That definedMetaTags() function will be already written in the system.
An example of Compiler.php:
<?php
require_once("definitionsForProgrammer.php");
include("uploadedfile.php");
?>
My question is that I want to allow that uploadedfile.php only what functions I want. Else, maybe that programmer writes some codes what I want him/her to do. (Deleting files, mysql connection, etc.)
Is there any way to allow a code only specific functions, variables, constans?
If the goal is to allow a user to insert placeholders that will be replaced by some PHP function execution, then there's no need to treat the uploaded file as PHP code:
<html>
<head>
{[definedMetaTags]}
</head>
</body>
Then Compiler.php would look like this:
<?php
require_once("definitionsForProgrammer.php");
$macros = array();
$macros['definedMetaTags'] = definedMetaTags();
$output = file_get_contents("uploadedfile.php");
foreach($macros as $macro=>$value) $output = str_replace("{[$macro]}", $value, $output);
echo $output;
?>
The definedMetaTags() function would need to be reworked so that it returns the tags as a string instead of printing them directly to output.
This method would allow you to define any number of macros without exposing yourself to all the security risks the others here have mentioned.
If you're aiming for security and you want to let them to write functions, then the short answer is: no.
Essentially you're asking for a PHP sandbox which will let you constrain what code can be executed. PHP would have to support this at a fundamental level for it to work. For example, supposing you took the approach of saying "I only allow the user to write a function named 'foo'". Inside that function, though the user can do all kinds of bad things like making system calls, downloading other code and executing it, etc. In order to prevent this you'd need to implement checks at a much lower level in the system.
If you're willing to restrict the scope only to variable definitions then yes you can do it. You can use token_get_all() and token_name() to examine the file to make sure that it doesn't have any code that you don't want in it. For example:
foreach (token_get_all(file_get_contents("uploadedfile.php")) as $token) {
if (is_array($token)) {
echo token_name($token[0]), " ";
} else {
echo $token;
}
}
If you don't like any tokens you see, don't include the file. You could theoretically guard against bad functions this way as well, but it'll require a fair amount of effort to properly parse the file and make sure that they're not doing something bad.
references:
http://www.php.net/manual/en/function.token-get-all.php
http://www.php.net/manual/en/function.token-name.php
http://www.php.net/manual/en/tokens.php
Well, if i'm understanding your question correctly. If you include("uploadedfile.php"); you will acquire everything in it.
What you could do is break your code up into related sections (whether it be via classes or just function definitions in a file) then only include the file/class that you want.
(let me know if that's not what your asking)
Is there any way to safely include pages without putting them all in an array?
if (preg_match('/^[a-z0-9]+/', $_GET['page'])) {
$page = $_GET['page'].".php";
$tpl = $_GET['page'].".html";
if (file_exists($page)) include($page);
if (file_exists($tpl)) include($tpl);
}
What should I add to make this pretty safe?
I'm doing it this way bacause I don't like having to include stuff that has to be included on all pages. The "include header > content > include footer"-way. I don't wanna use any template engines/frameworks neither.
Thanks.
The weakness in your current implementation is that …
the regular expression just tests the beginning of the string, so “images/../../secret” would pass, and
without further validation, “index” would also be a valid value and would cause a recursion.
To make your implementation safe, it’s a good practice to put everything, that’s intended to be included, in its own directory (e.g. “includes” and “templates”). Based on this, you just have to ensure that there is no way out of this directory.
if (preg_match('/^[a-z0-9]+$/', $_GET['page'])) {
$page = realpath('includes/'.$_GET['page'].'.php');
$tpl = realpath('templates/'.$_GET['page'].'.html');
if ($page && $tpl) {
include $page;
include $tpl;
} else {
// log error!
}
} else {
// log error!
}
Note: realpath returns the absolute path to the given relative path if file exists and false otherwise. So file_exists is not necessary.
Despite what you stated about not wanting to store a list of available pages in an array it is likely going to be the best, non-db, solution.
$availFiles = array('index.php', 'forum.php');
if(in_array($_GET['page'].".php", $availFiles))
{
//Good
}
else
{
//Not Good
}
You could easily build the array dynamicly with either DB queries or by reading a file, or even reading the contents of a directory and filtering out the things you don't want available.
You should never use user supplied information for includes. You should always have some sort of request handler that does this for you. While a regular expression may filter somethings it will not filter everything.
If you do not want your site to get hacked you do not allow your users to control the flow of the application by designating an include.
I agree with Unkwntech. This is such an insecure way to include files into your website, I wish PHP programmers would do away with it altogether. Even so, an array with all possible matches is certainly safer. However, You'll find that the MVC pattern works better and it is more secure. I'd download code igniter and take a tutorial or two, you'll love it for the same reason you wanna use dynamic includes.