Deploying Standalones/Prevent Malicious Code
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Deploying Standalones/Prevent Malicious Code
Hello All,
I've been thinking deployment strategies and I've come across a question I can't find an answer to.
The deployment method I'm leaning towards is multiple "Main" stacks where one is the executable and it uses the other (.rev) stacks. I believe this is similar to how RunRev deploys the IDE as I've noticed .rev files in, for example, the Toolset folder (such as revdatagridlibrary.rev). I'm attracted to this method because of the ability to more easily update "components" of the application.
So, I would have, for example, MyRevApp.exe and BaseControls.rev as my two files to deploy. Now, I know I can password protect stacks to keep people out of them, but what is to keep someone from creating some malicious code, naming the stack BaseControls.rev and dropping it into the folder my app is deployed in. When I "start using" BaseControls, the malicious code will be executed.
Is there a way to verify a stack is really my stack before I trigger any code in the stack?
Thanks in advance,
I've been thinking deployment strategies and I've come across a question I can't find an answer to.
The deployment method I'm leaning towards is multiple "Main" stacks where one is the executable and it uses the other (.rev) stacks. I believe this is similar to how RunRev deploys the IDE as I've noticed .rev files in, for example, the Toolset folder (such as revdatagridlibrary.rev). I'm attracted to this method because of the ability to more easily update "components" of the application.
So, I would have, for example, MyRevApp.exe and BaseControls.rev as my two files to deploy. Now, I know I can password protect stacks to keep people out of them, but what is to keep someone from creating some malicious code, naming the stack BaseControls.rev and dropping it into the folder my app is deployed in. When I "start using" BaseControls, the malicious code will be executed.
Is there a way to verify a stack is really my stack before I trigger any code in the stack?
Thanks in advance,
- John
-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
You might consider using a checksum on the stack files: read them into a variable and pass that into the md5Digest function, which will return a binary signature of the data. If you store that signature in your standalone and compare that to an MD5 value checked on startup you should have reasonable assurance that the stack file you're checking is indeed the one you originally put into place.
That said, such a method would preclude any dynamic updates in which you may want to replace individual components without replacing the standalone.
For such cases you might consider including a function in each of your stacks which returns a value known only to your standalone; you can call a function from a given object using the "call" command. If a stack returns a different value or doesn't include that function at all, you'll either get an unexpected value or an error, and either could serve as a flag to let you know to halt execution.
That said, such a method would preclude any dynamic updates in which you may want to replace individual components without replacing the standalone.
For such cases you might consider including a function in each of your stacks which returns a value known only to your standalone; you can call a function from a given object using the "call" command. If a stack returns a different value or doesn't include that function at all, you'll either get an unexpected value or an error, and either could serve as a flag to let you know to halt execution.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Hi Richard,
Thanks for the reply.
I was thinking along the same lines of having the main executable "talk" to the stack prior to any code execution but I'm so new to Rev (and stack programming in general...I've always been an OO guy), I'm not sure of the order of events.
I've learned that to use the external stack, I use the "Start Using" command which sends the libraryStack message to the external stack. Is there a way to "inspect" or make some kind of call into the stack prior to the "Start Using" command?
Thanks for the reply.
I was thinking along the same lines of having the main executable "talk" to the stack prior to any code execution but I'm so new to Rev (and stack programming in general...I've always been an OO guy), I'm not sure of the order of events.
I've learned that to use the external stack, I use the "Start Using" command which sends the libraryStack message to the external stack. Is there a way to "inspect" or make some kind of call into the stack prior to the "Start Using" command?
- John
hi John,
before opening the stack you are loading dynamically you could
This will prevent to trigger any of the messages that are usually sent in the opening process of the stack. Then you could call the secret function as Richard mentioned in a try catch block. If that does not throw an error, unlock messages and start using the other stack, otherwise warn your user and quit the app.
All the best,
Malte
before opening the stack you are loading dynamically you could
Code: Select all
lock messages
All the best,
Malte
Hi Malte.
Excellent! That's just the kind of information I was looking for. So, to clarify, if I have legitimate code in my external stack's libraryStack handler, I could do the following:
1) Lock messages
2) Start using my external stack
3) Check my "secret function"
4) Assuming it is valid, Stop using my external stack
5) Unlock messages
6) Start using my external stack again (so it can now handle the libraryStack message)
OR...
Would I be just as well off after Step 3 to Unlock messages and then Send libraryStack to my external stack myself?
Thanks again for the information! Greatly appreciated!
Excellent! That's just the kind of information I was looking for. So, to clarify, if I have legitimate code in my external stack's libraryStack handler, I could do the following:
1) Lock messages
2) Start using my external stack
3) Check my "secret function"
4) Assuming it is valid, Stop using my external stack
5) Unlock messages
6) Start using my external stack again (so it can now handle the libraryStack message)
OR...
Would I be just as well off after Step 3 to Unlock messages and then Send libraryStack to my external stack myself?
Thanks again for the information! Greatly appreciated!
- John