Security Testing for Manual Testers
Sometimes, as a test engineer, you need to check that your web application is not vulnerable.
I am not going to describe what security testing is because there are many introductory articles about it. In some companies, security testing or vulnerability assessment is performed by penetration testers from a special team or by the information security department, but it happens that such kind of activities have to be done by ordinary manual testers.
I would like to list practical actions of a brief security testing that can be performed manually and right away without additional tooling.
The main testing landmarks are:
- HTTPS
- XSS (Cross-site scripting)
- SQL Injection
- CSP (Content Security Policy)
- CORS (Cross-Origin Resource Sharing)
- CSRF (Cross-Site Request Forgery)
- Open Redirect
HTTPS
Manual testing of your web application over HTTPS means performing a regression run with HTTPS in URLs.
If all functionality works as expected, then it is OK, but here are a few tips:
1. URLs with HTTP protocol should redirect to HTTPS. This is a server’s side setting and a part of nonfunctional requirements — ask your developers about it.
If there is no redirect, then use a browser extension for automatic redirection from HTTP to HTTPS:
- HTTPS Everywhere or Smart HTTPS for Firefox;
- HTTPS Everywhere for Chrome.
Some browsers (Firefox since version 83 and since version 91 in Private mode) do it by default without any extensions.
2. Check the certificate for validity.
Firefox: under the «protection» icon in the URL bar (since version 70, it is not colored green):
Chrome: under the same «protection» icon or in the Security Panel in DevTools:
3. Watch out for mixed content!
All your data should be loaded over HTTPS. If your page is loaded over secure HTTPS, but other resources (images, videos, scripts) are loaded over an insecure HTTP, you’ll be notified about it in a browser’s Console. In some cases, mixed content may be the reason that some of the data may not be displayed on the web page.
4. All URLs inside <head> tag should have HTTPS protocol.
Check href, content, and src attributes in <link>, <meta>, and <script> tags:
5. All sharing widgets should provide HTTPS URLs.
Check pop-ups of Facebook, Twitter, or «Copy link» buttons: all shared links should have HTTPS protocol. Click on it and check what link is going to be shared.
Further reading:
XSS (Cross-site scripting)
Cross-site scripting is the most common security vulnerability that can be found in web applications. It enables the attacker to put his client-side script into a web page, and this script will be executed when another user opens a spoofed page.
The most common types of XSS are:
- Reflected XSS, when script executes immediately (in search suggestions or by following a link with XSS in URL);
- Stored XSS, when script saves (as a user’s comment) and executes when another user opens the page.
For both types of XSS we will test how developers coped with escaping special characters to prevent XSS attacks.Some developers argue that escaping should be done on frontend, and others argue that it should be done on backend, but for safety, it must be done both on frontend and backend.
The principles of testing XSS are:
1. Take the XSS vector → put it in all forms and inputs → press [Enter] → see what happens;
2. Take the XSS vector → put it URL → press [Enter] → and see what happens.
The main thing in these cases is to have a set of universal XSS vectors, for example:
<XSS>'':! — "<hr/>&{()}<img/src='x'onerror=alert(1)>"<img/src='x'onerror=alert(1)>"@gmail.com<%2Ftitle><svg%2Fonload%3Dprompt'XSS'>javascript:/* →</marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression(/*’/-/*',/**/eval(name)//);width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"- For URL:
#'"><script>prompt(document.domain)</script>1
More examples:
If your web application is based on a popular UI framework, then with a high probability, it has protection for XSS attacks «out of the box», but the manual check will not be superfluous.
3. Check for an X-XSS-Protection header.
This header stops pages from loading when they detect reflected cross-site scripting attacks. This feature only partially protects against XSS attacks because it is supported only by a few browsers. At least, expect to see (or ask developers to add) this value:
x-xss-protection: 1; mode=blockFurther reading:
- XSS Game;
- What is the http-header “X-XSS-Protection”?
- XSS Prevention Cheat Sheet for Penetration Testers.
SQL Injection
For brief manual testing without special knowledge, SQL injection may be the same as XSS.
You should put SQL injection payloads in the forms and inputs in the hope they will not crash your web application.
Further reading:
- SQL Injection and SQL Injection Prevention Cheat Sheet;
- SQL injection and SQL injection cheat sheet;
- SQL Injection Cheat Sheet.
CSP (Content Security Policy)
According to Content Security Policy, the source code on the site could be loaded only by the site itself (same-origin policy) or from allowed sites (resources). This is one of the ways to protect against XSS attacks — if the attacker somehow implemented a link to his script into your site, this script will not be loaded from the attacker’s resource because this resource is not in the allowlist.
For example, scripts, images, and other content on https://developer.mozilla.org can be loaded only from https://developer.mozilla.org OR from the allowed sites.
The allowlist of Content Security Policy resources can be found in response headers:
The testing vectors are:
1. All allowed resources are loading;
2. Watch out for errors of blocked content in a browser’s Console.
Common case: developers forget to put some allowed resources in a white list, and due to this, this resource does not load.
3. All data from not allowed resources is blocked.
To test that third-party resource does not load, you can run this script in the browser’s Console:
fetch("https://example.com/").then(response => response.json()).then(data => console.log(data));If you see the Content Security Policy error: «The page’s settings blocked the loading of the resource…» — then the test passed.
CORS (Cross-Origin Resource Sharing)
According to Cross-Origin Resource Sharing (based on HTTP-headers), a site can give permission to third-party sites to have access to its content.
How to test:
1. Make an HTTP request:
curl -i 'https://example.com/' -H 'Origin: http://evil.com/'If you will see the Access-Control-Allow-Origin response header — it is a bug. It means that our site (https://example.com) gives access to an absolutely unknown resource.
2. Watch out for errors of blocked content in a browser’s Console:
Further reading:
CSRF (Cross-Site Request Forgery). Here, in terms of defense
CSRF is a name for a type of attack when an unauthorized command is submitted from a trusted user. In most cases, this command includes in the URL as a malicious parameter, for example:
https://example.com/?action=delete_session_id&id=123To prevent such kinds of actions, sites can implement unique tokens in each truthful request (in GET parameter, in the header, or as a cookie), for example:
curl -X POST 'https://example.com/' -H 'X-CSRF-Token: iFr6yAmP3pelSbey2'There are two test cases:
- If you know that your site has CSRF tokens, you can:
Make a request without a CSRF token or with a spoiled CSRF token — in this case, you should not get a valid response.
2. Or, if your site does not have CSRF tokens, you still can try to make an unauthorized request:
Steps:
- Find POST request on your site;
- Make an HTML file with a button that will run this request, but without any headers:
<html><head></head><body>
<form method="POST" action="https://accounts.firefox.com/metrics">
<input type="submit" name="button" value="OK"></form>
</body></html>3. Open your HTML file and click on the button (run the request).
If you see response code = 400, 401, 403, or 404 — it is OK, at least your site does not allow unauthorized requests.
Further reading:
Open Redirect
If your web application supports Open Redirect, then it has potentially vulnerable functionality.
How does it work? If you pass in the URL a GET parameter with the link, then a passed link will be opened. The GET parameter for redirection in URL could be arbitrary (as developers decide, usually: url, link, retpath, or continue), for example:
https://example.com/destination?retpath=http://example.com/redirectionInstead of open /destination, it will redirect to /redirection.
Open Redirect is commonly used during authorization when the user should be returned to the original page after logging in ⇒ the Open Redirect links should be strictly validated to prevent redirects to third-party sites.
The testing vectors are:
- Redirect works only for allowed sites (ideally, only for URLs of the same domain);
- Redirect does not work for third-party sites.
If you try to open https://example.com/?url=https://mozilla.org, only example.com site should open:
As I pointed out at the beginning, I have listed only brief checks for manual execution. Of course, there are a bunch of tools for deep security testing, like Burp.
Further reading:
