NYCPHP Meetup

[nycphp-talk] HTTP_REFERER

Michele Waldman mmwaldman at nyc.rr.com
Fri Nov 28 15:36:15 EST 2008


I don't keep passwords in a web accessible directory.

 

My current php module is part of ajax, unless you make a function call the
php module does nothing.

 

Doesn't errordocument do basically the same thing as the following?

 

<IfModule !php_module>
    Deny from all
</IfModule>



If they try to access a non existence module I just display an error
document.  That would through an error?  Right?

 

Michele

  _____  

From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Elijah Insua
Sent: Friday, November 28, 2008 3:23 PM
To: NYPHP Talk
Subject: Re: [nycphp-talk] HTTP_REFERER

 

Oh! sorry to be so short with my other mail.

Generally when you request a php file on a php enabled web server the code
is executed and output is returned.

In essence this means that if you are returning text ie: <?php echo "hello
world" ?> instead of the execution result ie: hello world
you quite a serious problem on your hands (especially if you include your
passwords and such in a web accessible directory).

A way around this would to do something like (in .htaccess) ...

<IfModule !php_module>
    Deny from all
</IfModule>

Which basically says, if the php module is not installed.. throw a "Access
Denied" error to the requestor.

-------

As far as locking the user into a specific domain, I would reccommend you
use php sessions.  In which
case you can force a cookie to work for a specific domain.  If the user
attempts to create a cookie manually
it wont work as they would have to guess an active session id.

This breaches on the topic of Cross Site Scripting, but sessions should be
good enough for your needs.

-- Elijah



On Fri, Nov 28, 2008 at 3:04 PM, Michele Waldman <mmwaldman at nyc.rr.com>
wrote:

Could ya'll repost any responses to this.  Apparently, my new email address
wasn't subscribed to the mailing list.

 

  _____  

From: Michele Waldman [mailto:mmwaldman at nyc.rr.com] 
Sent: Friday, November 28, 2008 2:19 PM
To: 'NYPHP Talk'
Subject: HTTP_REFERER

 

I once had a problem with my server executing php and the code was dumped
out to the screen.

 

So, php isn't that terribly secure if your server has a glitch.  So many
folks put their passwords right there in a file that can be dumped to the
screen.  

 

In my current case I am using ajax because xmlhttp doesn't cross domains, I
didn't have a real security risk I believe from users call the php file
directly with data.  There would have to be a function call to execute the
php.  Without someone calling a function, nothing would happen.

 

If someone remotely embedded my php file remotely in their app, they could
have made a function call if they knew the name?

 

What does anyone know about linking a php file from another server?  I
haven't really tried it.  I don't think.  That would be my real concern.

 

The php.org docs say the http_referer can not be trusted.  Plus, I didn't
even see it defined in my phpinfo.  I don't know if it's only defined if
there is an explicit statement to do so.  Do you know another way of
requiring that some php files are only called by an app in the same domain?

 

I'd like to either prevent a remote call to my php file in htaccess.  I was
thinking something like:

 

RewriteEngine On

RewriteCond %{HTTP_REFERER} !^http://(.+\.)?wantedgaming\.com/ [NC]

RewriteCond %{HTTP_REFERER} !^$

RewriteRule .myfile\.php$ stub.php [L]

RewriteRule .myfile2\.php$ stub.php [L]

RewriteRule .myfile3\.php$ stub.php [L]

 

I was thinking I wanted to reinforce this inside the php file, but if
htaccess has it covered, it's probably a non-issue.

 

Does this look right?

 

Michele


_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/show_participation.php

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20081128/5be2de82/attachment.html>


More information about the talk mailing list