One Liner to get Active Directory Computer Account and Password on OS X
Posted: June 6, 2013 Filed under: Active Directory, Deployment, LDAP, Mac OS X, Mac OS X Server, Scripting, Security, Unix | Tags: Active Directory, security, dsconfigad, AD, computer, password, account, system keychain, keychain, one-liner Leave a comment »
Does that count as a one liner?
Shell Injection with AppleScript’s do shell script
Posted: May 14, 2008 Filed under: Mac OS X, Scripting, Unix | Tags: applescript, do shell script, quoted form of, security, shell injection Leave a comment »AppleScript’s do shell script capability is immensely useful, but if you are sending variable data to do shell script, always validate input and use quoted form of variableName. See the following example:
set dialogResult to (display dialog "Enter a directory name to pass to ls:" default answer ";say boo" buttons {"Cancel", "Quoted Form", "Raw"})
if button returned of dialogResult is "Quoted Form" then
try
set theCommand to "ls ~/" & quoted form of text returned of dialogResult
display dialog "Will execute:" & return & theCommand & return & "Proceed?"
do shell script theCommand
end try
else
try
set theCommand to "ls ~/" & text returned of dialogResult
display dialog "Will execute:" & return & theCommand & return & "Proceed?"
do shell script theCommand
end try
end if
Note you’ll have to fix the quotes to standard double quotes to get this to compile. I couldn’t get wordpress to cooperate.
Unix Environment Variable Scope/Security
Posted: May 5, 2008 Filed under: Scripting, Unix | Tags: environment, scope, security, Unix, variables 1 Comment »I recently encountered a command line tool which exposed passwords in the process listing.
The command would also also accept a password as an environment variable. I was concerned with the security of storing a password in an environment variable.
This article at itworld.com does a nice job explaining environment variable scope.
Environment variables are only accessible in the shell in which they are set.
If you export the variable, it is accessible to any subshell of the shell in which it is exported. Simply logging in as another user on the system or even the same user does not allow access to the exported variable.
So, until someone corrects me, I believe that setting and exporting environment variables containing passwords in a script does protect the password from exposure. As soon as the command requiring the password has completed, the variable can be reset to an empty string to prevent any further access to the password.