Recently, Koru had a penetration test done by an independent third party. The actual test took place a little before I had joined but the results only came in afterwards. Having never read through a pentest report, I was curious to see what they would find and more importantly how. Having been listening to copious amounts of DarkNet Diaries, I thought we were in for something along the lines of "we have all your data and locked you out" level of intrusion.
Thankfully, that wasn't the case. Instead we got a 6 page report outlining the findings. Being fairly unfamiliar with the system at the time (it was literally my first week), it was interesting to gain the insights that the document provided. Reflecting on it now, it's not incredibly surprising, we use a set of very tight VPC's to separate each clients data and the only frontend exposure is on a static website; So there are no chances of XSS attacks.
The first discovery which was considered Number 1 priority turned out to be rather humorous. It was discovered that the API returned an "X-Powered-By" header (which tells the client what library or language the service is written in) of "PHP 5.1". I was a bit puzzled by this as the entire stack was Javascript or Python. After some digging I discovered the following code in the Express server declaration.
The express X-Powered-By header code forgery
Sneaky beaky
This was a sneaky tactic... and very funny. This got removed to not return an X-Powered-By header at all.
Additionally, the pentest had pointed out that we did not have a password reset functionality when inside the application. This didn't seem like a security issue but the reasoning behind it was if the account was compromised then the user could take protective action and change their password right there and then. An edge case certainly, but interesting nonetheless. This feature has been more of a pain that we anticipated since Auth0 helpfully doesn't return the "reason" why a password was too weak when changing the password via the API. This is not a nice UX so although the feature has been built, it has not been released.
In connection with this, they pointed out that our password policy was incredibly lenient. Since we use Auth0 as our identity provider, this was a simple matter of upgrading the password requirements, turning on their common password list protection (to prevent highly used passwords like "hunter2") as well as configuring a bespoke list of blacklisted words such as our company name and some industry specific terms.
Another feature we lacked was no Multi-factor authentication. This was an important feature to have, as increasingly enterprise customers are requiring it from their suppliers. Again, since we use Auth0 this was fairly trivial to add, despite bending the UX flow they recommend (which isn't that great).
After this was a number of minor points around the Content Security Policy as well as the headers that were being sent with requests. In the case of the latter, this was solved by the defaults of helmetjs. For the CSP, this required a lot of back and forth configuring all the URL's we let through. In doing so, it made me realise just how much of the web is powered mostly by third parties. Our site has a intercom integration, Auth0, a few JS and CSS libraries and some Google Analytics for good measure, but even not having 1 of those components had ripple effects right across the site. The web is incredibly fragile and it's made me wonder if we need all of it?
I personally have Google Analytics configured on my blog, but I can't tell you the last time I looked at it or even did anything with the data. It simply has been hoovering up data for the big Google machine. The case is similar with the Intercom button, I've personally never once used one and it seems as this recent tweet states, no one else does either...
Here's why these auto-messages with the same text for every visitor simply don't work (over 14K sent, 88% opened, only 3% replied and thus 85% just distracted and probably annoyed): pic.twitter.com/GOAVQAp4BJ
— Yury Smykalov (@ysmykalov) October 10, 2019
Are these things a bad thing? Sometimes yes, sometimes no. I know for a number of companies and even peoples jobs literally revolve around Google Analytics, and that's super cool. But for a lot of a websites and apps, it's just not needed. It's another case of someone saying "oh we should have this so we can track X". Then "X" is forgotten and the person who wanted it in the first place leaves, and then it's just left. Silently slurping data in the shadows.
That was a little tangent, but you get my point. Overall, my experience of having a pentest done was very positive and I'd recommend it for any organisation. Security is something that is always said to be priority number 1 on peoples list, but no action is taken; ergo it's not actually priority number 1. These kind of insights from a third party can quickly and easily give you industry level knowledge on how to prevent issues proactively - which is a hell of a lot cheaper than fixing them retroactively.