Common pitfalls with application security

The code you write will end up as the product your customers use. Application security can be a very long and windy road, but like a lot of what’s being written in these posts, this journey can be started with simple strategies and open-source helpers.

We’re focusing on three topics; not committing secrets to source code, checking for vulnerabilities in the third-party dependencies you use, and learning about secure coding practices.

All software will have secrets, such as credentials to log into a database or authenticate with an API. Don’t commit or store these secrets in the source code. If you do it by accident, rotate that secret since it should be treated as compromised.

By design, source code repositories keep a history of everything and make it difficult to remove anything. It’s all too easy to accidentally publish a public repo or have a backup service that copies data from your local machine to a cloud storage service.

A prime example is having a public repo on GitHub for SDKs and accidentally committing an integration secret. Attackers regularly scan the GitHub “firehose” for secrets in real time and will take automated action with that API secret instantly. If they’re nice, you’ll get an email at your security@yourdomain distribution list to let you know of the vulnerability.

Basics to get started? Use environment variables for the secrets and don’t commit that file. Have your team peer review the code before merging and include checks for secrets in that process. This article from GitGuardian has a bunch of reasonable advice that doesn’t need any tooling to get started.

What’s next? Start using a tool to help find secrets. GitHub will scan public repositories for well know secret patterns. For anything private or not on GitHub, AWS Lab’s git-secrets and the open-source Gitleaks can help. Use these tools locally to get started and think about how they can be integrated into the pipeline to automate the alerting of secrets detection or prevention of the commit altogether. If you have lots of repos and products, having a commercial tool will help since they will report back to a central console.

What does Kinde do? Our team is versed in peer reviews for all pull requests and checks for secrets during the review process. We’re also using Gitleaks to occasionally scan through our repos for secrets. Currently, this is a manual task, but we’re looking to automate this into our pipeline.

Why code something yourself from scratch when you can use a pre-built library that does the same thing? Regardless of the advantages or disadvantages, almost every code base will have references to third-party dependencies or open-source libraries. The why is up to you. But be wary that vulnerabilities in those dependencies will likely be a vulnerability in your product.

Late 2021’s Log4Shell vulnerability was a big one that highlighted the importance of third-party dependencies and how prevalent some of them were across software globally. It seems like every year there’s a new dependency panic. You know it’s an increasing problem because the Open Web Application Security Project (OWASP) category for “Vulnerable and Outdated Components” moved up from 9 to 6 in their top 10 list.

Part of the problem is that sometimes we just don’t know what third-party dependencies we’re using. It’ll be a consistent theme in these posts, but it’s hard to protect against something you didn’t know existed. So what are we advocating here? Figure out what dependencies are used in your product, audit whether you actually need them in the first place, and then use a scanner to help let you know when there’s a vulnerability.

Basics to get started? Find an open-source third-party dependency scanning tool that’s suitable to the language and framework you’re coding in. OWASP has its own tool called Dependency-check. Popular source code repositories like GitHub and GitLab also have their own built-in dependency scanners. The extra benefit is that most of these will also help inventory what dependencies are in use. You may need to do this a few times depending on how many languages and frameworks are in use. Analyze the results to plan out any updates. You’ll want to put the updates through the same testing as any other code change to make sure it hasn’t broken the application.

What’s next? Similar to the secrets and secure coding sections, use automation to scan the code when commits and pull requests happen. Commercial tools that scan for third-party dependencies will have a centralized dashboard for all your projects to make it easier to track.

What does Kinde do? The team makes an effort to use as few dependencies as possible. We use SonaType’s nancy and NPM audit to scan for, inventory, and notify us of any vulnerable dependencies. And when new dependencies are being discussed, we use the Snyk Advisor to see how healthy the project is before deciding to use it. When the code gets pushed up the pipeline, AWS Inspector will perform a scan of the container image and report out to its dashboard.

Including publicly available strategies and information gleaned from previous web attacks will help you write defensive code that is less susceptible to attacks and vulnerabilities. How secure your product is will heavily lean on the code that holds it up. Don’t get sucked down the rabbit hole of static application security testing (SAST) tools too early without first understanding what kind of attacks you’re protecting against. SAST tools are great for finding insecure patterns that are common to certain exploits like SQL injections but are not good for finding application logic flaws like authentication and access control problems. The Open Web Application Security Project (OWASP) has a great quote:

We advocate approaching application security as a people, process, and technology problem because the most effective approaches to application security require improvements in these areas.

Have a quick browse of the OWASP Top 10 to get an idea of the kind of attack patterns in use with high-level advice on how to protect against them and some examples. If you’re into going down a detailed deep dive, Red Hat has a huge defensive coding guide.

Basics to get started? As mentioned earlier, read up on the OWASP Top 10. Also, refer to their Cheat Sheet Series that a ton of practical examples for specific situations and coding languages. This will help you and your team get into the mentality of secure coding and have the resources to get started.

Build a checklist of known insecure coding patterns that apply to your application. Coming across an XSS vulnerability in your application deserves a quick internal doc or post about how you found it, what you did to fix it, and anything you did to help prevent it from coming back in the future. This kind of internal knowledge is invaluable.

What’s next? Take a look at some of the free options for SAST tools from the OWASP website. Start with an open-source scanner that’s specific to the language you’re writing in. Start local and then work towards incorporating them into the pipeline for automated scanning whenever there’s a commit or pull request. SAST tools can be very chatty. Even if the results don’t have automated action, at least the record of the scan results is documented for further review in the future. A lot of the commercial tools will also include IDE plugins so that vulnerabilities can be brought up while the code is being written, which should greatly improve the speed of fixes.

If you’re curious about how to probe websites for vulnerabilities, check out the Portswigger’s Academy. Their tool, Burpsuite, is one of the most used application security testing tools out there and they have a whole library of learning modules with test labs to see if you can exploit their training websites.

What does Kinde do? A few of our senior engineers have been through lots of secure code training in their past lives and have been using that knowledge to improve our application. Anything related to security or that could impact the security of our application is discussed openly as a group to ensure the safest implementation. We’ve come across a few vulnerabilities internally while testing and are starting to document how they came about with suggestions for future prevention. We’re also running the gosec scanner to check our front-end code. Similar to the other topics in this post, we’re looking at automating the scans into our pipeline.