Check where the Type secure text activity types into

i_declined
security
activities

#1

The “Type secure text” activity types the password as plain readable text if we type the text into a notepad or and other non-password field.
Wouldn’t it be a good idea to check the type of field that allows type secure text activity? Like using it only for password fields? Else, it would be easy for anyone who wants to get the password used in that activity by simply using a type secure text in a notepad. This defeats the password security of Cyber Ark and password encryption we are using in Orchestrator.


#2

While I agree with the points, how would this work with typing into Citrix/RDP? There’s no way to verify what’s on the other side and it’s as easy as sending shift+tab to make it type into user field.


#3

I Agree. Citrix/RDP, we have no way of validating what we are typing in what field, that is a limitation from the environment itself. But in the others environments, its a good idea to have it. One of our clients automating a finance application have highlighted this as a security loophole.


#4

It will be nice but very difficult to implement. Not only in Citrix/RDP but many other sub-systems like terminals, java apps… how can you make sure that you’re detecting the password field in 100% of the situations? You can not.

If this is a security loophole then it applies to software development too. How can you make sure that one of our coders has not entered malicious code that sends credit-card info to his personal email?

The answers are below:

  1. Release Management/Code Review
    Every workflow that goes into production needs a reviewer approval (the reviewer is the one who pushes the workflow via Orchestrator). Now, he needs to check how all the SecureStrings are used So he needs to make sure that SecureStrings are not entered into notepad and sent via email.
  2. Source Control
    You can get to the developer that entered malicious code within the workflow
  3. Dev/Test/Production environments
    While a dev may call GetCredential within Dev environment he does not have access to production machines. The developer has access only to TestCredentials.

For software development there are automatic source code vulnerability scans which can’t be applied now for RPAs.


#5

Thanks @badita for the detailed reply. It helps. I already mentioned workflow code review and code check-in versions, logs in SVN as recommended best practices to avoid this problem.


#6

This is a more general problem of UI automation. How one can be sure that keystrokes reach the intended edit box? Any unattended pop-up window can steal the focus and the keystrokes will be routed to another destination; and this can happen to human users as well.

Adrian