Take the restricted script out of your web path entirely. Call it as a script from your web executables. Never use any security approach that relies on the referrer, it's not secure.
| [reply] |
Thanks guys, all your responses were very helpful!
| [reply] |
Simple, works for general case (but fakable) - check HTTP_REFERER environment variable.
More complex, works for all - have script A send a signed request, and have script B only run if that request is valid. There are many ways to do this - the best will depend on the environment you're coding in. Eg, Mojolicious has built in signed cookies, for example.
| [reply] |
I guess a better way of saying what I'm looking for is a 'conditional redirect'. I already have it looking at the HTTP_REFERER, so it will only run from my domain. However, I want it to only run from a specific script on my site, and if run without that script, I want it to redirect to an error page.
| [reply] |
The other Anonymous Monk and cLive;-) already gave you the answer, but didn't tell you how to implement it. An easy (though not entirely foolproof) way to do it is have each script that is allowed to call it pass an additional "password" parameter. The restricted script then receives that input and checks that it's valid before proceeding. It's reasonably secure because it's getting passed within your server, and the user will never see the required parameter list to make the restricted script work. Someone could, in principle brute force it, but if you pick a long random string the time required is long. It's probably essentially the same code you're already using with the HTTP_REFERER, but with a different parameter, and the calling scripts have to send it explicitly. There are various ways to make the brute force attack less economical by increasing the time required per call by a small amount- any single call will barely notice, but it adds up when you're doing a lot of them.
There may also be some complicated way you can do it by setting permissions so that your www user (or whatever your server runs as) isn't allowed to call it, but then the scripts that can call it can sudo to be a user with the correct permissions. This seems like a sketchier approach to me, since it probably uses system calls and may expose you to other security risks in less predictable ways.
EDIT: Your Mother's approach is better than either of the above.
| [reply] |
password protect the "script", problem solved | [reply] |
