I am writing selenium (seleno) scripts to test a c# MVC web application which requires users to log in. At the moment the username and password are hard-coded into the script but I need to make sure the password is protected before I can commit the scripts to our code repository.
The scripts will be run autonomously through CI (TeamCity) so the password must be available to the program without any human input.
In terms of security requirements, the password is common knowledge amongst devs but it is also bundled with the software that is deployed to clients (which obviously opens a back door to anyone in possession of the password - for better or for worse). So if someone gains access to our codebase we need to be sure that they cant get at the password. The password itself is stored (salted) in a sqlite database.
If I pass an encrypted value into the program and then decrypt it will that protect us? Im not too bothered about the password being in memory on the server where the test runs as that server should be securely locked down and will only exist for the duration of the tests.
The only other thing I can think of is to insert a temp password into the sqlite database once TeamCity has spun up the temp server instance and before the tests are run. Not sure how to achieve that though.
I would have thought this would be a really common problem with selenium but I havent as yet been able to find a definitive solution.
The solution is to set your passwords at runtime. I would suggest environment variables. Then they are not in your codebase and instead somebody would need to hack into where you run your tests from.
As SiKing suggests, the solution is to use a temporary, test specific password which wont make it into production code. Simples.
One approach that I have used is to execute javascript to evaluate things:
<td>storeEval</td>
<td>prompt("What password")</td>
<td>secretPassword</td>
That only really works for user run stuff via webdriver though.
You could setup some kind of small ajax request at the start of the test to http://localhost/credentials.json or similar, which is set up on your CI instance (but not available anywhere else).
Add a password manager extension like bitwarden,keepass etc.., and configure it to auto-login... give 2-3 sec in code to auto-login
Related
how can I make a login form that will remember the user so that he does not have to log in next time.
Some more information would be nice but if you want to use a database for this then you would have to create a entry for the user information last entered.
And then on reopening the programm you would check if there are any entrys and if yes load it.
But I think that writing the login information to a file on you pc would be a lot easier. So you run the steps from above just writing to a file instead of a database.
I am not sure how you would make this secure because you can't really encrypt the password because you would need a password or key of some type and that password or key would be easy to find in the source code especially in python. It would be harder to find in other compiler based programming languages but also somewhere. And if you would use a database you would have a password for that but that would also lay on the hardrive if not encrypted otherwise but there we are where we started.
So as mentioned above a database would be quite useless for a task like this because it doesn't improve anything and is a hassle for beginners to setup.
Hi security aware people,
I have recently scanned my application with a tool for static code analysis and one of the high severity findings is a hardcoded username and password for creating a connection:
dm.getConnection(databaseUrl,"server","revres");
Why does the scanner think this is a risk for the application? I can see some downsides such as not being able to change the password easily if it's compromised. Theoretically someone could reverse-engineer the binaries to learn the credentials. But I don't see the advantage of storing the credentials in a config file, where they are easy to locate and read, unless they are encrypted. And if I encrypt them, I will be solving the same problem with the encryption key...
Are there any more risks that I cannot see? Or should I use a completely different approach?
Thank you very much.
A fixed password embedded in the code will be the same for every installation, and accessible by anyone with access to the source code or binary (including the installation media).
A password read from a file can be different for each installation, and known only to those who can read the password file.
Typically, your installer will generate a unique password per site, and write that securely to the file to be read by your application. (By "securely", I mean using O_CREAT|O_EXCL to prevent symlink attacks, and with a correct selection of file location and permissions before anyone else can open it).
This is an interesting one, I can give you examples for a .Net application (as you haven't specified running environment / technologies used). Although my guess is Java? I hope this is still relevant and helps you.
My main advice would be to read this article and go from there: Protecting Connection information - MSDN
Here is a page that describes working with encrypted configuration files here
I've seen this solved both using encrypted configuration files and windows authentication. I think that running your application as a user that will be granted access to the relevant stored procedures etc (as little as possible, e.g. Principle of Least Privilege) and furthermore folder access etc is a good route.
I would recommend using both techniques because then you can give relevant local folder access to the pool for IIS and split out your user access in SQL etc. This also makes for better auditing!
This depends on your application needs though. The main reason to make this configurable via a config file or environmental user account I would say is so that when you come to publish your application to production, your developers do not need access to the production user account information and instead can just work with Local / System test / UAT credentials instead.
And of course they are not stored in plain text in your source control checkin then either, which if you host in a private distributed network like GIT could mean that this could be compromised and a hacker would gain access to the credentials.
I think it depends on how accessible / secure your source code or compiled code is. Developers usually have copies of the code on their dev boxes, which are usually not nearly as secure as production servers, and so are much more easily hacked. Generally, a test user / pw is configured on the dev box, and in production, the "real" pw is stored in much more secure config files. Yes, if someone hacked into the server they could easily get the credentials, but that is much more difficult than getting into a dev box in most cases. But like I said it depends. If there is only one dev, and they have a super secure machine they work with, and the repo for their code is also super secure, then there is no effective difference.
What I do is to ask the credentials to end user initially and then encrypt and store them in a file. This way, I don't know their connection details and passwords as a dev. The key is a hashed binary and I store it by poking ekstra bytes in between. One who wants to crack it should find out the algorithm used, key and vector lengths, their location and the start-end positions of the byte sequence keeping the values. A genius, who would also reverse engineer my code to get all this information would break into it (but it might be easier to directly crack the end user's credentials).
Problem
I am setting up a set of e2e tests on an existing web-app. This requires automated login on a login-page (mail & password). So far, as I am still developing the tests, I have been putting the test account credentials in cleartext in my test scripts. I have been removing the credentials manually before each commit, but it will not hold for proper automated testing on a server somewhere, nor if all the developers should be able to run tests from the comfort of their own computers. Furthermore, the tests need to be able to run with several different sets of user credentials, and credential safety is critical. Since we need to test for access rights, it seems that we cannot avoid having at least one test account with access to confidential data.
Question
So my question is: What strategies do you know of, or use, for safely storing and using test credentials in testing environments on developer machines, separate servers, or both?
Prior research
I have spent a few days looking around the web (mostly StackOverflow, and many attempts at using my Google-fu) as well as asking colleagues, but without finding any known and used strategies for handling and storing credentials in tests. I reckon that many skilled programmers must already have solved this problem in numerous ways.
StackOverflow kindly suggested these somewhat similar questions, which offer some interesting strategies:
Safely storing credentials when I need to retrieve the password for use, where the accepted answer recommends encrypting the configuration file. It seems like a very interesting idea, but it is unclear to me how well this distributes across servers and individual developer computers, and how the logistics of this could be handled.
Storing credentials for automated use, where the asker responds to themself by stating that they simply put the credentials as cleartext in a file on their password-protected server. This might work for a single server, but I do think this is problematic if a number of local developer machines or separate test servers will be used for testing.
Case specifics
I think the question is of general interest regardless of the implementation details, but as they might be of interest they are provided here anyway.
I am using protractor for testing AngularJS apps, and am considering Grunt for further test automation. We plan on hooking the tests up on our Git server, and have it run tests at each commit to the master branch, so that we know it is never breaking. Or, not breaking during our tests, at least :)
I'm not sure what you mean when you say 'Strategies for safely storing and using user credentials testing environments'. You state that your tests need to be run with different sets of credentials. If your test is able to get to the credentials in clear text, so is any other application/user running under the same account.
Sure, you can encrypt the file storing the passwords, but you'd need to store the encryption key somewhere in the application or on the machine for the application to be able to decrypt it.
You could use asymmetric encryption to encrypt any credentials with the public key and only give access to the private key to the account running your tests. But still, anyone being able to log on under the account that runs your tests would be able to decrypt the credentials file and get to the passwords.
The best option is to not use confidential data in testing. I work for a company doing medical software, and we have a test domain in which we set up our software with well-known accounts and use fake data to test it.
Or if you want other developers to be able to run the tests under their own credentials, you could consider switching to Kerberos and avoid passwords all together.
I agree with the above answer, you can create a key, store it somewhere and use.
Else you can got for encryption, I found a link which may be helpful for you.
http://docstore.mik.ua/orelly/java-ent/security/ch13_05.htm
I have a special user, called udpate, whose shell is a special command that fetches any pending updates to our system.
I'd like to be able to open an ssh session with this user without any kind of authentication (password or ppk, or anything), so if anyone wants to update a system, they could do "ssh update#<>", without having to know a password, or have a pre-shared public key on the box.
Insecure, I know, but this is over a VPN, so it should not be a problem, and they will only run the update, and then be thrown out.
Can this be done?
VPN is not a good reason to avoid authentification when using ssh. Even if there is a way to do this, you shouldn't use it. Use a ssh-key is the best way to do it. If you really want to do thing like this, use the same key and distribute it on each box.
What did you do if the local network of your box is compromised ? You just have a security hole.
as this rfc points out, there is support for host based authentication https://www.ietf.org/rfc/rfc4252.txt
So using it carefully should be possible by following this tutorial https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication#Server_Configuration_for_host-based_authentication.
That may not be a final solution, but helping finding one.
But really, you should not do it for this usecase... Just offer a basic web endpoint which does only start the update process on the next cron run. I know, its not so "simple" but its a lot more secure.
Or if they have access to this server anyway, add a script with super user bit set which triggers the update.
Also, if you have a central server in your company, where everyone has access too, you can use this as step in between to host the key pair, so you dont need to manage X keys for everyone.
Or you use a more modern setup with puppet or anything, or you just configure the server to always update without user interaction needed....
Some users are suggesting that my (C#) program should be able to run scripts after completing it's job. This would be done through a command line to be input in my configuration dialog.
I'm no security expert, so I'm not sure if this acceptable in terms of security. Since the app runs with admin privileges (on Windows), wouldn't that be a huge security risk? Someone could just modify the config files of my application to point to a potentially dangerous script, couldn't they?
On the other hand, plenty of applications allow this, while requesting admin privileges, so I guess it must be ok, but I thought I'd better seek advice before opening wide security holes everywhere =)
Can I allow my application running with full privileges to launch user-specified scripts?
You can restrict access to your config in different ways - from obfuscating the config file to using NTFS permissions to limit access of non-admin accounts to it.
C# certainly allows you to run a user script. System.Diagnostics.Process makes that real easy. The question of security here is another problem.
Running scripts when a process completes can be an incredibly useful and can make or break your target audience's opinion of your application. Understandably, you don't want your product to be turned against your own consumers through a malicious hack like you're thinking.
The root of this problem is that your options are (I'm assuming) text based and easily editable. Your best bet is to encrypt your config file to prevent outside changes to it. Note that this doesn't prevent people from using your app to change your options to allow a malicious script, but for somebody to do that, they need access to an instance of your application instead of simply file read/write access.
This does bring to question one more aspect you should watch for. Don't use the same key for every installation of your application. If you do that, then Bob could cause Alice to run a malicious script by copying Alice's config, using his instance of your app to decrypt it and make the change and then Bob can replace Alice's config with the new malicious config.
Here is another SO question for how to encrypt strings in C#.