I am trying to find a way to mask test data in Tricentis Tosca like a password, for instance. I see in TestCases section I can mask data by setting type as Password from string - however in TestCaseDesign there is no such option. Please let me know if you have any solutions for this.
I think Tricentis intends passwords to be stored in ReusableTestStepBlocks and then use conditions to switch which RTSB gets used for the sign on. You can store the desired user name in the red section (TCD), and then use switching logic to launch the RSTB that corresponds to that user and contains their password.
This is probably safer, since the password is stored hidden, and intimately tied to the module, so that it's more difficult to "extract" that hidden password data (i.e. tricking Tosca into typing it into a notepad)
This is how we do it in my team.
You may want to have them in TCP (Test Configuration Parameter). See here
Related
I'm currently developing one project and I just discovered that the value of hidden fields can be edited. So that causes me a problem of security.
Imagine that I have a form to edit personal information. Currently, the form has a hidden input that has the value of the primary key. So if someone change that value can update data from another people.
I already check here and on google and found a possible solution on https://mvcsecurity.codeplex.com/. But unfortunately, that's not available to the recent version of ASP.NET MVC.
So I want to know if someone knows the properly way to prevent that.
The short answer is, Never trust data coming from client!
You should never trust data coming from a client browser. It can be altered by the end user. So don't simply trust the value. Always do needed validations on server side to make sure that the data / operation is valid.
In your specific case, When the form is submitted, you should check the value of the hidden field (the primary key value of the record being edited) is valid for the current user to be edited. Depending upon your systems user permissions/role system, you can do some if checks and determine whether the current user is authorized to do this operation with the value coming from client.
One solution is to encrypt the primary key before putting it in the hidden variable. That's the approach alot of site use, although often the encrypted var will be in the query string.
I have a Tabular User Maintenace Window that uses Datawindow Select / Update.
I need to encrypt the password saved on the MSSQL Database.
I have a function f_decrypt for Powerbuilder and for dbo.
How can I use dw.Update() to encrypt the password?
A small book could probably be written on the possibilities. My first question is the requirement to store encrypted passwords, or does the password have to go over the wire encrypted. If storage is the only requirement, I'd tend to let the DBMS do what a team of high level programmers spent months trying to get right, rather than to try to reinvent the wheel myself. Even if it has to go over the wire encrypted, I'd look at DBMS-provided options first.
If you have to do it client-side and deal with hashing, salting, preventing reverse engineering of your code, et al, yourself, there are still probably a dozen ways to do it. The first way I'd try is to make a DataWindow with a dummy column for the password user interface, as well as the column in the table, e.g.
SELECT ' ' as password_ui,
table.password_storage,
...
FROM table
....
I'd put password_ui on the DataWindow's user interface, and leave password_storage off the user interface, but make sure password_storage is included in the Update Properties as an updatable column. Then, on ItemChanged, if the column changed is password_ui, I'd
CHOOSE CASE dwo.Name
CASE "password_ui"
SetItem (row, "password_storage", f_encrypt (data))
END CHOOSE
Good luck,
Terry.
I am developing an HTTP server application (in PHP, it so happens). I am concerned about table IDs appearing in URLs. Is it possible to encrypt URL variables and values to protect my application?
oh ok, so for sensitive information best to use sessions then, are table Ids etc safe to throw in the GET var?
Yes, sensitive information must not leave your server in the first place. Use sessions.
As for "are table ids safe in the URL": I don't know, is there anything bad a user could do knowing a table id? If so, you need to fix that. Usually you need to pass some kind of id around though, whether that's the "native table id" or some other random id you dream up usually doesn't matter. There's nothing inherently insecure about showing the id of a record in the URL, that by itself means absolutely nothing. It's how your app uses this id that may or may not open up security holes.
Additionally think about whether a user can easily guess other ids he's not supposed to know and whether that means anything bad for your security.
Security isn't a one-off thing, you need to think about it in every single line of code you write.
Sounds like you want to pass sensitive information as a GET param.
Don't do that - use $_SESSION if you can.
However, if you want your params encoded (i.e. => +) use urlencode().
$a = 'how are you?';
echo urlencode($a); // how+are+you%3F
You can encrypt what you pass before you transmit, or you can run the entire communication over an encrypted channel (https or ssh for instance).
Your GET variables are called whatever you choose to call them, and assigned whatever values you choose to give them. So, yes: they can certainly be encrypted or, if you'd rather, simply obscured. If you're planning to encrypt variables, then PHP has quite a few options available.
For the above, I'd recommend using something like urlencode.
In general I'd suggest using POST instead of GET, assuming you're getting your variables from a form element. On the other hand it might be even wiser to use session variables.
Maybe this article can give you more ideas...
http://www.stumbleupon.com/su/1nZ6bS/:1PcFQMI0:6oJD.Hd1/www.ibm.com/developerworks/library/os-php-encrypt/index.html/
How to encrypt this url in asp.net (VB.NET), so that user cannot view this address bar text in their browser address bar ?
http://localhost:2486/volvobusesindia/passenger_info.aspx?from=Delhi&to=Manali&journey=21-Nov-2010
You can't. And before someone suggests using POST, that doesn't really hide anything. It's trivial to use Wireshark, Firebug, etc. either way.
Any communication between the user's machine and your server, in either direction, encrypted or unencrypted, can be monitored by the user.
EDIT: An alternative is to generate a unique GUID or session identifier, then keep track of the meaning on the server. This is not encryption, but it may serve the desired purpose.
You can do some really good obfuscating, but you probably want to roll-your-own, as if you are using this for security, you don't want everybody knowing how to decode your encoding.
We do it by using a single querystring parameter that contains ALL of the information we need from the request in our own format. Of course, this does mean giving up all of the handy .Request[] methods, but you've got to make the trade off somewhere.
The full path to a file with the fully encrypted URL also can get obscenely long with everything thrown in there. For example, this is a link that will display an image of a ring with the word "Landrum" on it (in both directions). The image is created the moment you request it, from the information contained in the encrypted query string.
http://www.flipscript.com/data/default/images/catalog/medium/AMBIRingTitanBlue_G1F88E4X57,409-945,591O0M0S2V6.jpgx?xq=45C35129$6zvtnw6m1280kwz8ucqjt6jjb2vtea43bio5ixmnge-5r4i-o1o32j43y58nv
I hope that helps a bit! There is no "out of the box" solution, but this one works pretty well.
Instead of hiding it, you could call this site internally from within some other site and do whatever you wish with the returned results (e.g. display them on your site). That would guarantee you that the user won't ever have the chance to see the actual site being called.
I'm using ASP.Net but my question is a little more general than that. I'm interested in reading about strategies to prevent users from fooling with their HTML form values and links in an attempt to update records that don't belong to them.
For instance, if my application dealt with used cars and had links to add/remove inventory, which included as part of the URL the userid, what can I do to intercept attempts to munge the link and put someone else's ID in there? In this limited instance I can always run a check at the server to ensure that userid XYZ actually has rights to car ABC, but I was curious what other strategies are out there to keep the clever at bay. (Doing a checksum of the page, perhaps? Not sure.)
Thanks for your input.
The following that you are describing is a vulnerability called "Insecure Direct Object References" And it is recognized by A4 in the The OWASP top 10 for 2010.
what can I do to intercept attempts to
munge the link and put someone else's
ID in there?
There are a few ways that this vulnerability can be addressed. The first is to store the User's primary key in a session variable so you don't have to worry about it being manipulated by an attacker. For all future requests, especially ones that update user information like password, make sure to check this session variable.
Here is an example of the security system i am describing:
"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";
Edit:
Another approach is a Hashed Message Authentication Code. This approach is much less secure than using Session as it introduces a new attack pattern of brute force instead of avoiding the problem all togather. An hmac allows you to see if a message has been modified by someone who doesn't have the secret key. The hmac value could be calculated as follows on the server side and then stored as a hidden variable.
hmac_value=hash('secret'&user_name&user_id&todays_date)
The idea is that if the user trys to change his username or userid then the hmac_value will not be valid unless the attacker can obtain the 'secret', which can be brute forced. Again you should avoid this security system at all costs. Although sometimes you don't have a choice (You do have a choice in your example vulnerability).
You want to find out how to use a session.
Sessions on tiztag.
If you keep track of the user session you don't need to keep looking at the URL to find out who is making a request/post.