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 !
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.
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.
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.
you can use deny access on .htaccess on a folder with a php authentification that will redirect to those php file
Related
I have a use case where I need to be able to access my site from the local server. Specifically, it's for a HTML-to-PDF export of parts of various pages, but this would be nice for testing parts of the website as well.
The problem is that we have a login splash page, which needs to be dealt with before I can access any parts of the website. It would be really nice if I could just call a command "wkhtml2pdf 'localhost/[myurl]'" and have it PDF some stuff, but it hits this splash page.
Is there some way that I can perma-persist just one single session on the server? Or enable login-less access from localhost? Or could I just add a new Apache entry that accesses our site, whitelists only localhost and somehow circumvents the login?
What's the best solution?
You can pass your session cookie as parameter in wkhtml2pdf to solve your problem.
You can also execute it from a php file like this.
exec("wkhtmltopdf --cookie '{$cookieName}' '{$cookieValue}' http://example.com");
Soliciting feedback on this solution now:
I whitelisted localhost via $_SERVER['REMOTE_ADDR'] in the login scripts to bypass the usual user authentication and get an automatic localhost-user login. The server is running, however, on a university LAN, so the LAN maybe really big, possibly enabling bidirectional TCP spoofing.
Should I be worried about this, or does someone need admin rights on the routers or something? I trust the IT folks, but not others.
I realize that this sounds like a separate question, but I feel that security relates to whether or not this is a good solution.
I'm building an online dating website at the moment.
There needs to be an admin backend to the site to approve users/photos etc.
I can add this admin part of the site/login etc to the same domain.
eg: www.domainname.com/admin
Or from my experience with PHP CURL I can put this site on a different domain and CURL the requests through.
Question: is it more secure to put the admin code/site on a completely different domain? or it really doesn't matter if it sits on the same domain? hacking/security is the really point of this.
thx
Technically it might be more secure if you ran it from a different server and hosted it on a subdomain using a different IP/vhost, or use a proxy mod for your webserver (see Apache mod_proxy) to proxy requests from yourdomain.com/admin to admin.otherdomain.com and enforce additional IP or access control using .htaccess or equivalent to access the proxy url.
Of course, if those other domains are web accessible, then they are only as secure as the users and passwords that use them.
For corporate applications, you may want to make the admin interface accessible from a VPN connection, but I don't know if that applies to you.
If there is a vulnerability on your public webserver that allows someone to get shell access, then it may make it slightly more difficult to get administrative access since they don't have the code for the administration portion.
In other words, it can provide additional security depending on the lengths you go to, but is not necessarily a solid solution.
Using something like cURL is a possibility, but you'd have far less troubleshooting to do using a more conventional method like proxy or subdomain on another server.
Background
I'm looking for a transparent, PHP-driven authentication layer for a web site.
I'm aware of the following simple approaches:
HTTP Authentication
Mechanics:
Apache controls access rights;
Attempts to access any file in a given directory transparently require HTTP auth if not already authed.
Downsides:
Limited configuration options;
Difficult to integrate with existing user database;
No control over visual presentation of login prompt.
PHP-based login
Mechanics:
PHP controls access rights;
Attempts to access any file explicitly built for the system if not already authed will result in redirection to a login page.
Downsides:
If I forget to write the required include "login_required.inc.php"; or similar at the top of any PHP file, that file will be accessible by anybody.
What I want
I'd like to implement the PHP-based login solution, but to somehow configure Apache to invoke login_required.inc.php (or similar) transparently as an intermediate step when any PHP file is requested.
This script will:
run;
check session variables;
tell Apache either "yes, produce the requested page" or "no, redirect to the login page";
not require code to be inserted at the top of every PHP script that requires authentication.
Is this a pipe dream? Or can I do it? And if so, how?
If you rewrite all php requests through index.php, index.php/php would then control access to anything.
RewriteRule ^(.*)$ /index.php?pageid=$1 [QSA,L]
Something like that will push any request to index.php, in which you can do your authentication and then it will farm out the content...
The QSA in this will retain any query string parameters etc.
I think you should restructure you website to use a Front Controller. There's a reason that pretty much every framework uses the FrontController pattern: single point of access makes your app simpler.
One possibility is to use .htaccess ModRewrite to redirect all requests to, say, login_required.php?redirect=<ORIGINALLY-REQUESTED-SCRIPT>.
login_required.php can then perform its magic and do one of the following:
Present a login form
include <ORIGINALLY-REQUESTED-SCRIPT>.
Note that a header("Location: <ORIGINALLY-REQUESTED-SCRIPT>)"; will, I believe, merely fall foul of the .htaccess again and cause an infinite redirect loop! Setting the .htaccess ModRewrite directive to only conditionally redirect based on the value of HTTP_REFERER is not secure enough.
This is not the preferred solution, but it's a possibility...
Another possibility:
Have only a single entry-point. Just one file that's accessible from the outside world, like index.php?target=<REQUESTED-SCRIPT>. This one file can contain the authentication logic and include the required script.
All other files would be blocked from external access by .htaccess, or simple file permissions.
This is a good solution, but it would be a large change to update all URLs throughout the existing system.
Edit Apparently this is called the "Front Controller" pattern.
I have a demo server where I put samples of my apps, I send potential customers links to those apps. Is it possible to use htaccess to track visitors, without adding tracking capability to the apps themselves? The data I'm interested in are:
date and time of page visit
ip of visitor
url of the page visited
referrer
post and get (query string) data if any
That entirely depends on your webserver, what options it provides for htaccess overrides.
For Apache, the access log logs what you are looking for
http://httpd.apache.org/docs/current/logs.html#accesslog
but is not configurable via htaccess.
no, that's impossible to use .htaccess file, because it's merely a configuration file, not executable one.
However you can use another web-server capability - log files.
Everything you asking for is already stored in the access log, almost in the same format you listed here.
An important note: unlike google analytics or any other third-party or scripting solution, web-server logs is the only reliable and exact source of tracking data, contains very request been made to your site.
Best way it to use google analytics.
You will get all what you need and much much more.
I know this thread has been quiet for a while, but i it not possible to use the prepend?? directive that prepends a script to all visits to track site/page visits ?
I have not got the code (tried something similarthough was not successfull) but I used the prepend directive to prepend a script that "switches" on gzip for all site visits. I am sure the same can be implemented for logs (for those of us with cheap shared servers!) Come on coders, do us all a favour and reveal the secret!
I am creating a web service using php's SoapServer built-in class. I have run some basic tests and it seems to be working fine, but now I need to limit who can use the service.
Assuming that only other scripts on the same server are trying to consume my service, and that they would do this server-side (as opposed to with AJAX or similar means), does my service have any means of identifying the owner of the requester?
I could limit access the service to only requests coming from a specific origin, but this seems either very strict or very unreliable, depending on if I allow access to any script in a directory vs. only specific scripts.
I'm just not clear if I can limit access by the user on the server since the user that the original requesting script will be www.
here are some of your options:
as vivek mentioned, a key in the url could do the trick, i have used this many times, and it works nicely, and also allows you to monitor who's consuming the service (different consumers, different keys)
you could restrict usage of the scripts by IP. this is like the nuke of restrictions, i've seen it used mostly in places where service is granted outside the original server, but where a VPN would be an overkill.
of course, you may require full authentication, but this has too much overhead, both in terms of programming, and in terms of usefulness.
however, i must ask:
if only scripts on the same server are consuming the service, why make it a service at all?
if you have (unrestricted) pages that consume this (restricted) service, what's stopping anyone from scraping those pages - no matter how hard you protect the service?
You can always implement HTTP authentication against a data source of your choice. Apache has various options for doing Digest and Basic auth against a myriad of sources (we use mod_auth_mysql to secure a php webdav solution) but PHP also has good documentation about how to do it at the app level.
http://php.net/manual/en/features.http-auth.php
Why not just make the web service available on the localhost vhost?
Not completely water-tight, admittedly but relatively simple to implement.
Or on a vhost running on a firewalled port?
C.
You could use a registration key as most famous API's do, like weather bug....
so when a request comes in, you could check the the code and see whether the user has registered to use your API.