Cross-Site Scripting (XSS)
What is Cross-Site Scripting? Cross-site scripting, also known as XSS, is a type of security vulnerability typically found in Web applications. It occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink that contains malicious content. Browsers are capable of displaying HTML content and executing JavaScript. If the application does not escape special characters in the input/output and sends the user input back to the browser, an attacker may be able to launch an XSS attack successfully. Through which malicious files can be executed, session details of a logged-in user can be stolen, or Trojans can be installed. Types of XSS: The non-persistent (or reflected) Cross-site scripting vulnerability is the most common type. A non-persistent XSS vulnerability occurs when the data provided by the attacker is immediately executed and a generated page is returned to that user. The persistent (or stored) XSS vulnerability occurs when the data provided by the attacker is saved in the server, and permanently displayed on web pages returned to other users. Another type of XSS attack is DOM Based on XSS. DOM Based XSS (type-0 XSS) is an attack wherein the attack payload is executed as a result of modifying the DOM environment in the victim’s browser. How to Perform XSS Testing: Submitting malicious script through text inputs List out all the text input fields [Text box, Text area] in the application. Submit simple javascript code, like ‘<script>alert(“XSS”)</script> through each identified text input field. If the text box is vulnerable, an alert with the text mentioned in the quotes will be returned. Submitting malicious script through an application URL Modifying the requests using security testing tools like Burp Suite to test for application vulnerability Capture the request using the Burp tool Append malicious script in the captured request ‘Forward’ the modified URL Validate the result How to prevent XSS attacks are possible mainly because the server is not handling special characters in the output. There are 2 broad strategies for defeating XSS: Whitelisting Good inputs Whitelist: Create a whitelist of characters required by the application. Once the whitelist is ready, the application should disallow all requests containing any character apart from those in the list. Blacklisting Bad input Blacklist: The application should not accept any script, special character, or HTML in fields whenever not required. It should escape special characteristics that may prove harmful. Some of the special characters used in the script that must be escaped are <>()[]{}/\*;:=%+^! Have questions? Contact the software testing experts at InApp to learn more.
Creating AdvancedTest Plan in JMeter
The need for creating an Advanced Test Plan comes in when the test requires any of the following The need to validate results based on updates to a field in the DB To use Input File in order to parameterize the input variable Use of While, If-Else controller Steps to be followed while recording an advanced script Open a new Test Plan Right-click on Test Plan->Add->Threads (users)->Thread Group Right-click on Thread Group->Add->Config Element->CSV Data Set Config Right-click on Thread Group->Add->Config Element->Http Cookie Manager Right-click on Thread Group->Add->Config Element->Http Header Manager Right-click on Thread Group->Add->Logic Controller->Transaction Controller Right-click on Thread Group->Add->Logic Controller->Recording Controller Right-click on WorkBench->Add->Non-Test Elements->Http Proxy Server Click on HTTP Proxy Server, and from the Target Controller Drop down select ‘Transaction Controller->Recording Controller’ To exclude images, Add rows in the ‘URL Patterns to Exclude’ and use the code ”.*\jpg” , “.*\gif” , “.*\png” Right-click on Recording Controller->Add->Config Element->JDBC Connection Configuration. This is used to create a Database connection. We include Database URL, JDBC Driver Class, Username, and Password Right-click on Recording Controller->Add-> Config Element->User Defined Variables. This is used to replace Hard-coded values say Username, Syntax is ‘Variable name = Variable value’ and use ${variable name} in the script instead of hard-coded value(s). Right click->Recording Controller->Add->Logic Controller->While Controller Right-click on While Controller->Add->Sampler ->JDBC Request. This sampler is used to send SQL Query to the Database. Note: Before using JDBC Request Sampler we need to set up the ‘JDBC Connection Configuration’ configuration element Right-click on While Controller->Add->Sampler->Debug Sampler. It generates the sample of all values of JMeter variables Similarly, we can generate a sample of all values of JMeter properties and system properties. Presently in our scripts, we set these 2 properties to false. Right-click on While Controller->Add->Timer->Constant Timer This timer pauses for the set amount of time between requests. If we don’t add a delay, JMeter could overwhelm the server by making too many requests in a short amount of time. Please note Before recording go to Internet Explorer->Tools->Internet options->Connection->LAN settings Check the Proxy server, address: localhost; port: 8080, click ok Click on Start to record the script Once the recording is over, click Stop and save it as a JMX file Using Transaction Controllers in the Test Plan Grouping the test action within a Transaction Controller helps the normal user to understand the script more effectively than recording an entire script in one full stretch. To add a Transaction Controller, right-click on Thread Group->Add->Logic Controller->Transaction Controller Transaction Controller measures the overall time taken to perform nested test elements Once the entire script is executed, click on View Results Tree and select Transaction Controller, this controller gives the overall time taken to process the request (load time). The load time will is shown in milliseconds. For n multi-users, once the scripts are executed there will be ‘n’ Transaction controllers within the View Results Tree. Each Transaction controller when clicked shows 3 tabs – Sampler, Request, and Response. By default, the sampler tab is shown. Assume a user logins to an online shopping website and performs a search on 5 different products. While the script is under execution, the progress of the script parsing through 5 different products is reflected in the statement – “Search Transaction Controller 1-4”. This means of the 5 searches, 4th has been completed. Merging Scripts Two or more scripts can be merged into a single Test Plan. Assume we have three scripts merged in the order say Create Profile (This script is executed by 10 users) Basic Search (This script is executed by another 10 users) Signing up on an online shopping website (This script is executed by another 5 users) Steps to be followed while merging the scripts Open any existing test plan say ‘CreateProfile.jmx’ Right-click on Test Plan-> Merge Select the test plan which you want to merge say ‘BasicSearch.jmx’ A new thread group is displayed along with the existing thread group In order to avoid confusion, it would be better to rename the thread group(s) merged. When the merged script is executed, there will be 25 (10+10+5 users) Transaction controllers now present in the Test Plan. During execution, each of the 3 merged scripts will be tracked independently, i.e if the Transaction Controller shows ‘Basic search Transaction Controller 2-6’; this implies the 6th search of the 2nd merged script has just completed execution. Input File (Comma delimited (CSV) file) The recorded scripts can be executed with multiple users, by parameterizing our scripts. This can be done in two ways: User-defined variables Input file CSV file is very useful while executing the JMeter script(s) with ‘n’ multiple users. The attached screenshot (CSV.jpg) has 3 columns. The first column is for Username, the second column is for password and the third column is for the server name. On executing the script after parameterizing, the script fetches the value from the CSV file, substitutes it with the corresponding request, and sends it to the server. Points to be noted while using a CSV file Open an Excel file and provide the required information say Username, Password, Server name, etc under each column that we would like to pass as an input parameter to the script. Save the Excel file as .csv In the Test plan, configure CSV Data Set Config as follows, click on CSV Data Set ConfigCSV Data Set Config as follows, click on CSV Data Set Config Filename: filename.csv File encoding: leave it blank Variable Names (comma-delimited): Specify the names for parameters (values) specified in each column in the CSV file. Later use this variable name in the script as ‘${variablename}’ Delimiter (use \t for tab): , Allow quoted data?: False Recycle on EOF?: True Stop thread on EOF?: False Sharing mode: All threads Note: The first variable name entered in the Variable Names text box contains the value of the first column of the CSV file and so on. Replace values with corresponding variable names in the form ‘${variable name}’ throughout the script. It would be even better to rename the