ScotSoft: Building and Breaking Web Applications

On October 7th I had the pleasure of speaking at ScotSoft 2021 about Penetration Testing and breaking Web Applications. I’ve included my slides from the presentation and some speaker notes on the content covered below:

For this presentation, I opened with my working definition of what Penetration Testing is, to give the audience an idea of what I personally try to deliver to customers when performing penetration testing engagements.

I also added in some details about how, although technology moves quickly, very often cybersecurity appears not to advance as quickly – giving the example of the AIDS Trojan Ransomware from 1989 compared to the Travelex Ransomware of 2020. I’ve also built on this idea in more depth in our Ransomware episode of Core Issues. Long story short, a lot of companies are still struggling with attacks and attacker techniques that are now considered “old” to those working in Cybersecurity.

Therefore it’s important not to over-focus on “interesting” or “cool” vulnerabilities that are the latest developments but instead try and focus on what the company are trying to gain form the engagement and try and deliver the most value to the customer throughout the penetration test.

Building on this I also add the fact that very often companies may struggle with cybersecurity topics – there’s a few different reasons for this such as the fact that security is only one thing that a company has to perform and so it’s competing with other priorities – but in this case I raised the fact that often, best practice can be confusing or misleading for companies. The examples that I use to make this point is whether password rotation and password complexity should be enforced.

The NCSC and NIST 800-63B both state clearly that these should not be used. However, PCI DSS 3.2.1. mandate both of these controls.

Note: Regarding complex passwords, PCI DSS 3.2.1 also states “Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.” Which I acknowledge does allow for different controls and the use of passphrases in the way the NCSC recommends, however I’d still consider this stating mandated complexity is the “default” whereas the NCSC guidance is very clear at: “Do not use complexity requirements.”

Building on this I give some recent examples I’ve seen of companies using, what I would personally consider, bad password policies. I have a range of examples of this from cybersecurity conferences, to pizza stores, to online banking platforms – simply put, it’s very common to see short password requirements (e.g. minimum length of 6 characters on an online bank) and complexity enforced.

My recommendation for those hearing this discussion on the benefits and drawbacks of password complexity and password rotation is to check out some of our previous articles that go into far more depth on this topic:

• Strong Passwords: The Problem with Rotation
• Strong Passwords: The Problem with Complexity
• Strong Passwords: Three Random Words

Moving on from problems with Best Practice I discuss one of my favourite vulnerabilities: Cross-site Scripting. I cover the fact that, whilst it is issue number 7 on the OWASP Top 10 it’s still often reported as the most common web application issue. This is in part due to the fact that the order of the OWASP Top 10 is a balance of impact, prevalence and exploitability.

I then gave a quick overview of what Cross-site Scripting is and how it’s exploited – but we’ve covered that topic in these articles before in Finding Cross-site Scripting and Fixing Cross-site Scripting.

Finally, I closed out with importance of not only fixing discovered vulnerabilities, but hardening systems against exploitation – in the case of Cross-site Scripting, this was a look into Content Security Policy – but in short, any time you can make an attacker’s life harder, either complicating exploitation or slowing down exploitation, is going to be a good thing for your system’s defence overall.

That’s it!