I am using the community version of studio (2019.10.3). Recently, I was testing something and accidentally hit, what I see until now, as a bug.
I was able to capture the password to any application. I verified this by attempting in 2 applications.
Steps to reproduce.
We will try in “https://acme-test.uipath.com/account/login”
- Define your credential in Orchestrator
- In your studio, create the following activities.
a. Get credential
b. Open browser and login to “https://acme-test.uipath.com/account/login”
c. Enter username
d. Enter password
Here comes the crucial stage.
e. Before you click Log in, insert GET FULL TEXT activity to scape the screen and store output.
f. Print scrapped text.
I was able to see the password printed.
I repeated the same steps on one of my email account.
This seems to compromise security.
Correction: Studio version is 2019.10.4
Great find… let me tag my friend who can tag this to a relevant person…
oh wait a minute this seems familiar .
It’s been a long time ago.
However It’s kind a obvious to see the result since get text returns string not secure text.
On top of that html tag has type as password which can be altered by user at the client side to see the password by changing type to text
Hence its one and the same.Just like using Type Secure Text on notepad .
I wouldn’t consider it as a bug. ACME website has been made for education/test only and it’s simple database web application which not stores any crucial or sensitive data. Many websites have password textbox made to show only “*****” instead of signs where in fact you could read the data using same method (of course it’s not a best practice to design it such way as some viruses/keyloggers would be able to get this. Anyway thank you for being watchful
My test was not against ACME website alone. Before I posted my concern, I tried it in 2 other applications, a email web portal as well as ERP application. Get Full Text simply grabs everything including the password and just exposes it. I cannot be believe that it is NOT a bug. In my honest opinion, it does compromise the security that we enforce through Credentials.
The fact that this is not seen as a bug (so it can be fixed) makes us a little uncomfortable.
Anyone else shares my sentiments?
The point is that this is an issue with specific websites, not with UiPath. If a website doesn’t have proper security than any software tool could potentially scrape the password once it’s typed into a textbox.
@csathys UiPath activities are just doing their job. If password’s textbox is not properly coded and it’s just keeping raw data under
****** without any active encryption it’s a website’s issue not Studio
Agree with @Pablito on this comment
if the password can scrape form this ****** means that it was a security issue on the relevant sites , if any site can be extract that kind of data means that its not only way to get that , there are various ways to capture the password then.
Also as i remember UIPATH publish article here , successfully passing the CAPTCHA image recognition security (unfortunately i cannot find the link for you now )
like wise UIPATH will find a way of giving automation solution.we have to have a ethical acceptances for not to do unethical automation or any Cyber- Corona
FEEL FREE HAPPY AUTOMATION