Security Testing Fundamentals

# CHAPTER 12

Security Testing Fundamentals #

1. Introduction #

2. Learning Objectives #

• Understand the critical role of QA in identifying basic security vulnerabilities.

• Define and manually test for SQL Injection (SQLi) flaws.

• Define and manually test for Cross-Site Scripting (XSS) flaws.

• Execute rigorous Authentication and Authorization testing.

• Utilize a basic security validation checklist during standard functional testing.

3. Authentication vs. Authorization #

• Authentication (Who are you?): Testing the login process. Does the system correctly verify passwords? Are sessions timed out securely?

• Authorization (What are you allowed to do?): Testing permissions. If User A logs in, can they manually change the URL to /admin/delete_users and successfully execute the action, bypassing the UI? (This is a catastrophic failure known as "Broken Access Control" or IDOR).

4. SQL Injection (SQLi) #

• The Concept: A developer takes input from a search bar and directly concatenates it into a raw database query.

• The Attack: A hacker types ' OR '1'='1 into the password field. The database interprets this as a true statement and logs the hacker in without a password.

• QA Testing: A QA Engineer should always try typing basic SQL characters (like ' or "; DROP TABLE users;) into input fields. If the application crashes with an SQL syntax error, it is highly likely vulnerable to injection. It should fail gracefully with a validation error.

5. Cross-Site Scripting (XSS) #

• The Concept: A hacker injects malicious JavaScript into a website (e.g., by posting it in a public comment section).

• The Attack: When a normal user loads the page, the hacker's JavaScript runs in the user's browser, stealing their session cookies and sending them to the hacker.

• QA Testing: A QA tester enters <script>alert("XSS HACK!")</script> into a comment box or profile name field. If the website literally pops up an alert box when the page reloads, the site is vulnerable. The site must "sanitize" or "escape" the input so it renders as harmless text, not executable code.

6. Security Testing Checklist (The QA Baseline) #

• [ ] Are passwords masked in the UI?

• [ ] Does the app enforce a strong password policy?

• [ ] Does the session expire after 15 minutes of inactivity?

• [ ] Does the app lock the account after 5 failed login attempts (Brute Force protection)?

• [ ] Are all API endpoints restricted to authorized users only?

• [ ] Does the application sanitize all HTML/JavaScript inputs to prevent XSS?

7. Visual Learning: Broken Access Control (IDOR) #

[ Normal User Flow ]
1. Logs in as User ID 10.
2. Clicks "My Invoice".
3. Browser requests: GET /api/invoices/10. (Returns Invoice).

[ The QA Security Test (The Attack) ]
1. Still logged in as User ID 10.
2. Manually edits the URL in the browser bar.
3. Browser requests: GET /api/invoices/11. (Trying to see User 11's invoice).
*Result:* If the API returns User 11's invoice, the system FAILED the Authorization test. It must return a 403 Forbidden.

8. Best Practices #

• Never Store Secrets in Code: During testing or code reviews, if a QA Engineer sees an AWS API key or database password hardcoded in plain text in a .js or .php file, it is an immediate critical security failure. Secrets must live in environment variables (.env).

9. Common Mistakes #

• Security as an Afterthought: Many teams only think about security the day before launch. They hire a Pen-Tester, who finds 50 critical vulnerabilities, delaying the launch by three months. Security testing must be integrated into the STLC during the daily Sprint cycles.

10. Mini Project: Test for XSS #

1. 1. Navigate to Edit Profile.

1. 2. In the "Bio" text area, enter the following exact string: Hello! <script>alert("Your site is broken")</script>

1. 3. Click Save.

1. 4. Navigate to the public view of the profile.

11. Practice Exercises #

1. 1. Define the difference between Authentication and Authorization.

1. 2. Explain how a QA Engineer performs a basic manual test for Cross-Site Scripting (XSS) in an input field.

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the concept of Insecure Direct Object Reference (IDOR). How would you test an API endpoint (e.g., GET /user/data?id=5) to ensure it is not vulnerable to IDOR?

• Q: A developer tells you, "We use HTTPS, so our application is completely secure from hackers." As a QA Engineer, explain why encryption in transit (HTTPS) does absolutely nothing to stop application-level vulnerabilities like SQL Injection.

• Q: Walk me through a basic Security QA checklist you would execute before signing off on a new "User Login" feature.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #