Re: do. command. safety. ?

2018-04-03 Thread Bob Sneidar via use-livecode
When I first started writing things in Hypercard, I would take my creations to the Principle of the High School where I worked and he would set about trying to break my code. He was good at it. He told me that if it occured to him to try and break it, eventually it would occur to someone else.

Re: do. command. safety. ?

2018-04-03 Thread Mark Waddingham via use-livecode
On 2018-04-02 07:06, Richard Gaskin via use-livecode wrote: You were just thinking constructively. You look for outcomes that benefit people. That's a good perspective to have. Most devs do. Maliciously breaking things requires a different mindset. Or just recast the problem as an entirely

Re: do. command. safety. ?

2018-04-01 Thread Richard Gaskin via use-livecode
J. Landman Gay wrote: > Thanks for the examples, Alex and Richard. I did understand the > principle behind the caution but I couldn't get any of my tests to > produce bad results. Both your examples do that. > > I think the problem was that I wasn't being imaginative enough. You were just

Re: do. command. safety. ?

2018-04-01 Thread J. Landman Gay via use-livecode
So next time I'd better hire one of you guys, looks like. Malice isn't my strong point. Except maybe for certain distant relatives. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On April 1, 2018 5:42:26 PM Mark Wieder via use-livecode

Re: do. command. safety. ?

2018-04-01 Thread Mark Wieder via use-livecode
On 04/01/2018 11:40 AM, J. Landman Gay via use-livecode wrote: Thanks for the examples, Alex and Richard. I did understand the principle behind the caution but I couldn't get any of my tests to produce bad results. Both your examples do that. I think the problem was that I wasn't being

Re: do. command. safety. ?

2018-04-01 Thread J. Landman Gay via use-livecode
Thanks for the examples, Alex and Richard. I did understand the principle behind the caution but I couldn't get any of my tests to produce bad results. Both your examples do that. I think the problem was that I wasn't being imaginative enough. -- Jacqueline Landman Gay |

Re: do. command. safety. ?

2018-03-31 Thread Richard Gaskin via use-livecode
Jacque wrote: > could you provide an example where the embedded command would actually > execute? A variant of Mark's example which executes when passed to fooEvil but not when pass to fooGood: on mouseUp put "into x "&";answer GOTCHA & word 1 of the params #" \ into tUserInput

Re: do. command. safety. ?

2018-03-31 Thread Alex Tweedly via use-livecode
The question is exactly what did you type into the field ? It's unclear whether the quotes in your email are part of the email, or part of the field content. Here's a case that definitely shows the difference: button "Button" on mouseup   localtVar, tX   do"put "&& quote& thetextoffld1&

Re: do. command. safety. ?

2018-03-31 Thread Dr. Hawkins via use-livecode
On Fri, Mar 30, 2018 at 9:02 AM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > > do "put " && quote & user input & quote && "into x" -- not safe > Thus, do "initiate global thermonuclear war" :) Was shazam the statistical package that actually implemented that

Re: do. command. safety. ?

2018-03-31 Thread J. Landman Gay via use-livecode
BTW, I know this works and is dangerous: do It's the insertions that don't seem to be affected. On 3/31/18 2:03 PM, J. Landman Gay via use-livecode wrote: At the risk of appearing to be obtuse...I tried both versions of the "do" and got the same results. In each case, the variable was

Re: do. command. safety. ?

2018-03-31 Thread J. Landman Gay via use-livecode
At the risk of appearing to be obtuse...I tried both versions of the "do" and got the same results. In each case, the variable was populated but no code was executed. In a test stack with one field and one button, I entered ";set the backcolor of btn 1 to blue;put ". In the button script I

Re: do. command. safety. ?

2018-03-30 Thread Mark Waddingham via use-livecode
The user input was indirected through a variable in the safe version - not made part of the do string... That's the critical difference. The unsafe version allows user input to change the do'd code, the safe version only changes the content of a variable the do string uses. Warmest Regards,

Re: do. command. safety. ?

2018-03-30 Thread Richard Gaskin via use-livecode
Tom Glod wrote: > Sometimes late at night just before falling asleep I think about > the dangers of the do command. Is it possible to inject code into > this mechanism through malware? Mark's discussion handled the security aspect well. The only thing I could add would be to examine each

Re: do. command. safety. ?

2018-03-30 Thread J. Landman Gay via use-livecode
Well yes, but as Bob mentioned, wouldn't a variable do the same thing? put ";delete hard drive;put " into x do x vs: do "put " && quote & ";delete hard drive;put " & quote && "into x" This actually came up way back in MetaCard where it was pointed out that the engine was about as

Re: do. command. safety. ?

2018-03-30 Thread Bob Sneidar via use-livecode
Couldn't the same be said about tVar? I suppose you mean that you could check the user input before doing it. Bob S > On Mar 30, 2018, at 10:15 , Mark Waddingham via use-livecode > wrote: > > Think about the string that can be constructed in the quoted version

Re: do. command. safety. ?

2018-03-30 Thread Mark Waddingham via use-livecode
Think about the string that can be constructed in the quoted version - user input could be "; ...;put " where ... is any code you would like... Sent from my iPhone > On 30 Mar 2018, at 18:09, J. Landman Gay via use-livecode > wrote: > > These look the same to

Re: do. command. safety. ?

2018-03-30 Thread J. Landman Gay via use-livecode
These look the same to me. Both versions place content into a variable. Is the difference because of how the engine evaluates the input somehow? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 30, 2018 11:04:54 AM Mark Waddingham

Re: do. command. safety. ?

2018-03-30 Thread Tom Glod via use-livecode
your point still applies about not being responsible that the user has allowed malware onto their system. On Fri, Mar 30, 2018 at 12:52 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Ah I saw command in the subject and thought you were talking about shell > commands.

Re: do. command. safety. ?

2018-03-30 Thread Bob Sneidar via use-livecode
Ah I saw command in the subject and thought you were talking about shell commands. Bob S > On Mar 30, 2018, at 09:49 , Tom Glod via use-livecode > wrote: > > Valid point Bob. Thank You. > > Useful info, Thanks Mark. I was doing it the right way

Re: do. command. safety. ?

2018-03-30 Thread Tom Glod via use-livecode
Valid point Bob. Thank You. Useful info, Thanks Mark. I was doing it the right way sometimes. the wrong way other times. thank you. On Fri, Mar 30, 2018 at 12:02 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Using do safely is the same as making database

Re: do. command. safety. ?

2018-03-30 Thread Mark Waddingham via use-livecode
Using do safely is the same as making database queries safe, or URL requests. You 'just' need to make sure that any input from outside is sanitized to ensure that it doesn't change the meaning of the expression you are 'doing'. For example, don't interpolate strings directly in the script using

Re: do. command. safety. ?

2018-03-30 Thread Bob Sneidar via use-livecode
Any shell command that can do anything dangerous is typically protected by the host OS. You could not for example install software in a way that would bypass UAC in Windows. You *could* conceivably delete all the files in a folder I suppose, but you couldn't copy files to a protected location.