I'm not authorized to show the code but I have a problem:
When using the recording feature of CUIT on VS 2015, The test yields an error part way through the playback.
A date entry field is a masked input string field like this "MM/DD/YYYY HH:MM". You can type the values freely into the field. The issue is when doing playback, CUIT attempted to enter the string value of what is captured in the control's final state as "05/09/2017 12:42". The "/" and ":" of the string's value causes the cursor to tab through the masked input, resulting in an erroneous entry. The actual string required to account for all of the tabbing is literally "05///09///2017 12::42" but when I use that hard-coded value, it errors out while attempting to check for the longer version. States that it can't set the control to that value.
Is there a way to tell the CUIT to evaluate an overridden value so that it doesn't try to enter the string stored within the control which contains "/" and ":"?
You need to modify the value in the ...ExpectedValues class that holds the recorded date-time. Coded UI sends the recorded characters (or more accurately, the values from the ...ExpectedValues class) to the application and the application you are testing adds the / and : characters in the approprate places. The Coded UI recorder records both the entered and the generated characters.
Change the recorded 05/09/2017 12:42 value to be 05092017 1242. This can be done via the UI Map editor if the same date-time is always needed. Commonly the date-times are provided via the data source of a data driven test, or they are generated by the test itself. In either case it should be easy to provide data without the / and : or to add code to remove them before they are used. The wanted values are then written, when the test runs, into the ...ExpectedValues class.
See here for some additional notes on the ...ExpectedValues class and on data driving tests.
Related
I'm using Fortify static code analyzer with a C#/.NET project. I'm taking an integer parameter, a year, from user input and starting a process with that:
int y = int.Parse(Year.SelectedValue); //Year is a DropDownList
if (y >= 2017 && y <= DateTime.Today.Year)
Process.Start(new ProcessStartInfo(Server.MapPath("~/bin/SomeProgram.exe"), "/x:" + y.ToString()));
Fortify doesn't like that, throws a "Command Injection" issue:
Data enters the application from an untrusted source.
In this case the data enters at get_SelectedValue() in ccc.aspx.cs at
line 25. Even though the data in this case is a number, it is
unvalidated and thus still considered malicious, hence the
vulnerability is still reported but with reduced priority values.
The data is used as or as part of a string representing a command that is executed by the application.
In this case the command is executed by ProcessStartInfo() in
ccc.aspx.cs at line 28.
There are literally two possible values of input that would cause the process to start (as of this writing) - 2017 and 2018. If the if() statement doesn't count as validation for Fortify, what would?
EDIT: on top of everything, unless you explicitly opt of ASP.NET's ViewState integrity check, DropDownList doesn't allow values outside of the assigned range. With this in mind, I don't see why SelectedValue of a DropDownList is treated as an untrusted source in the first place.
Mark it as a false positive and move on.
I don't think Fortify takes the datatype into account. You are taking the value out of a string to and int, doing validation, then using the int value not the original. So as far as the command injection goes not an issue (in this case).
--
What constitutes a validation?
When it comes to Fortify, there is a difference between what constitutes validation and what will make Fortify stop reporting on it.
Unfortunately, there are some cases (as far as I have found from my time 5+ years of using Fortify) that you just cannot make it happy without writing a custom rule for the analyzer to indicate that some method is cleansing the data.
I need to verify if a string format has correct number and position of parameters.
In my system advanced users (administrators) can configure a option with string format and select the params in combobox, one specific combobox to position in format.
To save I need verify if this configuration is correct.
This is to generate a unique code to a record, this code is specific for each client.
In my screen I have a text box to the format, that can contain up to 6 items (or less), for each item i have one combobox.
The comboboxes contains a type of the value (ex. sequence, year, number, nothing (in case it's not required, etc).
I need verify if the format is correctly (ex. {0}-{1} is correct and {0}-{1}.{3} is wrong) and respective comboboxes are selected (ex. {0}-{1} require select a type in combobox 0 and 1)
--update--
I have resolved this question verifing the number of parameters in the string format is match with the number of values selecteds and the order of the values selecteds (ex. if the user keep any value empty and selected the next I have assumed this is incorrect) and I try generate a string with the format and values informed
To match a string to a particular pattern you should look into Regular Expressions.
It looks however, like there is more to it than simply pattern messaging - like maybe the user should be able to specify the desired pattern at run time? The question is a little unclear to be honest so I don't understand your full requirement.
I am creating a Calculator in Windows Store Application. I have successfully created the app in the store.
Now there is a problem in my app, after getting the result from performing any operation whenever I press on any numeric value, that value got append in the existing value.
In the following snapshot: I have added two numbers (1,1):
Now I am entering another value to perform some other option, but the new value got append in the existing value. I am entering 1 here:
What is the code for removing the existing value, if any numeric values pressed?
you could declare a bool value which is false and when you have your calculation done you switch it to true. Then you write a method that checks if the calculation is done or not and if it's done you simply clear the (i guess you use a textblock / box?) output. That would be my way in this situation - maybe there is a better solution for you. I hope it helps you to get a clearer way in mind.
As the author of the Windows Calculator that shipped from Windows 3.0 through Windows Vista, I agree with user3645029's response. You need to work out the input model for the app, so you understand clearly when you begin entering a new number and when you append to the one showing. I suspect that your app logic isn't making this distinction.
Let me be more specific:
If the key pressed is a number and the last key pressed was a number, then you add that new digit, which effectively means multiplying the current value by 10 and then adding the new key.
If the key pressed is a number and the last key pressed was an operator, =, or similar keys, then you're starting a new number input and your current value should be reset to 0 first.
In short, writing a calculator app requires an internal state machines that understands how to proceed from one input to the next. From what you describe, it sounds like you're missing the logic for the = key. Generally speaking, hand-held calculators with an = sign effectively clear the current value if you start entering a new number after =. Only if you press an operator does that value persist, and in that case you're also starting a new current value and keeping the "2" in your case as the first operand.
I'm concerned about the predictability of my application in handling string input in different cultures. It has been a problem in older software and I don't want it to be a problem in the new.
I have generally two sources of input; Strings entered into a WPF application and Streams, loaded from files, containing text. These cultured strings are generally entered into an model before being used
public struct MyModel
{
public String Name;
}
I want to design a meaningful test to ensure some logic can actually handle Result DoSomething(MyModel model); when it contains text inputted on a different machine.
But how can I show a case where the difference matters?
For example the following fails.
var inNativeCulture= "[Something12345678.9:1] {YeS/nO}";
var inChineseCulture = inNativeCulture.ToString(new CultureInfo("zh-CN"));
Assert.That(inChineseCulture, Is.Not.EqualTo(inNativeCulture));
[Question]
How can I test DoSomething such that the test is able to fail if the strings are not converted to InvarientCulture?
Should I even bother? i.e. the string Something entered on a french keyboard will always equal Something entered on a Chinese keyboard?
What can I test for that will mitigate Globalization problems?
The ToString method taking a IFormatProvider on a string is essentially a no-op. The documentation states "Returns this instance of String; no actual conversion is performed."
Since you are concerned about avoiding issues here's some general advice. First it is very helpful to have a clear distinction in your mind between frontend (user facing) strings and backend (database, wire, file, etc) strings. Frontend strings should be generated/accepted according to the user's culture / application language. These strings should not be persisted (with few exceptions like when you are generating a document that will be read only by people and not by machine). Backend strings should always use standard formats that will not change over time. If you accept the fact that the data used to generate/parse globalized strings changes, then you will isolate yourself from the effects by ensuring that you do not persist user facing strings.
I have a winform app with a TimeSpan column that displays the hours/minutes part of a date. When the user enters text it is converted to a TimeSpan using TimeSpan.TryParse(). This works as expected when the user input is "11:00" in setting a value of 11 hours. The problem is that if the use enters "1100" it is parsed as 1100 days which is not what I want, nor is simply saying "bad input" in the `CellValidating event satisfactory behavior.
The users input is provided in the readonly property DataGridViewCellValidatingEventArgs.FormattedValue so I can't change the value being passed through the call chain. DataGridViewTextBoxCell.EditedFormattedValue is also read only and I can't find any other event or property that lets override the default behavior.
This is very frustrating. I can write a many stepped fall through validater that can handle multiple user input formats and get the intended value from each; but unless I throw away all the strongly typed data binding that the framework offers and instead create a shim object that stores all values as strings there doesn't seem to be any way to do so.
Somehow among the 10 billion events in the DataGridView I managed to overlook CellParsing. Overriding it lets me do what I need to do.