XSS testing in Testing Fundamentals - Test Execution Trace

Test Overview

This test checks if a web application is vulnerable to Cross-Site Scripting (XSS) attacks by injecting a script payload into an input field and verifying that it does not execute.

Test Code - Selenium with Python unittest

Testing Fundamentals

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import unittest

class TestXSS(unittest.TestCase):
    def setUp(self):
        self.driver = webdriver.Chrome()
        self.driver.get('http://example.com/comment')

    def test_xss_injection(self):
        driver = self.driver
        # Locate the comment input box
        comment_box = WebDriverWait(driver, 10).until(
            EC.presence_of_element_located((By.ID, 'comment'))
        )
        # Inject XSS payload
        xss_payload = '<script>alert("XSS")</script>'
        comment_box.clear()
        comment_box.send_keys(xss_payload)

        # Submit the comment
        submit_button = driver.find_element(By.ID, 'submit-comment')
        submit_button.click()

        # Wait for the comment to appear
        comment_display = WebDriverWait(driver, 10).until(
            EC.presence_of_element_located((By.ID, 'comment-display'))
        )

        # Verify that the script tag is not executed but escaped or removed
        page_source = driver.page_source
        self.assertNotIn('<script>alert("XSS")</script>', page_source, 'XSS script tag found in page source')

    def tearDown(self):
        self.driver.quit()

if __name__ == '__main__':
    unittest.main()

Execution Trace - 7 Steps

Step	Action	System State	Assertion	Result
1	Test starts and browser opens	Browser window opens at http://example.com/comment page	—	PASS
2	Waits for comment input box to be present	Comment input box with id 'comment' is visible on the page	Presence of element located by ID 'comment'	PASS
3	Injects XSS payload '<script>alert("XSS")</script>' into comment box	Comment input box contains the XSS payload text	—	PASS
4	Clicks the submit button with id 'submit-comment'	Form is submitted, page reloads or updates to show the comment	—	PASS
5	Waits for the comment display area with id 'comment-display' to appear	Comment display area is visible showing submitted comments	Presence of element located by ID 'comment-display'	PASS
6	Checks page source to verify script tag is not present	Page source loaded after comment submission	Assert that '<script>alert("XSS")</script>' is NOT in page source	PASS
7	Test ends and browser closes	Browser window closes	—	PASS

Failure Scenario

Failing Condition: The page source contains the injected script tag, indicating XSS vulnerability

Execution Trace Quiz - 3 Questions

What does the test verify after submitting the comment with the XSS payload?

A That the alert popup appears

B That the script tag is not present in the page source

C That the comment box is cleared

D That the submit button is disabled

Key Result

Always verify that user inputs are properly sanitized or escaped to prevent XSS attacks by checking that injected scripts do not appear or execute in the page output.

Practice

1. What is the main goal of XSS testing in software testing?

easy

A. To check if harmful scripts can run on a website

B. To test website speed under heavy load

C. To verify database backup integrity

D. To check user interface responsiveness

Solution

1. Step 1: Understand XSS testing purpose

   XSS testing aims to find if malicious scripts can run on a website, which can harm users or data.

2. Step 2: Compare options to XSS goal

   Only "To check if harmful scripts can run on a website" matches the goal of detecting harmful script execution on websites.

3. Final Answer:

   To check if harmful scripts can run on a website -> Option A

4. Quick Check:

   XSS testing = harmful script check [OK]

Hint: XSS testing checks for harmful scripts running on sites [OK]

Common Mistakes:

• Confusing XSS testing with performance testing
• Thinking XSS tests database or UI only
• Ignoring script execution risks

2. Which of the following is a correct example of an XSS test input to check script injection?

easy

A. SELECT * FROM users;

B. <script>alert('XSS')</script>

C. DROP TABLE users;

D. console.log('test')

Solution

1. Step 1: Identify typical XSS test input

   XSS tests use script tags like <script>alert('XSS')</script> to check if scripts run on the site.

2. Step 2: Eliminate unrelated inputs

   Options B and C are SQL commands, not XSS scripts. console.log('test') is JavaScript code but not wrapped in script tags for injection.

3. Final Answer:

   <script>alert('XSS')</script> -> Option B

4. Quick Check:

   Script tags = XSS test input [OK]

Hint: XSS test inputs use <script> tags to inject scripts [OK]

Common Mistakes:

• Using SQL commands as XSS inputs
• Not wrapping JavaScript in script tags
• Confusing console logs with injection

3. Given this input in a web form: <img src=x onerror=alert('XSS')>, what is the expected result if the site is vulnerable to XSS?

medium

A. The image will load normally without alert

B. The input will be saved as plain text without alert

C. The form submission will fail with an error

D. The alert box with message 'XSS' will appear

Solution

1. Step 1: Understand the input behavior

   The input uses an image tag with an invalid source and an onerror event that triggers an alert. If the site is vulnerable, this script runs.

2. Step 2: Predict the output on vulnerability

   If vulnerable, the alert('XSS') will execute, showing a popup message.

3. Final Answer:

   The alert box with message 'XSS' will appear -> Option D

4. Quick Check:

   onerror alert triggers popup if vulnerable [OK]

Hint: onerror event triggers alert if XSS vulnerability exists [OK]

Common Mistakes:

• Assuming input is saved as text without execution
• Thinking image loads normally despite invalid src
• Confusing form errors with script execution

4. You wrote this test input to check XSS: <script>alert('test')</script>. The alert does not appear, but the input is stored and shown as text on the page. What is the likely reason?

medium

A. The site properly escapes script tags to prevent execution

B. The browser blocked all JavaScript on the page

C. The input was rejected and not saved

D. The alert function is disabled in the browser

Solution

1. Step 1: Analyze why alert did not appear

   The alert script is stored and shown as text, meaning it was not executed but escaped.

2. Step 2: Identify cause of script escaping

   Proper XSS protection escapes script tags so they display as text, preventing execution.

3. Final Answer:

   The site properly escapes script tags to prevent execution -> Option A

4. Quick Check:

   Escaping scripts = no execution [OK]

Hint: Escaping script tags stops alert from running [OK]

Common Mistakes:

• Assuming browser blocked all JavaScript
• Thinking input was rejected when it was saved
• Believing alert function is disabled

5. You want to test if a website properly blocks XSS attacks in both URL parameters and form inputs. Which combined approach is best?

hard

A. Test URL parameters with SQL commands and form inputs with numbers

B. Only test form inputs with normal text values

C. Inject <script>alert(1)</script> in URL and form fields, then check if alert appears

D. Use browser developer tools to disable JavaScript and test inputs

Solution

1. Step 1: Understand testing both input types

   XSS can happen via URL parameters or form inputs, so both must be tested with script injections.

2. Step 2: Choose effective test input and verification

   Injecting <script>alert(1)</script> is a simple way to check if scripts run. Observing alert confirms vulnerability.

3. Final Answer:

   Inject <script>alert(1)</script> in URL and form fields, then check if alert appears -> Option C

4. Quick Check:

   Test scripts in URL and forms to find XSS [OK]

Hint: Test script injection in both URL and forms for full coverage [OK]

Common Mistakes:

• Testing only one input type
• Using unrelated inputs like SQL commands
• Disabling JavaScript instead of testing execution