From Fuctional Testing To Security Testing

07 Nov 2021 - karit

While at ChCon 2021 I had a discussion about my transition from Functional Software Testing into Pen Testing and how others could have similar jouney. Given that I thought I would make a brain dump of my thoughts, as it may be helpful to others.

tl;dr

Do it - if you have an interest in security and currently do functional testing. There is a lot of overlap in the thought process to be successful in both. If you have an interest in security, make the jump.

My Context

A bit about my history:

  1. I did the Computer Science thing at Uni.
  2. I have always had an interest in the security side of things.
  3. I had some jobs doing functional testing.
  4. Started to add more security perspectives to the functional testing I was doing.
  5. Got a new job in security.
  6. Have now been in security full time for the last six and change years.

The “What Happens If” question

A lot of Pen Testing distils down to the “What Happens If” question. With Pen Testing the question comes through as “What happens if a malicious individual wants to make this system work for them?”. While in functional testing the question is “What happens if the users of the system do things outside of the expected flow or validation?”.

If you have this thought process sorted for functional testing you will most probably do well when applying it to the security context as well. The hard part is finding people who can think that way, adding the new security context viewpoint, to the “What happens if?” question can be taught & picked up; e.g. through reading blogs, going to meetups, watching conference talks, working through online hacking learning platforms like Pentester Labs and working with your teammates.

The diagram below is my thoughts on how you can expand this question out through the testing process. Hacking is just testing the malicious flows through the application: Diagram with three nested circles. The inner one is "Normal Flows", the next layer is "Non-malicious unexpected flow" and the other is "Malicious Flow".

You may be doing security testing already…

You may be doing security testing already and not even know it. For example, say you are testing a field that accepts name inputs and decide to with names that contain a ' e.g. O'Reilly or - e.g. a double-barrelled surname and the form breaks or strips the character. Wearing a functional testing hat you may raise a bug with the title “Name field dropping single quote”. That is an important bug to find, but you have also likely found a security bug without realising it.

The dropping of the single quote may indicate that the developers may have implemented a vulnerable SQL injection (SQLi, pronounced “squeely”) mitigations. So viewing the same issue from a security standpoint, it turns into quite a different issue from being purely functional bug. Congrats you have found a security issue without even possibly realising it.

Colouring outside the lines

When doing functional testing for Role Base Access Control (RBAC), it is likely the testing will focus on if the users “can do what they are meant to do”. Security testing of RBAC is the inverse “can users do anything which they are not meant to do”. The prep is the same, but just this time just testing the other side of the lines.

Bugs Reports Vs a Finding in a Pen Test Report

Bug reports will often already contain most of the core information which a Finding in a Pen Test Report does:

There will be some differences, though a lot of those should be supported from the “Canned Findings” repository. These will be things like:

Though these differences should be quick to pick up. Supportive team members should get you up to speed on these differences quickly.

Additionally to a few more sections in the findings, another difference is tying it all together with an executive summary in the report. Though this is a written form of the triaging and champion of bugs which is likely taking place in the daily stand-ups or triage meetings, so this is something you are all likely doing as well.

Context

I have found functional testing set me up with a good skill base to understand the end-users and how the business uses the system. I personally find this is a really helpful skill to have in security testing as it helps in articulating the issue to the business and understanding what issues will have the greatest impact on the business.

When on an internal Red Team style job it is helpful finding the meaningful assets which will mean more to the business when say got access to them than saying got access to Domain Admin (DA). Outside of the IT team getting DA does not mean much to the business, though saying got full access to the data the key application of the business is more impactful.

Summary

All testing be it functional or security has the “What happens if” question at the centre. This is a key thought process and is needed to be successful in security testing. The journey is about gaining more security perspectives, so can look at the application from a security perspective alongside that of a functional perspective. Even now while doing security testing I still observe functional issues in the applications I test and try hard not to rage and point out all the functional bugs as well.

If you have an interest in security and you have gathered some security perspectives, you will have a solid foundation to start looking for security testing roles.