views:

54

answers:

3

There is this PHP script on my website which I don't want people to be able to run by just typing its name in the browser.

Ideally I would like this script to be run only by registered users and only from within a Windows app (which I will have to provide). Can this be done ?

Alternatively, how can I protect this script so that it can only be called from a specific page or script?

Also how can I hide the exact URI from appearing on the address bar?

Thanks !

+3  A: 

If you are running Apache for your webserver, you can protect it with a username/password combo using .htaccess. It takes a little configuration if your server is not already configured to allow .htaccess. Here are the Apache docs.

If you need authentication based on application-specific factors, you can put something at the top of your script like

<?php
  if(!$user->isLoggedIn()) {
    // do 404
    header('HTTP/1.0 404 Not Found');
  }

Do you have a question about how you would implement isLoggedIn?

You can also use mod_rewrite to rewrite URIs, and those directives can go inside your .htaccess as well. mod_rewrite can rewrite incoming requests transparently (from the browser's perspective) so a request for /foo/bar can be translated into secret_script.php/foo/bar. Docs for mod_rewrite.

However you decide to implement this, I would urge you to not rely solely on the fact that your script's name is obscure as a means to secure your application. At the very least, use .htaccess with some per-user authentication, and consider having your application authenticate users as well.

Jesse Dhillon
+2  A: 

As Jesse says, it's possible to restrict your script to logged in users. There are a large number of questions on this already. Search for PHP authentication.

However, it is not possible to restrict it to a single application. It is fairly simple to use a program like Wireshark to see exactly how the program logs in and makes request. At that point, they can reproduce its behavior manually or in their own application.

Matthew Flaschen
Seconded, thirded and fourthed.
Jesse Dhillon
You could employ various levels of encryption and request signing at various stages to ensure that only a client that possesses a certain secret can make requests. From there it depends in what environment that client is running. If all parts are being properly secured, spoofing requests can be subverted, or at least made very impractical. That's a lot of ifs though. :)
deceze
In the theoretical and fairly ridiculous situation :) that we've got going on here, you still have to reckon with the fact that your secret would be stored on a machine that is not under your control (the user's).
Jesse Dhillon
+2  A: 

There are a variety of different ways that you could go about securing a script. All have pluses and minuses, and its likely that the correct answer for your situation will be a combination of several.

Like mentioned, you could lock down the account with Apache...it's a good start. Similarly, you could build a powerful 'salt-ed' security system such as this: http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-An-ObjectOriented-Approach/ If you use SSL as well, you're essentially getting yourself security like banks use on their websites--not perfect, but certainly not easy to break into.

But there are other ideas to consider too. Park your script in a class file that sits inaccessible via direct URI, then do calls to the various functions from an intermediary view script. Not perfect, but it does limit the ways that someone could directly access the file. Consider adding a "qualifier" to the URL via a simple get--have the script check for the qualifier or fail....again, not a great solution on its own, but one additional layer to dissuade the bad guys. If you have control of who's getting access (know exactly which networks) you could even go so far as to limit the IP's or the http referers that are allowed to access the file. Consider setting and checking cookies, with a clear expiration. Don't forget to set your robots file so the browsers don't stumble upon the script your trying to protect.

A while back my company did a membership app using Delphi on the front end, talking to php and MySql on the backend....it was a bit clunky given that we were all web application developers. If you're so inclined, perhaps Adobe Flex might be an option. But ultimately, you'll have to open a door that the application could talk to, and if someone was determined, theoretically they could dig through your app to find the credentials and use them to gain instant access to the site. If you're going the desktop app route, perhaps its time to consider having the app avoid talking to an intermediary script and do its work on the local machine, communicating the db that sits remote.

bpeterson76