Security Testing: An Essential Tester Skill
Updated: Apr 12, 2021
You don't have to know a lot to find security vulnerabilities in software. In fact, you don't really have to know anything...trust me. Two weeks ago I found a pretty critical XSS vulnerability in my company's software on my first try. Don't get me wrong, I am no security wiz. My knowledge is limited to podcasts and late-night googling and if you asked me what this year's OWASP top ten are I could probably name three. Yet I was still able to find some crucial security bugs and I think you can too!
We're not about to jump into HTTP smuggling, internal port scanning, or anything else that may require third-party software. Nah, we're going to talk about CPL tests, Copy. Paste. Look. If you can copy, paste, and look (or listen) at a result you are fully capable of executing these tests and you can hopefully find some pretty sick bugs!
Before getting started here you need to ensure that the firewall settings in your development environment match the firewall settings in your live environments. Organizations will sometimes have stricter WAF settings for their development environments but this will inhibit your security testing efforts. Talk with your manager or your team's security expert and find out how to deploy an environment with security settings that mirror a live environment.
If you can't get a work environment to test with but still want to learn you can always use the OWASP juice shop.
Cross-Site Scripting (XSS)
What it is: Cross-site scripting is one of the most common vulnerabilities that is missed, which is CRAZY because it's so easy to test! XSS occurs when you are able to inject your own HTML into a website.
Where to Test: Any input field. This is especially dangerous where the information is saved to a database then displayed to other users, like a comment section on a social media site.
How to test it: Copy, Paste, and look. If you are familiar with writing HTML then have at it. If you aren't follow these steps:
Click into the input field
Paste this: <script\x20type="text/javascript">javascript:alert('pwned');</script>
Enter
What happened? Anything weird? Did an error pop-up? If an alert popped up that said 'pwned' then you've found a vulnerability.
To have even more fun try using some of the injections from this excellent Github page: https://github.com/payloadbox/xss-payload-list
SQL Injections
What it is: SQL injections are SQL commands executed outside of the allowed processes. As an internal tester you have the greatest advantage to finding and preventing these vulnerabilities because you already know the database queries.
Where to test it: Any input field. This is especially dangerous if the input field is interacting with the database (ie, a search field for a program on a gym website, or a page where you view user data).
How to test it: Here is where looking becomes important. You don't need to get the database to drop a list of users to find a vulnerability, you just need some kind of response that let's you know you have undesirable access. To see this response you'll need to watch the network traffic. (Right-click anywhere, select 'Inspect Element', Click on the 'network' tab).
Click into an input field
Type in any SQL query (List of examples here)
Submit your query or request
Click on the request that was initiated in DevTools
Verify there is nothing unexpected in the response
Sensitive Data Exposure
What it is: It is what it says it is. Private information being exposed when it should not be exposed. This often happens when an API returns all user data, but the front-end only displays the information the user has access to. However, if that user inspects the response from the API they can see all the information the UI masked.
Where to test it: Any area where vulnerable information may display. This occurs often when information is masked on the front-end but is not controlled with permissions on the back-end.
How to test it: DevTools! Right-click, select 'Inspect Element' > 'Network' and you're ready to go!
Log into your system with a user that has fewer permissions
Click around the system while inspecting elements
View the responses from requests and verify private information does not display in the API response
If you've made it to the end of this list, congrats! I know some of these steps and processes are nebulous and getting started can be intimidating. I'd encourage you to just try one thing this week in your testing. Just try one xss attack and see how it goes!
If you've made it to the end of this list and you're SUPER excited about security testing I'd recommend checking out the OWASP top ten and listening to some Darknet Diaries.
Inspired by: https://club.ministryoftesting.com/t/bloggers-club-april-2021-the-essential-skills-for-testing/48977