Peter H. Coffin wrote:
> On Wed, 31 Aug 2011 02:14:58 -0700 (PDT), jwcarlton wrote:
>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>> accesses?
>>> 1/. Write it in a proper language for this purpose, C, not php
>
> Won't gain much relevant. Compilation isn't even obfuscation, much less
> encryption. Run strings on a compiled c program sometime.
>
You miss the point completely: you want access to libaries about PIDS
and PPIDS that are not within PHP directly. Sure you can use system ) or
exec() calls, but since you probably need to write what amounts to an
extension anyway why use PHP in the first place?
And only if you are relatively crass would you encode as a string. If
you were worried about security.
There are many algorithms for generating strings and you would need to
examine the machine code and determine which one has been used.
For instance a single character followed buy a sequence of numbers which
have to be added sucessively to generate the lower 7 bits of an ascii
message is very easy to organise.
i.e 'a',1,1,1,1,1,1
becomes abcdefg
strinsg isn't a deal of use there
>>> 2/. Check the id of the parent process: compare that with running
>>> processes . If it ain't cron abort the program.
>
> Marginal. Are you 100% sure, though, that cron will always spawn it
> directly? On my host, it doesn't; cron spawns a process that sets up
> the environment, which then spawns the actual command in the cron job
> and accepts output for mailing back to the owning user, if any, then
> exists itself.
>
recursively trace the PID and the PPID to see what the last level below
init is.
> ----------------
> #!/bin/ksh
>
> echo "this process $$";
> echo "parent process $PPID";
> ----------------
>
> run by cron outputs
>
> ----------------
> this process 20206
> parent process 18169
> ----------------
>
> while cron is pid 547:
Thats cos its a shell script, not a c program,
>
> $ ps aux | grep cron
> ----------------
> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
> ----------------
> root 547 0.0 0.0 632 868 ?? Is 22Jun11 0:13.07 cron
>
>>> 3/. When you have it working, delete the source code.
>
> So you can NEVER MAKE CHANGES AGAIN! (Okay, yes, you can keep a backup
> elsewhere. Which makes it really easy to lose track of.)
>
That is the whole point. Doing things right is not for simple minded
fools who cant count beyond ten without taking their pink booties off.
Have a compile and test environment and a different run time
environment. And keep them separate.
>>>> I wouldn't mind encoding the page, too, JUST in case I have a root
>>>> breach (not expected, of course, but not impossible).
>>> That's the second reason to write it in C.
>>>
>>> Since I would
>>>
>>>> only need to encode one page, once, would it be reasonable to use the
>>>> free trial of Zend Guard? Or would you guys suggest something
>>>> different?
>>> Why not start with the right approach, instead of patching the wrong
>>> approach?
>>>
>>> I like PHP. But its not the only language in town and this is where I
>>> would definitely get out the C compiler
>> I think you make an excellent point, NP. It's been awhile since I've
>> messed with C and have forgotten more than I should, but I think
>> you're right that it's the appropriate language.
>>
>> In retrospect, I don't know if I've EVER coded in C. I think I started
>> in C++. Oh, well, it's not a big deal to go find a compiler and see
>> what I remember :-) "Hello World", here I come! LOL
>
> Best of luck to you. I hope you have the time to build the skills
> necessary for the job in the time you've got. (:
>
>> FWIW, Alvaro, I don't really have a problem, I'm just trying to
>> prevent one before it has a chance to happen :-) I figure that it's
>> better to tighten it up the best that I can in the beginning, instead
>> of trying to come back to it later. I'm more or less just playing with
>> this script right now, anyway.
>
> Preventing problems is a good thing to do, but using the simplest method
> to prevent the problem is the least likely to introduce other, shiny and
> new problems that you haven't already thought of. Stick with simple:
> secure the script written in a language you're already comfortable with
> to a single user, have cron run it under that user id, be done with it.
>
So says the carpenter who repaired the space shuttle with a six inch
nail and a club hammer.
|
Calendar
Search
Help
Members
Register
Login
Home
]