I want to validate each and every value that is being passed to database for special characters. Is it possible to have any method kind of thing in T4 achieve this rather than adding a static method and validating it or please do let me know if there's a better solution for this
Related
I keep seeing code like this:
.WebButton("locator1", "locator2", "locator3")
What is the type of arguments in WebButton, WebElement, WebEdit etc ? I tried passing an array to .WebButton. So, qtp told me its not the correct type. Is there an alternate way to pass multiple locators ?
Also, what is the return type of .WebButton, .WebElement etc. ?
The "arguments" which you are talking about are the set of properties which are needed by QTP/UFT to identify that particular object(WebElement, WebEdit etc.) uniquely so that one can perform actions on them.
Also, this is not some sort of a function that is going to return you any value.
If you are not sure about what properties you need to mention in those brackets, an easier way would be to add that object to the Object Repository and drag that object from OR to your script. After that you can perform any action on those objects.
If you do not want to use OR, then you need to make use of, what we call, Descriptive Programming(DP) wherein you have to mention the object property names and their values "explicitly" in the script.
Remember that the sole purpose of mentioning these properties is to help QTP identify the objects in your application so that you can perform actions on them(like click, set etc.)
Here are a few links which can help you:
http://www.learnqtp.com/descriptive-programming-simplified/
http://www.guru99.com/quick-test-professional-qtp-tutorial-6.html
http://www.guru99.com/quick-test-professional-qtp-tutorial-32.html
EDIT 2 - for answering your question in the comment:
.WebButton("Locator1","Locator2","Locator3") means .webButton("property1:=value1","property2:=value2","property3:=value3")
Now, I could have only mentioned property-value pair1(which you are referring to as "Locator1") only If it alone was sufficient for identifying that webbutton. If only 1 property-value pair cannot help UFT in UNIQUELY recognizing the webbutton, then I have to provide another property-value pair until I have provided enough of them so that QTP recognizes that webbutton uniquely. Since, I have provided multiple property-value pairs(or locators), they have to be separated by commas. If there was only one property-value pair, no comma is needed. All this explanation only applies to the case when we are using Descriptive Programming. If we are not using Descriptive programming, then in that case the objects and their properties&values are stored in the Object Repository and you just have to mention their logical names(say Button1 as stored in OR) in the script like:
.webButon("Button1")
To understand more, you need to do some more research on "How object Identification works in UFT/QTP"
I'm using Visual Studio 2015 Web Performance test (.webtest) and have an Extraction Rule in place to capture a 8-digit number that references a check number (via inner text) into a context parameter.
If the number only contains 6-digits, then it has two blank spaces in front of the check number. This causes an issue because I'm using the check number in a form parameter and those blank spaces need to be switch to zeroes (0).
My question is what's the best way to handle the comparison? Is there a way to edit the context parameter (named "CheckNBR"), or can I overwrite the Extraction Rule to manipulate the parameter? Maybe create a custom Extraction Rule instead? I'm kinda going in all directions on this and not sure what options work the best.
[Update]
Instead of determining the best way, I'm re-directing the question towards the editing of the context parameter. Once I set the parameter from the Extraction rule, how can I edit it?
There are several possible approaches.
You could write a custom extraction rule that finds the required text, modifies it as needed and then save it to a context variable. This is probably the most complicated version to write.
You could write a custom extraction rule that uses the built in extraction rule and then modifies the result. Code based on the following (not tested, not compiled) should work. Of course you need to write your own version of ModifyTheTextAsNeeded. Then change the web test to use the extraction below instead of the original.
public class ExtractAndModifyHtmlTagInnerText : ExtractHtmlTagInnerText
{
public override void Extract(object sender, ExtractionEventArgs e)
{
base.Extract(sender, e);
string extractedText = e.WebTest.Context[this.ContextParameterName].ToString();
string modifiedText = ModifyTheTextAsNeeded(extractedText);
e.WebTest.Context[this.ContextParameterName] = modifiedText
}
}
Another approach is to put something similar to last three lines of the body of the method shown above above into a plugin. It might be a PreRequest plugin used on the next request after the one with the extraction rule.
I often encounter advice for protecting a web application against a number of vulnerabilities, like SQL injection and other types of injection, by doing input validation.
It's sometimes even said to be the single most important technique.
Personally, I feel that input validation for security reasons is never necessary and better replaced with
if possible, not mixing user input with a programming language at all (e.g. using parameterized SQL statements instead of concatenating input in the query strings)
escaping user input before mixing it with a programming or markup language (e.g. html escaping, javascript escaping, ...)
Of course for a good UX it's best to catch input that would generate errors on the backand early in the GUI, but that's another matter.
Am I missing something or is the only purpose to try to make up for mistakes against the above two rules?
Yes you are generally correct.
A piece of data is only dangerous when "used". And it is only dangerous if it has special meaning in the context it is used.
For example, <script> is only dangerous if used in output to an HTML page.
Robert'); DROP TABLE Students;-- is only dangerous when used in a database query.
Generally, you want to make this data "safe" as late as possible. Such as HTML encoding when output as HTML to an HTML page, and parameterised when inserting into a database. The big advantage of this is that when the data is later retrieved from these locations, it will be returned in its original, unsanitized format.
So if you have the value A&B O'Leary in an input field, it would be encoded like so:
<input type="hidden" value="A& O'Leary" />
and if this is submitted to your application, your programming framework will automatically decode it for you back to A&B O'Leary. Same with your DB:
string name = "A&B O'Leary";
string sql = "INSERT INTO Customers (Name) VALUES (#Name)";
SqlCommand command = new SqlCommand(sql);
command.Parameters.Add("#Name", name];
Simples.
Additionally if you then need to give the user any output in plain text, you should retrieve it from your DB and spit it out. Or in JavaScript - you just JavaScript entity encode (although best avoided for complexity reasons - I find it easier to secure if I only output to HTML then read the values from the DOM).
If you'd HTML encoded it early, then to output to JavaScript/JSON you'd first have to convert it back then hex entity encode it. It will get messy and some developers will forget they have to decode first and you will have &s everywhere.
You can use validation as an additional defence, but it should not be the first port of call. For example, if you are validating a UK postcode you would want to whitelist the alphanumeric characters in upper and lower cases. Any other characters would be rejected or removed by your application. This can reduce the chances of SQLi or XSS occurring on your application, but this method falls down where you need inputs to include characters that have special meaning to your output context (" '<> etc). For example, on Stack Overflow if they did not allow characters such as these you would be preventing questions and answers from including code snippets which would pretty much make the site useless.
Not all SQL statements are parameterizable. For example, if you need to use dynamic identifiers (as opposed to literals). Even whitelisting can be hard, sometimes it needs to be dynamic.
Escaping XSS on output is a good idea. Until you forget to escape it on your admin dashboard too and they steal all your admin's cookies. Don't let XSS in your database.
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.
I made a report with about 30 different rectangles and textboxes that have different visibility expressions depending on the parameters. (It's a student invoice and many different messages have to appear depending on the semester) When I made all the expressions I coded in the parameters in all upper case. Now I have a problem when users enter lowercase letters, the SQL all works fine since it is not case sensitive, but the different rectangles and textboxes don't show. Is there a way in the report code to first capitalize all the parameters before running the SQL? Or do I actually have to go back to every visibility expression and add separate iif's for upper and lower case? (That seems incredibly silly to have to do). I can't change my parameters to numbers because I have been given strict requirements for input. Thanks.
I do not know if this is the most elegant solution, but you could accomplish this by following this procedure for every parameter on the Report Parameters page:
1)Re-name the parameter, leaving its prompt as that of the old parameter.
2)Add a new parameter with the same name as the old parameter.
3)Mark this new parameter as Hidden.
4)Make sure that the new parameter's available values are marked as non-queried(available values will never be actually used.)
5)Mark the Default Values as Non-queried, using the following syntax:
=ucase(Parameters!OldParameterName.Value)
Can't you just UCASE the params (do it in the xml view, it will be quicker and you might even be able to do a regex find/replace)