How Developers Can Use Automated App Security Testing To Protect Vue Apps

Hey, everybody. My name is Nick Teets, and I'm a front-end engineer at StackHawk. And today, I'm going to tell you how developers can use automated application security testing to protect their view apps.

A bit about me, I am a front-end engineer, so I must admit I do get emotional over fonts. I'm also the co-organizer of the Jamstack Denver meetup, where we talk about everything from headless CMS to static site generation. And when I'm not busy jamming or tearing up over Helvetica, I'm a musician here in Denver.

Today, I'm going to tell you what it means to shift left, I'm going to show you an example of a cross-site scripting vulnerability in a view app, and then I'm going to give you the tools that you need to find these types of vulnerabilities before you hit production.

So what does it mean to shift left? Simply put, we're moving the tools of the software development lifecycle earlier in the process. There's a bunch of different types of security tools that you can use now when you're checking into your develop branch or your feature branch that will help you find security vulnerabilities. Things like secret scanning, or the idea that we should be obfuscating API keys that we use to communicate with third-party services. Software composition analysis, which is taking a look at the open source modules that you use to run your app and find vulnerabilities there. We have static application security testing, which looks at the actual code and text files of your repository to find vulnerabilities. And lastly, dynamic application security testing. This is what StackHawk's really good at, is we take a running instance of your app, whether it's in the pipeline or in local development, and find vulnerabilities the same way that a bad actor may exploit your app.

So let's jump into our example of our Vue app with cross-site scripting. So here we have FontTalk. This is a place where users can log into a message board and talk about fonts. And of course, we're going to give them the ability to style the text that they post on this message board.

So Jane is going to start the conversation and say, y'all like fonts? We're going to wrap this in a bold tag to really emphasize that we're here to talk about fonts, of course. And we're going to post it. And you can see that we got the bold text in there. The message is available for everyone to see.

But then Jane's going to follow it up with another post. We're going to emphasize the beautiful here. But we're also going to include this image tag. We're going to hide this from the user. And when this image tag loads, we're going to post sensitive account information to a bucket that we've set up on a third-party service. So let's go ahead and save this note. And you may not notice something as a user that's not too savvy on the web, but if you inspect this bit, you can see that here's our image tag, which is hidden, that is hitting our third-party service with sensitive account information.

So let's go ahead and log out as Jane. And we're going to log in as Bob. And Bob gets here, and he sees, you know, there's some good conversation about fonts, and he says, yeah, fonts are cool. And then Bob's going to leave the chat, because you know, maybe they're not a message board person. But what he doesn't know is that that cross-site scripting has now hit his account. So if we go to this pipe dream, this bucket, this end point that we set up, we can see that that image tag sent Bob's confidential information over here, so our bad actor Jane can see it. So now she can log in and post as Bob, or maybe, you know, steal his credit card information, if that sort of system was implemented on our app. Which, obviously, that's no good. So what can we do in the code to stop this from happening?