Node Congress

Node Congress 2022

It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder

Feross Aboukhadijeh

React Summit

React Summit 2022

New Way of Envisioning Security in the Dependencies

Hi everyone. Good morning, good afternoon, good evening, wherever you are. Today, I'm going to be talking about new way of envisioning security issues and dependencies. I'm sure some of you know about it, some of you don't know about it. So today, I will be sharing my experience and my understanding about those issues. My name is Vandana Verma Sehgal and about myself, about my background, I'm currently a security relations leader at Snyk, which is a software security company. When I'm not working at Snyk, I generally contribute to open source projects and cybersecurity and part of certain conferences like Black Hat. So I'm currently the chair for OWASP, which is Open Web Application Security Project, a community driven to motivate people to understand application security. I also run InfoSec Girls, InfoSec Diversity and Kids so that we can have cybersecurity understanding for everyone. That's about myself. Now, while I talk about what security issues are, what exactly do you see in this picture? This is something which is more of a futuristic image of what we really want. We want everything to be automated. We want everything to be super cool. We want everything to be different and helpful for us. I want it. I want smart TVs, to smart devices, to smart users, everything smart at home. So I just need to play a button and everything is good. But there's one thing which is there. What happens when the data is being uploaded somewhere? And that's natural. We've heard and even we've seen the data is getting uploaded somewhere. Why do we say that? Because the point comes is anything that you speak to these smart devices, they're actually getting trained because you want everything at the earliest. So they're getting trained to deliver the content at the earliest. So data is being somewhere, stored somewhere. Now, I am sure these devices are being updated somewhere. So there'll be a patch which might be downloaded. Now, when that patch gets downloaded, there are times where you would feel that there's something fishy or even sometimes you even don't get to know that there are malicious things which are downloaded on your system. So what do you do? You download it. So what do you do? And what happens then? Could be that they might be tracking you. Anything and everything that you're speaking might be getting tracked. Is it cool? No, it is not. It is somewhat scary. But the point comes, how shall we actually deal with them? So developers play a very, very crucial role in cybersecurity incidents. And especially when we talk about these new supply chain issues which are there, the whole landscape which is being changed and the way we have started to care about software security. Now, this event stream incident, which doesn't seem to be new, but it dates back to many, many years, when somebody said, I want to help you out and hire the maintainers. But then instead, they added a crypto miner, and nobody even knew about it. So you're working and something is running in the background. So how much exactly do you know about what is in your system? Now, I'll tell you about myself. All my websites are on open source content. I'm using whatever is there on the internet. Now comes, are there any issues in those dependencies? Maybe. So this is an image that I have in mind, that this is all my app. But actual thing is that this is the only code, the red dot in the middle, which is the code which is developed by me, or maybe my friends, maybe the company itself. But what is rest? The whole rest is the open source code, third party dependencies, third party libraries and whatnot. How exactly are you going to be taking care of that? And what happens when attacking, people start attacking developer tooling? Now, being in security, I might not use Visual Studio Code or any IDE very often. But can it happen? If I'm a developer, I wouldn't be using day in and day out. I would be using, and even for that matter, being in security, I want to learn about a lot of new things. So I learn these things. So that's what happened in January, 2021. Somebody actually tried to attack Visual Studio Code, where they were able to get access to the GitHub of many accounts. But they diligently reported that it could have gone in any wrong direction. And when somebody gets the house key, they can do anything. For example, you've got four doors in the house, then there are four windows. Now you're going on vacation, you've closed all the doors, but what happened to the windows? Maybe there's one window which is open, which you did not realize and somebody gets into your house and takes all the stuff. It's crazy, right? And that can happen with anyone. And that's when we need to understand what's inside our code. Now, there are certain lessons that we learned from the Equifax breach that happened a few years back. Now, why we are still talking about it, because it actually envisions one very important aspect, that when there's a certain vulnerability, which gets reported, after that, what we really need to do is we need to understand what that vulnerability is all about. Can we fix it or not? And if it's critical, how soon can we address it? What happened with the Equifax? Feb 14th, Apache notified that there are certain issues. There was a release, a fix. People started exploiting the exploit. And even though some companies already updated it, there are some companies which could not. One of them was Equifax. Now, it was a huge data breach, and especially concerning the libraries. What it tells us is that we need to detect these issues as early as possible. We need to respond to them. And when we respond to them, we need to do it with the whole organization, within the whole organization. Trust me, it took us a good two, three days to understand where we are, where do we stand. Everyone was getting crazy. Do we have this version? Do we use Apache on this application? And a lot of time, what happens? You don't even know that you are using Apache or maybe this any third party version, which is vulnerable in your ecosystem. Why? Because we sometimes tend to miss in updating CMDBs. Now, when we say that, the most important aspect comes is that, are we able to maintain it regularly? Maybe, maybe not. So what shall we do with that? We need to make sure that we understand these issues. And on top of it, these supply chain risks, are they new? I don't think so. They're new, because they have been there for a very, very long time. And it started getting into the limelight after the solar winds attack, where there was a third party library, which was added as part of the package, which the package was shipped to everyone, and everyone was using it. Now, this is a big concern, which means there's one library, one dependency, which is there as part of your code, that can lead to big issues. And on top of it, the point comes, how are we trying to address that? We're still seeing these issues every year and year. Companies, organizations are spending more and more money on these. Now, let me tell you something very interesting. There are times when maintainers themselves remove the libraries. These are some of the cases wherein somebody removed the package and the whole packet started breaking, and everybody got crazy. Now, this also tells us one important thing, when we're using third party dependencies to open source content, it's important we track it, and we understand if something happens to them, how are we going to deal with that? And let's not go back this very, very long, which is 2016. Just two months back, or three months back, there was an issue with Collar and Faker. These are two major libraries as part of the Node.js ecosystem. The maintainer was the same for both. Now, this maintainer removed the whole package from one of the libraries for one of the ecosystem, and for the other dependency, the person added a loop condition. Now, what do you do in that case, wherein I have a package because I wanted a new update, now that has a loop condition and it's breaking my whole code? Isn't that scary? And that brings us that even these issues can come in any form, in any part, as part of the registries. So what do these registries contain? Could be malicious issues, could be vulnerabilities, could be whatnot. And these issues are not only just for the ecosystems, which are smaller, but they're impacting enterprises as well, medium business units, and everyone. This brings us to the point wherein this lock for shape. I'll tell you my own story. In December, I was on vacation. In the first week, I was like, oh, I've not taken vacation for a very long time. We've been at home, so let's take a vacation. So we went to travel. Now, during the similar time, lock for shell happened. What is that? I didn't even know. But then I started seeing messages and everyone started talking about it. So I wanted to understand what it is. So lock for shell is basically a very popular logging platform, Apache-based logging platform written in Java. And people use these platforms very easily because they're easy to use. But what happens when it impacts huge amount of organizations, from CESA to Amazon to IBM to any company, even SNEAK, we were talking about it. Now, when that happens, how do you deal with that? And what was the part of, what was the issue in there? So anyone who was using a lab server and was using JNDI, J-N-D-I, they were vulnerable because it was a very highly or very useful framework a lot of organizations were using. And they were trying to figure out whether they were vulnerable or not. Now, organizations, to people, everyone was talking about it, sharing their views on social media, Twitter, LinkedIn, on their own blogs. And this whole attack made us realize that if this small, small issue, which is there in the code, it can be a big concern. Even if one library, there were people, there were organizations who were actually not vulnerable, but they were using third-party components, which were making them vulnerable. Would you like that? I wouldn't like that. So I would like to know what I have and what I don't have. What I have, what is the list of it, whether I'm using third-party vendors or not, which is very, very important. Also, I'll tell you something interesting about OWASP. So OWASP top 10 releases, top 10 list of risks every three years. So it came up with the top 10 risks and injection, which is supposed to be on 10, dropped down to third. And suddenly I saw these injection issues and they're becoming more and more prevalent. This is Lock4Shell, then many other vulnerabilities came. And it just doesn't stop there. Why? Because it was actually the indication that there are regulatory compliance failures. We're talking about cloud. So there are cloud security control failures, which are there, sometimes intentional. Sometimes we don't even get to know. And these third-party SaaS application security failures, because we are too much dependent on them, which also leads us that if something happens, anyone can deploy malware and ransomwares, which can lead to data exfiltration, to integrity issues, to availability issues and whatnot. I wouldn't want that. Now, let me actually show you something very interesting. So here I have actually created a demo. Now, what it says, I have it on my local system. I've not installed this vulnerable version of Java on my system, but it is in a system. It is in a different folder. Now, what I have is I've created a Java group where I have this exploit. In the exploit, for you to see, I need to have a server running. If there's no vulnerable server, how would you get attacked? How would you get a vulnerable? So I have a Lock4Shell server running. Now, this server is running on localhost, which is HTTP server port 8000. And there's an LDAP server, vulnerable Jindy server, which is running on port 9999. Now, this whole thing is running. Now, I need a client so that I can make it vulnerable. So here is the client. And simply, what I'll do is I will try and connect it with the server. So let me execute this in Java. Now, when I connect from client to server, there is a file which does not exist, temporary pawn. But when I ran it and I connected it to the server, it actually downloaded a malicious file and made it vulnerable, which is, let's see if this file exists or not. So let's see. So if you see this file exist, now you must be thinking, how can that happen? So let me do this. Let me remove this file completely. So let's see if this file exists or not now. Oh, sorry. Let me go ahead. If you see, oh, I need to remove first. Now, I'm going to go ahead and show you if it exists or not. So it does not exist. Now, the file does not exist. Now, let me connect it to the vulnerable server. Here, I'm going to execute Java. And it is going to connect to the server. Now, while it's running, it's trying to connect to that GD server. And this file now exists here, which it says that it's just a small file that I have downloaded in a temporary folder. If I am a malicious person, I know that this server is vulnerable. For example, right now, we're talking about React.js Summit. I'm sure they must have a website. Now, when there's a website, and it's vulnerable, I know it's vulnerable. What I'm going to do is, I'm going to connect to it and upload certain files. So anyone who connects to that server gets downloaded these malicious files. It could be a ransomware. Oh, nothing should happen. Because people are more aware, especially the development teams are becoming more and more aware about security issues, at least more than us. What I can see. I have a lot of friends working in development teams, and they are like, pro security people, because they understand security better than me, because they know the ecosystem well, day in and day out. Now, the simple issues. It took me a few seconds to exploit it. What happens when a hacker tries and expilses the data, which is very, very confidential, and nobody should know about it. That can be scary for an organization. Now, what it takes us that even though these popular frameworks are there, there are certain issues which need to understand. We need to have a list of all of these issues. And more on top of it, we should know what we have in our house. So we tried and hacked that. Generally, I do it after this, but I did it early to set the context. And on top of it, what we used to see that this is the life of a security analyst. On Thursday night, Friday night, you would have these issues. Well, let me tell you, this is not the case anymore. When the zero rate drops, it impacts everyone from a security analyst to anyone and everyone. And that also tells us that the security issues are real. There are many, many issues which are there as part of the ReactJS ecosystem, which people are trying to fix. So what I would really request everyone, if you see any issues in any of the dependencies, please report. If you are a maintainer and you need help from people, please do ask for help. There are so many people who want to help, but they don't know how to help. There are issues which are going to be there to stay. And when we talk about open source, open source is here to stay, but let's use responsibly. One important aspect, as for one of the research, 70 to 80% and even more code on the internet is all open source. The rest is being developed by us. When that much of a code is open source, it becomes our responsibility to make sure that we address if there are any issues. When my website is all built on open source, can I say that everything is fine with it? Maybe not, if I've not updated it. When I start using it, it doesn't mean that everything is perfect. I have to update it. I have to update it. I have to update it. I have to update it. Everything is perfect. I have to make sure that I work towards making it perfect. And on top of it, while dealing with these new vulnerabilities, we need to think in a broader way, mapping each and everything. And you can start any day. If you talk about open source, OWASP Dependency Check is a free tool, open source tool. You can leverage, you can scan your code and understand what you have in the code itself. There are so many wonderful open source tools which are there to help you out. And when you are comfortable with these tools, you can go for a commercial tool based on your need and what you really want in an organization. I have friends who bought the tools, but they don't use it because that's of no use for them. Because everyone was using it, they have bought it. Now, important aspect comes is that let's start getting those things which are really needed. On top of it, let's have security champions and teams so that we understand security well, we advocate about security. And let's not just stop there, but let's train people, let's cross train people, which is going to help us avoid these issues. And I am sure we'll all work towards that. And it's going to be a better and secure place to live in. Thank you so much for listening to me. It was wonderful to be part of Reactors. Thank you.


Vandana Verma Sehgal

Automated Application Security Testing 

What's going on React people? I'm Scott Gerlach, co-founder and chief security officer over here at StackHawk. I hope you're really enjoying React Summit. Let's talk about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, server-side application and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding and fixing security bugs easy. How does StackHawk work, you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host, in CICD workflows and against applications that have yet to be published on the internet. We also made dynamic testing fast. By placing the scanner as close to the application as possible and by using open standards to inform the scanner, open API spec, GraphQL, introspection queries, SOAP, WSDL, in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose. Based on severity of untriaged findings, most of the major CI player logos are shown here on this slide. And even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. You can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog, or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner looks like. As you can see here, I've got a standard server side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the web page that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan, so we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got this SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails, so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application, and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen, to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira Cloud or Jira Data Center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next epoch. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk can be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. And StackHawk is always free to use on a single application. Hey, thanks for watching everybody. I hope you really enjoy React Summit. Come see us.


Scott Gerlach

JS Nation

JSNation 2022

Finding Stealthy Bots in Javascript Hide and Seek

Hey everyone, I'm Adam. I'm super happy to be here and I'm here to ask what's going on with bots on the web. I'm not talking about the nice ones, the testing. I'm talking about the bad ones. So we'll talk about simple detections, how the bots got better. We'll talk about what's possibly the best bot out there cheating on most detection solutions. And we'll lastly get to my favorite part, which is how you can find it anyways. But before all that, one reason I'm here is because I always like packing stuff and now I'm the reverse engineer for DoubleVerify. They measure ads. Part of my job being playing hide and seek with these bots so advertisers can avoid them. It's not just advertisers in the games, it's going to be social media, concert ticket sellers, a lot of people facing this issue because the internet was not designed with bot detection in mind. Seriously, the only real standard is bots.txt telling bots what they're allowed and disallowed to do. Basically the honor system asking people to play nice. When you do that, yeah, real story, when I was 16 High School Prodder Project may or may have not dropped service to some sites. But some people actually do this on purpose and at scale, denying service to real users, using what they have to steal, sneakers, sneaking around social media with fake users, I practice that part. So to make the internet better, we want to detect them. Let's talk detections. Starting with the basics, not because bot makers can't play around these, but because they're usually the first thing you rely on when you come up with something more complicated because simple detections are pretty straightforward. User agent. Does the HTTP request headers identify the browser? You guys know this. You see it's a Python bot. You block that. Probably not a real user behind that. They figured this out, the bot makers, now they hide the user agent. Let's say you don't run JavaScript on your bot. Maybe you make a token as the detection, as the site. In Azure, you make sure it's created. So if you have a bot that's navigating to your site, non-generating this token, not running JavaScript, you know something's going wrong. But let's say they do run JavaScript. All of a sudden, you can check how the browser behaves. You people probably hate browser quirks. Bot makers hate them too because they can be used to verify what's under the hood and not what the browser's reporting at face value. And sometimes you can dig deep in JavaScript to see if somebody's trying to hide something. User agent. We talked about that. That property on the window navigator is going to be read-only. So bot markets, they're going to hide that with object.defineProperty. You look at the property descriptor, you see somebody did some funny stuff there trying to hide a user agent, that's going to be suspicious image here being how you have a bad attribute identifying you. You fix it into something perfectly fine as the bot maker accidentally leave behind an artifact that can be used to incriminate you. That's going to be used for detection. This is going to be a common theme, the cat and mouse of bot detections. Another example is the bot maker can override the toString, something they're trying to hide. So you look at the toString, the toString, they hide that too. There's a fun game established there. Several ways around this key takeaway being here, this cat and mouse theme that's going to repeat back to some more detections. Let's say you're really good at this DOM stuff. You make JavaScript library like creep.js to fingerprint the browser under the hood. That only goes so far because the bot makers, they can see what you're doing. Every time you find them some way, they're going to evolve, they're going to patch a little bit, and now we got to use something else. Let's say you're on a site, you want to use data. Data is going to be tricky because you have to mine privacy issues around real users that you're testing. But let's say you have a site that users, they go to just for the sake of argument. Each page, you put a generated token, you can validate as the user go through, you can see where that user went. All of a sudden, you have a whole new arena for catching these bots, duplicate tokens, nonsense navigations, anything that's giving you even the tiniest hint that somebody maybe just have pre-programmed your logic in some way and it's not an actual user navigating. Some of you might be thinking, hey, real users do this too, and that's absolutely right with caches and stuff. That's the way this isn't a smoking gun on its own, but caches, for example, that also introduces a whole other avenue for bot detection. Some bots, they clean the cache too much. We'll get into advanced bot and detection in just a moment, but still in the domain of old school simple detections, behavior tests. How many times should the user click in your site, let's say in an hour? Okay, so there's going to be a little spectrum, how much each user does it, and you're going to look in the edges and one side you have zero, there's going to be my father clicking absolutely zero times after a long day at work, but on the other edge, you have people clicking 172 times per second. Okay, we're getting somewhere there. Also caches, that's what we came up with originally to distinguish humans from bots. You might be asking, hey, when you start with that, reason is that the bots trained, they absolutely demolish humans and simple ones. This offers for complex caches too, so caches aren't there to prevent bots. What they do currently, the reason you see them is that they slob the bots down. Moving forward, let's talk about how the bots got better. Getting closer to the advanced detection, that part, the bot makers haven't been sleeping on their gourd all this time. They got better, they keep getting better. With every little patch they evolve, eventually game became written in their favor. 10 years ago, they're struggling with Python scripts. In recent news, it's now publicly retweeted, so here's some guy complaining about this to Elon Musk. Ping me in the Q&A if you want to talk about the seekers and the hatters about this some more. I'm right about that one. Point being that the evolution thing is really good at gradual improvement and problem solving. Bot find eventually become indistinguishable from humans entirely, but moving from philosophy rambles to practice, biggest technical advances bot made in the last 10 years, that's going to be automated browsers. Automated browsers changed the game. No more requesting Python. You're taking the whole browser, you run the DOM and JavaScript. You can even fake the user. Automated browsers got really good at their thing. So you got bot makers fake attributes, like the user agent, without leaving the artifact behind that you'd normally do in JavaScript. That makes bots more flexible, harder to detect. Browser quirks and all that, not as useful when the browser automation solution is importing the browser with whatever quirks they have. You can fake the user too with these, using vanilla JavaScript or browser hooks, say scrolling through some articles with Windows scroll. So here's some automated browsers that are good for testing, but don't be like some of the bot operators I found out using these for fraud schemes, because they're not meant to hide anything. They're easy to detect. No, you want something better. We're getting to the kingpin here. You want something that's based on this guy, Puppeteer. That's Google's automated browser. It's not malicious at trying to hide, but it's really good at its thing and makes itself super easy to extend. Makes everything super smooth. And with that, all the pieces kind of came into place. We see bots getting weathered better, automated browsers available, and operators improving their game. Thus, the king bot was born. This guy. Puppeteer, as they're still best at hiding, so it can run headless, meaning no rendering in the screen. Still doesn't get detected. It's amazing, criminally easy to use, making really good botting really accessible. The community behind it is an army looking for even the slightest discrepancies. For example, they patch hardware concurrency. That's the amount of available processors you have. And so they can scale the operation to run many of these on the same computer without even raising the suspicion that they're a bot. Whole different playing field there. They left some traces when they patched this attribute on the prototype. People detected that on the screen. They found it. They patched it. They did this fast. Let's talk about something harder to fake. Canvas fingerprinting. That's when you dynamically render a canvas to fingerprint your device alongside the browser. Sorry. Should be harder to fake. Bam. These folks developed an extension that reports fake values using JavaScript hooks. So they solve pretty much anything. I want to take the time to explain just one of these before I fly through the others. You have Chromium here. When it's headless, it does not end the Chrome.csi, Chrome app, all that performance stuff. So you think, okay, I can detect Puppeteer when it's headless with this. All of a sudden, not so fast, buddy. They fill every single object with fake values like this. Navigator Chrome, load times, run time, up, so on and so forth. Anything that can be used for detection. It's making it stupid easy to use. Annoyingly elegant. Remember, CAPTCHA has two lines here, a little bit of money, and they solve that. And all of this is going to be just with these two lines here. Everything we talked about, super easy to use, bot tests failed to find it. They just hang the spot detection on their repo. But I promise that gets to what actually works. That part, I made it within ten minutes. All right. Obviously, I can't specify too much here. But let's start with the easy part. Easy bots are easy to detect. I'm going to name three ways to go after hard bots. This is going to be quick, but I'm going to say this more than what's out there. Starting with stuff like hardware concurrency, there's still more JavaScript engine artifacts to be found if you know where to look. These are becoming increasingly rare, though, so I wouldn't count on them long term. But the upside here is that they're very clear cut. What we'll hold at the time is behavior tests and session level data analysis. Behavior tests that still work usually look at window context discrepancies interacting with the DOM. And data analysis can take many shapes. For example, let's say you pick the user agent perfectly. The question is what value you put there. Look at this graph. That's the user agent along navigating to an app. Each point is how many people navigated with that specific user agent. You'd say there's some variance here. But this is what it's supposed to look like. Blue line's almost flat, so that's probably because the bot foster got right how the user agents vary. They got the wait part entirely wrong. They're probably just producing these at random. Normal sites don't do this. And here's one way you can detect even the best bots. So at the start I asked you, what's up with bots on the web? I can't tell you for sure, but what I do know is that they're getting better. We need more smart people like you to be aware so that the internet becomes a better place. Thank you and feel free to reach out.


Adam Abramov

How React Applications Get Hacked in the Real-World

Well, how would you like to hack a real-world live React application? So let's get started and see how we do that in seven minutes. I'll try to give you as much tips and best practice as I can and show you where the pitfalls when you write React code. So my name is Irantel. I'm a developer advocate at Snyk, where we help developers build secure software. I've got a bunch of stuff around OS and Node.js and security research that I'm doing on my own. If you have any questions or want to help me do some of that as well, just reach out afterwards. And happy to chat with you, and we'll do some stuff together. So how do you do React vulnerabilities live? So essentially, think about XSS. And I'll go through this really quickly. Why am I talking about XSS and cross-site scripting when we have React and modern front-end frameworks? So consider this code example, which has first name with some XSS image. And first name is user input, right? It flows into your JSX like that, and React outputs something like this. So far, so good. Basic stuff. It works. Actually, React outputs this and not the other thing that you saw before. These are called HTML entities, and it allows the browser to understand that these are left, a side triangle, right triangle, with the less than, greater than, and all of those kind of things. And so the browser understands that you want to print it as text and show you this. They're like basic stuff. But React is secure by default. Or secure by default, this is essentially what it means. It's doing output encoding. Well, what if I told you it sometimes does that? Not all the time. And that is where things get very hairy. So let's discover the first thing. Take one. I want to add a link to a React application. So imagine this is my application, and I'm building it on the right side. And there's a user story, right? Product managers put in a user story. You want to add Twitter links. Makes sense. I add a Twitter link. You can see the input. I essentially have my Twitter link coming in, maybe at like a JSON feedback from the back end or somewhere else. And I have my React code with a component. There's a button in it. href, I give it the Twitter link. So far, so good. Let's see. Well, essentially, if this flows into the Twitter link as is, that is a cross-site scripting vulnerability. So if you did that, and really the input of the user for the Twitter link was the following, you'd get an alert pop up. This is plain React code. I didn't do anything except show you the code of what actually happens. The thing is, React doesn't sanitize or output and code those href attributes. So let's try to fix it. Maybe we'll try to fix it and do something like, well, I'll detect all of those JavaScript and colon whatever is coming up there, index of. I'm detecting it's starting with s rather than being somewhere else on the URL. I'll go ahead and fix it with some dummy hashtag. So I do that. But then that doesn't work, because hackers are smart. So they try different ways to fuzzy test the application. So maybe I'm thinking, well, you know what? I'll try and fix it with a lowercase. So I'll transition everything to lowercase and then match them. So I do this. Very simple. Push it to production. I test it. It works. But then someone comes in, and they do something like this. OK, this is a control character. If someone pushes this in, it means, essentially, the end of the medium, the end of line. This is a way for someone to push it in. And so all of that thing just ends up not working. So links in React apps. Think about the fact that best practices here don't do denial list. Don't do trying to figure out how to remove it. Also, think about things like sanitizing user inputs where it should be, because React doesn't sanitize or correctly actually output and code everything that you push into it. There are some specific contexts, like HTML attributes, toElement, and all of those things. So that said, let's see another way of doing it. Discovering other people's XSS vulnerabilities. How do you pretty print a JSON to look something like this? Because I don't want to write the whole logic around printing it, indentation, et cetera. So I do an npm install for a package that does this for me. Makes sense. This one has like 50k downloads a week, so I feel pretty well to install React JSON pretty. I do it. I import it. All of that makes sense. Then I use it like that. A very cool, easy, simple component. So far, so good. That's what you do all day. Is it XSS free? Well, think about what input can flow into the application. Maybe it flows in different ways. Like maybe your package manifest or the JSON you want to show there is actually not a JSON object. It's maybe a string. So here's the code for it. This is the code from the React JSON pretty component, the npm library. You can see it has some dangerously set inner HTML there. But it actually calls this pretty, which is a method inside that has something that actually tries to output encoding correctly. So it does essentially what React does. Well, if you look actually more into what's going on with stuff that it tries to catch and not do correctly, it actually has this area where it catches it but doesn't do output encoding correctly. So that's what we have. And they have tried to do some XSS to try and remove it. Maybe you tried it. Maybe it doesn't work. Maybe you use it in specific context. And you fall into the same problem. Because if you try to do that in XSS for an attribute, that's not going to work. You need to do context encoding aware. So with that said, I'm going to tell you if you want to learn more about all of those things, there's a bunch of stuff on the blog. You can just Google things like React Security Best Practices sneak or something like that. And do secure coding. So thank you so much. Have fun. Thank you.


Liran Tal

Security Controls in the JavaScript Supply Chain

Automated Application Security Testing

What's going on JS Nation? I'm Scott Gerlach, co-founder and chief security officer at StackHawk. I hope you're really enjoying JS Nation and making the most out of it. Let's talk about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, server-side application and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding and fixing security bugs easy. How does StackHawk work, you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host, in CICD workflows and against applications that have yet to be published on the internet. We also made dynamic testing fast. By placing the scanner as close to the application as possible and by using open standards to inform the scanner, OpenAPI spec, GraphQL, introspection queries, SOAP, WSDL, in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose. Based on severity of untriaged findings, most of the major CI player logos are shown here on this slide. And even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. You can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner looks like. As you can see here, I've got a standard server-side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the webpage that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL ejection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan, so we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got the SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL ejection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL ejection in Spring, Laravel, Django, and Rails, so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen, to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira Cloud or Jira Data Center ticket right now from this particular screen. So I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next epoch. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk can be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. And StackHawk is always free to use on a single application. Thanks for watching, everybody. I hope you're really enjoying JS Nation. Come see us at StackHawk.


Avoiding CSRF with Remix 

Hi, and welcome to my session on avoiding CSRF with Remix. This is a lightning talk, so we're going to go through this in a pretty whirlwind fashion. So let's start off by talking about what CSRF is. So like most security exploits, it's got an acronym, and it stands for Cross-Site Request Forgery. And in this scenario, basically the attacker tricks the user into accessing the URL, and then this URL will perform an action using their existing session. So a simple example, or perhaps the worst example, is an image with a URL and that URL performs an action. So before you say, no, I want to write code like this, I've seen this in apps that I've audited, and obviously the first thing the user is doing wrong here is they're using GET to perform some sort of action. But equally, this kind of exploit can be achieved even if it's using POST, and we do that by having an iframe with a hidden height and width, and that embeds a separate URL, and in that URL we have the form that POSTs to that endpoint, and we have an onload function that submits it the second the form is loaded. So let's talk about Remix a bit. Remix gets you thinking about actions in terms of the building blocks of the web, which is the HTML form element. And if you've been building apps with JavaScript, you've probably been using like Fetch or Axios, and in these scenarios, CoreOS protects you, unless of course you're using access, allow origin, star, and you're allowing credentials to come through, and in that case, you're in the same boat. So because we're submitting forms again via straight up multi-part form data, we need to think about cross-site request forgery. So let's have a look at a simple Remix form example. We've got a primitive form here with a text field and a submit button. We've got some sort of loader to check the user has got authenticated session, because cross-site request forgery does require the user to be logged in. You know, you're performing an action using their existing session that they didn't intend to do. And so we're not going to get the details here, but yeah, the loader is making sure the user's got a session. We've then got an action in our component that does some sort of write to the database or similar, something that could perform some sort of action that can't be reversed. So how do you avoid cross-site request forgery with Remix in this scenario? Well, the first thing you should do is set the same site attribute on your cookies. So you can set that to lax, which will mean the browser will only send the cookies if it's a GET request coming from another domain, or you can set it to strict, which means it won't send any cookies for any requests that originate from another domain. So you might need to check whether you're using some sort of authentication flow that redirects to other sites as to which is the most appropriate for your site. But unfortunately, according to OWASP, this isn't enough and we shouldn't replace having a token. And the main reason for that is that only 93% of browsers support the same site attribute at this stage. We're almost there. Your app might have higher depending on your user's browser mix. So the token-based approach is commonly called synchronize a token pattern, and it's basically a four-step process. The first thing is you have to generate a unique token per session, per form. You have to transmit that with the form. You have to send it back when the user submits the form, and then you have to securely validate it on the server side. So we start by generating some secure random keys. We generate a hash salt, and this is something that you shouldn't store in your database. It should be on disk or an environment variable so that if your database is compromised, even then the hash salt's not leaked. You should also have a private key. And both of these you can generate using the random bytes package from the crypto. So the first step is to generate a unique random seed per session. And so we do this by checking if the seed already exists in the session. If it does, we use that. If it doesn't, we generate a new seed using, again, the random bytes function, and we store that in the session. Then we need to generate a unique token per session and identifier, and in this scenario, the identifier would be something unique for that form or operation. And this prevents the same token being valid for two different operations and prevents token reuse. So to do this, we will take that hash salt, we'll take our private key, we also take the CRS seed, we combine the three together and we create a HMAC, digest that, which is basically a hash, gives us a nice unique token. We have to transmit that token with the loader. So the first thing we do is we generate the token and we return it in our loader data. And that means we can then get that back in our form by using the route data. So we get our CRS SRF token from there, and we transmit that in the form in a hidden field. We then need to validate the code. So if we write a nice little utility function for validating the CRSF token, it will regenerate the token based on the unique identifier and session, and then it will compare the two using timing safe equals against the version that was submitted with the form. And we use timing safe equals here to avoid timing attacks. So how do we use this utility function? In our action, we can just call validate CRSF token using the value from the submitted form. And if the two don't match, then we throw an error. So that's a whirlwind tour of CRS SRF validation for Remix. If you've got any questions, please contact me via the GitHub Discord server for this conference or you can message me on Twitter. Thank you.


Lee Rowlands

DevOps.js

DevOps.js Conf 2022

What's up DevOpsJS people? Scott Kerlock, CSO and co-founder here at StackHawk. I hope you're having a great time learning a ton here at DevOpsJS. Let's talk about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, server-side application and single-page applications. StackHawk was built for automation and CICD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding and fixing security bugs easy. How does StackHawk work you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host, in CICD workflows and against applications that have yet to be published on the internet. We also made dynamic testing fast by placing the scanner as close to the application as possible and by using open standards to inform the scanner, open API spec, GraphQL, introspection queries, SOAP WSDL. In addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack, and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CICD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose. Based on severity of untriaged findings, most of the major CI player logos are shown here on this slide. And even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. You can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog, or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner looks like. As you can see here, I've got a standard server-side application. This one is a polls app that I want to test for security issues. So over here on my command line, I've got a simple Docker command that I ran. So Docker run StackHawk. I fed it the StackHawk YAML. We'll look at that in a second. As you can see, it did a standard crawl looking for all the interesting things on the webpage that it could, and then it did an attack. So it actively attacked this application for potential security issues. When it was all done, we've got a summary of these findings. So I've actually got a SQL injection issue that I need to take care of. You can see that it's new. I also have a cross-site scripting issue that I've done something with before. I actually made a ticket out of this. So now it's in an assigned status. We've got a bunch of other things that we can look at as well, but let's take a look at those too. Down here at the bottom, we actually have a link to this scan. So we can actually take this link and paste it into a browser. By the way, output in a CICD system would look very much like this because this is the standard output. So if you did choose to break a build, you would have this same link in CICD output. So we can go over here to our web browser and jump right into the scan that we're looking at. We were just looking at this exact same scan. We've got this SQL injection issue that we can look at quickly. You can see that we've got a SQL injection issue. We're quickly describing what SQL injection is, how to remediate it, what it's about, and what risks it might pose to an application. We also have links to different language frameworks that show you the pattern of how to prevent SQL injection in Spring, Laravel, Django, and Rails so that you can help identify the anti-pattern that we're looking for. Let's take a look at this particular issue here. So we can see that on the polls SQL path, we have a post method that has some kind of an issue. Over on our right-hand panel, we've got a request and response of what the scanner actually did and then came back with. So we can see that the scanner made a request here against the application and it responded in some form or fashion. We can actually see that the scanner made a case when injection here. So we could replay this if we wanted to. This is all helping you understand what the scanner is trying to do and what issue it thinks it's found. But interestingly, we've got this really cool validate button up here. As I mentioned before, this validate button gives you a curl command of exactly what the scanner did to identify this particular issue. So you can copy and replay this attack against an application. Let's take a look at that StackHawk YAML. Here you can see the code that I've used to build my polls application. Inside of this repository, I've also stored the StackHawk YAML. The StackHawk YAML is how you configure the StackHawk scanner. So you can see the important information that's in here is where do I find the application I need to test? In this case, it's running on my local machine, so localhost 8020. What environment am I in? What is the application ID? That is the minimal amount of information you need to run a StackHawk scan against your application. There are other pieces of information that help tune the scanner to your application, such as authentication, how to handle cookies and CSRF tokens, as well as things you don't want the scanner to scan. If you wanted to add OpenAPI spec or GraphQL, minimal additional configuration is needed to make that happen, to point the scanner at those industry standard definitions of REST API and GraphQL. Now let's say we don't have time to fix this particular issue. We need to get this feature out for our customer, but we do want to fix it. So we can push this quickly to a Jira ticket. So I can send this to a Jira Cloud or Jira Data Center ticket right now from this particular screen. I can push this issue straight out to Jira, and now I can prioritize that and bring it back out of the backlog when I'm ready to do it in the next sprint or in the next epoch. As you will see, this has now turned into a triaged status issue. So when we come back here to our summary of findings, you can see that our cross-site scripting has been triaged and our SQL injections have been triaged. The next time the scanner finds these things, it will remember that you have triaged them already and it will stop trying to bring your attention to it. If you've configured builds to break, this will undo the build break mechanism and your build will continue as normal. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk could be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. And StackHawk is always free to use on a single application. That's my time. Thanks for watching. I hope you have a great time at DevOpsJS. Don't forget to tell someone, thank you for the things that you learned today.


GraphQL Galaxy

GraphQL Galaxy 2021

How to Make GraphQL Security Easier with StackHawk

What's up GraphQL Galaxy? It's your boy Scott Gerlach, CSO and co-founder of StackHawk. That seemed weird. I shouldn't have done that. I'm too old for that. Thanks for taking time to check out StackHawk. I hope you're having a great conference at GraphQL Galaxy learning a ton. Today I wanted to talk to you a little bit about StackHawk. Quickly, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications and API endpoints for security bugs and keep them from becoming vulnerable. You can use StackHawk to run active security tests on your running REST API, GraphQL API, SOAP API, Riverside application and single page applications. StackHawk was built for automation and CI CD to be part of your robust testing strategy for your application development lifecycle. It also makes finding, understanding and fixing security bugs easy. How does StackHawk work you ask? Great question. StackHawk runs active security tests against your running applications to ensure that your application is handling user input and output in a safe manner, as well as implementing OWASP top 10 best practices for application security. We can do this against your running application on your local host in CI CD workflows and against applications that have yet to be published on the internet. We also made dynamic testing fast by placing the scanner as close to the application as possible and by using open standards to inform the scanner, open API spec, GraphQL, introspection queries, SOAP, WSDL, in addition to the scanner tuning we've made, most StackHawk customer applications scan average around or under 10 minutes. Finding and fixing security issues is simple with StackHawk. Our focus as a company is to help developers find and most importantly fix security issues. The StackHawk scanner and platform are built around this simplicity model. The scanner is configured via YAML that lives with the code for the application that you're testing. When StackHawk findings are triaged, the platform is trying to give you the simplest version of the information needed to help you quickly understand what the problem is with simple descriptions and examples of patterns to help you identify the anti-pattern, be able to recreate the issue with tools like simple curl command to replay the attack and get you into debug mode, stepping through code as fast as possible to help you fix issues and get back to your regular job of creating value for your customers. All of this is CI CD enabled. Again, you can integrate this into your CI process and importantly, get feedback into the CI process on scan findings. This information can be used to break a build if you choose based on severity of untriaged findings. Most of the major CI player logos are shown here on this slide and even if your particular one isn't, chances are pretty good StackHawk will work in your platform as long as it can run a Docker container. If you can run Docker, you can run StackHawk. You can also see here StackHawk integrates with your workflow and information tools. We can notify you of your scan results in a Slack channel, publish that information to Datadog or send you a simple webhook message that you can then use to process and do with the data what you choose. Let's take a look at what running the StackHawk scanner against a GraphQL application looks like. So you can see I've got my simple GraphQL application. It's the basics of a service that would run a blog and we're testing it today with StackHawk. So you can see it has some posts and some post ideas and content and we want to be able to test that with StackHawk scanner to see if it has any security vulnerabilities. So we're going to do that with a simple Docker run command. You can see that I just kicked off the scan right before we started talking today and I've got a simple Docker runs scan here that is Docker run StackHawk, Hawk scan, and I'm feeding it a StackHawk.yaml file. We're going to look at that yaml file in just a second. What you can see here is that it says we've turned on our GraphQL engine and we've got the information for what this host is. So you can see that the host is running on my local host on port 3000. And then you can also see the scanner found 11 different GraphQL routes in the application. Now this is important because it actually knows this from the GraphQL introspection endpoint. It's not guessing what's available in this GraphQL application. It's well documented in the introspection endpoint and the scanner is using that to test against it. I just ran a scan right before this. So let's jump over to the platform and see what kind of output we have. So here you can see our scan that's already running, but the one I ran right before this is right here. So you can see I've got a couple of different issues. There's some interesting stuff in here that we can look at. What kind of tests ran against this application? What kind of findings do we have? Let's dig into one of these issues, shall we? So I've got two high issues, high criticality issues, and there are a SQL injection and a remote OS command injection. Let's dig into that remote OS command injection really quickly. By clicking on that finding it takes us to a simple description of what remote OS command injection is, as well as how an attacker might leverage that remote OS command injection and ways to remediate this problem. So you can see actually we have on our mutation here, our super secret private mutation, we have some kind of a problem. So over here on the request response side of the panel, you can see that during a mutation with this variable, we have now caused some kind of an output that looks like the output of an Etsy PASWD file to me. So we're quickly kind of getting into the context of what is this problem? How can I recreate it so I can go fix it? There's a couple of things that are really handy here. One, we've formatted all of these GraphQL requests in a GraphQL type of a fashion. So you can see that the operation and the variables make a lot of sense relative to GraphQL. The other thing that we've done is create this validate button up at the top. So if you wanted to, you could just copy and paste this curl request and replay this against the app. But the thing that I really like about GraphQL is because this is so well formatted and I've already got GraphiQL up, as we looked at before, I can kind of copy and paste our request out, paste that back into our app, and then I can copy our variables out and paste that into the app as well. So now I can replay exactly what the scanner did in my app, in GraphiQL, without too much hassle. So I can see what happened here was the scanner tried to do a cat of slash Etsy slash PASWD, which on Linux boxes is where all the user information is stored, not the passwords, the users. And what came out of that was actually the content of that file. So that's bad. We want to be able to get into the application, start debugging and fixing how that actually works. This is really good at setting you up for success on how do I get back into my app, debug, fix this problem, and get on with the business of creating value for my customers as a developer. I hope you enjoyed my talk today and perhaps learned something new about how StackHawk can be integrated into your development workflow. If you'd like to check out StackHawk and see how you can integrate it into your development process to keep pushing the limits on software development quality, you can always start a free trial at stackhawk.com. StackHawk is free to use on a single application. Thanks for watching and joining me with the StackHawk demo. I hope you continue to enjoy GraphQL and Galaxy. I'll talk to you next time.


React Advanced

React Advanced Conference 2021

Let Me Show You How React Applications Get Hacked in the Real-World

Hello and welcome to my talk. You thought your React application is secure? Think again. My name is Zerontal and I want to show you today a few gaps that you should know about when you do React coding. So why are we here today? I know what you're thinking right now. This is the year 2021. Is this going to be another talk about XSS? What do you want from my life right now with XSS and React? Because I thought we got over it by now. Well, that's where I'm going to say hello XSS, my old friend. And I'm going to show you a couple of examples that I was just running over Twitter just to find some coding examples of people showcasing some of their code stuff on React. And what are they actually doing there? So here's one example. This is XSS. This is this year. What's going on? Let's see. It looks like someone is trying to build a counter, but something's messy over there. Are you seeing what I'm seeing? Because when I zoom in a bit inside, I see the whole fancy use effect kind of stuff. Is it fancy still? I don't know, it's already a few versions into React. But anyway, you can see that there's a count variable that's coming maybe from the outside. We are putting it in. We have no idea what's in it. Is it sanitized? Is it not? Should we output and code it? What does it even mean to output and code things? We'll learn about it in a second. But as you're seeing, there's a mix here of React APIs and the DOM APIs like innerHTML, which is not a really secure way of doing things. And this mix actually causes cross-site scripting attacks or vulnerabilities like in this application. Let's look at another example. I've also seen this case on Twitter, which is also this year, not so long ago. So this person was trying to avoid the runtime evaluation eval function by basically accepting user input as well and running it. Because when you're doing return A plus B and A is an IIFE or a function or whatever, it's going to get run. It's going to get evaluated. So that doesn't really solve the problem either. So we're having a lot of those different things that if we're not using the right APIs, we're not aware of what are the secure APIs or what are the insecure APIs. I'm not just talking about dangerously innerHTML things. I'm talking about other things as well. And you'll see it in a second. So introducing myself, my name is Iran Tal. I'm a developer advocate at Snyk, where we help developers build applications securely using open source. So if you're in your IDE writing some JS6 code, writing some Node.js code, Java, whatever that is, we'll help you find it. We'll augment your experience of doing that by telling you real time if you are actually having some vulnerabilities and insecure code writer. Well, this is really cool, but I'm doing some other things as well. GitHub star, activists on web security topics. So Node.js, probably send me active there as well. Doing all of those kinds of things. But really, if you just want to reach out and talk about any of this or something else on Twitter, Iran underscore Tal, and reach out and say hi. So let's get on with this. React is mostly secure by default, right? Like other frameworks like Vue and Angular, most of these get things right on the client side, right? As far as it goes to XSS and maybe some other things when some frameworks take a bit more bulky and take a step further as well. But why am I saying mostly secure, right? Like what is going on? Why is Iran on this stage right now saying mostly secure? What is left for me to protect? Because I thought using React actually protects me from all of this weird XSS stuff happening to my applications. So to realize that, we kind of need to explore something else. I'm saying React is mostly secure by default. But what does secure by default mean? We need to explore this a little bit. And you need to understand a little bit more of the jargon. And that's where I'm going to just level up and just say what XSS is. So everyone here can be on the same level playing field. So when you write this code and render it to the DOM, the user input here, like first name for example, what happens to it? In the general case where this is insecure user input, it could lead to potential vulnerabilities like XSS on the web page. But with React, you're kind of safe. Now why is that? And so let's see what happens when we actually put something in like a script alert thing or image source or whatever into this JSX code snippet. Well actually, if you look at the page, you get something like this, which looks like a script or whatever element I would have put there, but it's not. That is because if you look very carefully with your DevTools inspector thing into this specific component, specific element on the page, we'll actually see that all of those angle brackets, they're not real angle brackets. They're actually HTML entities that encode and tell the page that it needs to render the angle brackets to the left and to the right, but they're not real angle brackets. So that is why when you put that into the page as user input, nothing would happen. No script would actually get evaluated, no runtime JavaScript evaluation because this isn't actual real HTML element or something around it. And the browser knows this, and this is what I mean when I say React is mostly secure by default. React is mostly secure by default actually means that it knows to encode. So now we have this new jargon telling us what this actually is. This is secure by default if you actually do output encoding by default on any user input. So with that said, with this knowledge, let's move a little bit forward and figure out now if React is secure by default and it does secure output of user input, why are you saying this is mostly secure by default? What is still left for me to protect and where are really all the gaps? So let's dive now in into some live coding together and see what we can learn about some pitfalls. And so for that, I have this build application website where it's, you know, this Kate Levy was building her package profile for open source maintainers and things like that. So it's kind of like the, well, a webpage with packages on it. So let's dive into something like this and see how it looks like. Well, I need my ID. There we go. Let's make sure everything works. It does. And if it does, I should have this one here. Okay, cool. So this is the website that I've just built and it looks like it's working pretty cool, has some elements in it like user input here, sorry, like the name, description or something, link to their Twitter, some more stuff that I can use like testimonials. So there's a lot of user input here that we can use as a baseline of just simulating what could actually go wrong. So let's take a look at this a little bit more. For example, this database has all of the things that I was talking about over here. And this is what we're actually going to use to simulate what could actually go wrong. So I'm going to go and change some of them, for example, just for the sake of things. So I can change this to my name here. And once I do it, you see it auto loads to Liranta over here. That's fine. But what happens if I change it to something like image source X on error alert one. And hopefully that triggers an XSS. It doesn't. This is where React actually helps you and secures things by default. Actually outputting codes. This is what we said with the example of the first name. This is why if you try those things and they didn't actually execute, that's fine. That's because that's fine database author name over here is simply something that React knows to now apply output encoding and change all of this into HTML entities. So so far so good. Let's bring this back to Kate Levy. And let's change something else. Let's try a link. Which is not just a bit of text. Let's try and change this to this is over here. So this is if I go, I just hover it, you can see the browser bottom left. This is going to her Twitter account. So I'm going to change this to let's try and be kind of malicious here. Let's say someone has this free form field and they just build up JavaScript alert, which is like, again, the classic way of maybe introducing some XSS. So if I do this, let the page reload, assuming it does is what you need to like go here and maybe click on it. And we see now an exercise with why, why is it going on? This is actually pretty weird. Like why do I have an XSS and alert if I'm actually using React? This is pretty newish version of React as well. Okay, this, you know, 17 and above. So what is going on here? Now to understand what is going on there, let's go back here. The Twitter link. So database of Twitter link actually gets inserted here. And so what we now understand is, well, React does not apply output encoding and protects you from HRF values, like HTML attributes that go here. And that is something that you should be aware of. So let's try to fix it. If first of all, now you are aware of it and you know that if something is malicious, we need to fix it. But let's see, there are some pitfalls in how we try to fix those things. So let's look at that as well. I'm going to go here and I mean, we can, we can live it at that. And just before around here a bit, we have enough room. And so let's go ahead and try out these whole user factors, just like change and sanitize it together. So let's try something like this is Twitter link. We put it over there. Okay, set Twitter link and use date. I'm going to kick it off with the database. Yes. Okay, cool. Yes, do that. Use effect, use effect and come on. Yes, autocomplete it. There we go. And then we want to find if, you know, not that one. GitHub co-pilot. That's insane, right? Twitter link that index of JavaScript. Like what do you think about this? Is this a good fix? Let's try it. I like this autocomplete. Go with that one. So basically this says if Twitter link over there on the database that we get as user input has JavaScript in it, it will actually set it to, I don't know, set it to something like this, right? Just a hash and that's it. Hopefully I didn't forget to close anything. Looks good. I think it looks good. Let's try it. Did it reload? No idea. Let's see. It didn't reload. Did reload. I'll reload. There we go. So no, we still have it. So this is not yet working. Oh, did I not save this one? Something here I didn't save. Let's try again. Oh, I'll tell you what we didn't do. So now we need to set the Twitter link instead of the database Twitter link, right? This is real life coding, real life debugging. There we go. I forgot to use the new variable. Okay. Now, is it loading it fast enough? There we go. Now it did load it fast enough and you can see that on the bottom left. Actually, I can click on it and just nothing happens because it adds just a hashtag there and that's it. So it looks like we fixed it. Did we fix it? What happens if someone gets a bit, you know, well, tricky and maybe they do something like that. They just, you know, do it as a uppercase kind of string. So now if I do it, did it reload? Wait for it to reload. There you go. So I reloaded it and now we have the XSS again. So the fix wasn't really that good for us. Let's try something else. Let's try, let's say that we, I mean, we want to catch it. So what do you think we should do like that? Should we like do a two lowercase and try it like this? Two lowercase. Would that work? Let's do it like this. And as you can see, this is basically the thought process of a developer and what would be great is if they had a tool that would help them on the IDE to basically follow the right APIs. I will, did it get loaded? Let me see. There we go. Now it did get loaded pretty fast, I think. And it looks like we fixed it. Did we? We knew it was coming, right? So we fixed the uppercase, we fixed the lowercase, but what else could go in, right? Like anything else, we can strip, trim, space characters and all those things. We can try all of those, but would it actually work? Would they not? We can try different way of escaping it maybe, but that's maybe a bit tricky. What we haven't tried is, what happens if we add things like control character, and that is something that I can actually add a control character over here and escape something like a slash R, slash N, something like that. And that would actually escape the whole two lowercase and index sub and everything will be just fine. Let me show you what I mean by that. If I just do slash, no, not here, over here, I just started off with slash X, nine, 10, which is a control character. If I try that one, the whole thing falls apart. Reload it again. There we go. So as we're learning, doing one thing and the other and the other, these are all trying to mitigate a problem, but there are still some issues, still some issues that we should figure out how to do it. So learning how to do things right is important. Now let me go into something else. Let's say that I actually want to, let's avoid this whole thing for a second, so I can try another example. I said I'd actually want, well, Libby actually wants to go ahead and do this whole package JSON view. And well, she's not going to go and, I mean, I'm not going to go and write a parser that I indent stuff and highlights. And this is, you could actually have themes and like pretty cool colors. So I'm not going to build all of this. I'm going to go outside and find something where I can give it a JSON file, like the package manifest for your NPM package. We'll go ahead and do this whole really cool highlight syntax thing, because I'm also not really a CSS person. So this whole thing is not for me. I'm going to go over to something like the Snyk Advisor and I'll look for some packages. Already found something that's called React JSON Pretty. It's unfortunately it looks like inactive. It's unmaintained or something, but it has something like 40K downloads, which is a lot. So, you know, maybe I'll try and use it. You could try and check if this is popular by version or not. So hopefully, I mean, hopefully everyone are on the latest version, which they are. So that's a good thing from security wise, if there's like, this was vulnerable, this was vulnerable, you knew what to upgrade to. It also looks like this is mostly used as a direct package, which makes sense as opposed like an indirect package. So I'll go ahead and use it. The most popular version indeed has no security fixes. Let's see what's going on. I'm going to go and use this. So I'm going to go into package profile. Where is it? It does package parser. I'm pretty sure. There we go. So I've imported this as package parser and I've provided it the package manifest, which is basically all of this JSON from the database file that I have here. Let's play around with this one here. So it's a simple component, just take some configuration and then things apply it by default. That's it. And I can go ahead and what I want to show you is like, let's try and do XSS from other places. Let's say that name is not now Gibson Explorer. Let's go back here. Right? Not Gibson Explorer anymore. That's going to be again, that thing that we saw. Well, let's do, I don't know, let's do, I mean, JavaScript alert will not work there. That's not a link. So I can try this vector instead. Click alert and see what happens. And changed it. But I mean, no alert. I don't even see an image tag, so that's okay. Let's try something else. What I would say is, I don't remember what was here, so I'll just do ABC. But let's say this, you know, if I were thinking how to exploit this, I would say, if this package was written by someone, maybe they didn't take a good care enough of sanitizing the data or output encoding it by going into all of the recursive elements that actually are in within the JSON. So all of the elements that are kind of living inside other fields and other fields. So what if I tried to put it here? Like maybe this is, this level on the JSON is sanitized, but this one is not, or output encoded would be the best way of doing this, but it looks like it is. So like that, that looks okay. So there we go. Getting back to normal. Now it looks like this is working and I've, you know, if this is a JSON input from an HT, from an NPM package that you get as well, that is not controlled by you. That is controlled by someone else, right? So what if that person gives you, you know, gives you a bad package JSON, right? Like I'm going to go and do something like this and say, Hey, my, like you're getting this package JSON. There you go. So package manifest. There you go. No, it's, it's not a JSON anymore. Now it's a string. It's a string, which I control because I can, I can define whatever I want in my package JSON and my just a tar file and I'll send it to you. Right? So if this is the input now, let's see what happens. Change the whole meaning of what the package JSON is. But the question is, is the application ready to handle something like that? Doesn't look like it because it looks like it tries to render it. You should probably have put an alert box somewhere there. On alert. On our alert. Probably should have worked. Oh, there we go. So now we see that what's happening, right? So now you're using a component and open source library that may have vulnerabilities in it, even though you were thinking it might be okay, you know, probably, you know, all that probably it's not, but no, you have to like test all of those things. So it's kind of like brings us into the world of, you know, managing components, learning about all of those things. So here are my takeaways. Let's go back to slides. Yeah, sorry though. So takeaways for us, right? This is, you know, avoid all of this, you know, dangerously inner HTML, obviously you do not want to do this. But the fact that you're avoiding it doesn't mean that others are avoiding it as well, like we've seen here. So you should really scan your third party dependencies. If you're doing something like NPM audit, you know, that's fine. It's a great way to, you know, get awareness for security vulnerabilities. But in my case, I found out when I was using React.JSON pre in my demo here is that he did not find it when I was doing NPM install, NPM audit, nothing was showing up for it. You know, luckily I was using a sneak test and I was able to find it. So, you know, be aware of what you're putting into this. If I have to summarize, right, be aware of what you're putting into your, I would say dependencies in general, libraries collection or your applications components, be aware of what you're putting there, be able to scan it all the time and fix it. And the other thing is, of course, be careful of what you put into those href HTML attributes because they are not getting output encoded by default. So thank you, you know, React, as I would say, React responsibly and securely. And if you want to reach out, I'm Lirontal. Thank you and have a nice time. Bye bye.


Vue.js Live Conference

Vue.js London Live 2021

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 Vue 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 Vue 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 finds 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 there's some good conversation about fonts. And he says, yeah, fonts are cool. And then Bob's going to leave the chat because 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. If we go to this pipe dream, this bucket, this endpoint 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 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? One thing that we could do is go to our notes list. And instead of using vHTML, which uses that inner HTML method on our element, we can go ahead and just render the information in this note, the actual value. And so if we check that out, we can see that we've exposed these HTML tags that people were putting into our message board. So here's that bad image tag that's sending that information. But this is kind of removing some of the features from our cool message board about fonts. So that's not the way to go. Let's use this sanitize HTML library that you could scan with SCA, of course, to remove some of that bad HTML while allowing our users to still style their posts. So if we inspect this element, we can see that that malicious image tag has been removed from our post. And so things seem to be working. Now there's one last thing that we could do kind of as a frontline against cross-site scripting attacks, and that's adding the CSP header. So if we go to our terminal, we're going to run a StackHawk scan. Now this would obviously be implemented in your CICD pipeline every time you check code in. So while we're running that scan, we'll go over to the StackHawk platform to see what a finished scan looks like. Here's our app that we've already registered. And if we click into this, we can see that there's a couple CSP header findings or vulnerabilities that we've discovered. And so when we click into this, we are given the ability to triage or mark as false positive or risk accepted for these different types of vulnerabilities. And we also provide a little bit of educational text about what the content security policy means. And so using a tool like StackHawk, you can see what some of these vulnerabilities are before you hit production because you're running this in a pipeline. And I'd love to tell you more about security and VLAPS and StackHawk, but we're running out of time. So we're just going to play the thank you slide. Learn more about StackHawk at stackhawk.com. The blog post that I got inspiration for this Vue example is available at this link below. And if you want to bug me on Twitter, I am nicktex on Twitter. You know, drop by, tell me you love the presentation. Let's talk about music or security or JavaScript. Thank you to Vue for having me. Thank you for watching. And this has been awesome. We'll see you later. Bye bye.


Nick Teets

React Finland

React Finland 2021

You thought your React application is secure? Think again

DevOps.js Conf 2021

You're 5 Minutes Away from Code Quality & Code Security

Hi, I'm Anne Campbell with SonarSource. I don't have any slides for you today. I'm going to try something that's a little bit risky given the time constraints, but this should work out okay. So what you're seeing right now is the front page of Sonar Cloud, which is a SaaS product, a SaaS product, to add code quality and code security to your repository. And I want to show you today how easy that is. So I'm going to start by logging in. Now, I already have an account, so you're going to see that reflected in my experience. But as a new user, all you would have to do is choose your ALM to sign in with, and it creates your account for you. So I'm going to start with GitHub because I have an account there. And it logs me in and shows me the projects that I have access to. But that's not what I want to show you today. What I want to show you today is how easy it is to set up your projects with code quality and code security. So I'm going to go to the plus to analyze a new project. Now, it asks me if I want to analyze a project from one of the existing organizations that I already have access to, but again, that's not what I want to show you today. I'm going to show you creating an organization from my ALM. So I'm going to choose GitHub. And when I get here, it says, which organization do you want on GitHub? I'm going to choose my private one. And now GitHub is asking me to grant permissions. Now, I don't want to give Sonar Cloud, I'm just trying this out, right? So I don't want to give Sonar Cloud permission to all my repositories. I'm going to select the repositories that I've chosen, I forked recently for this demonstration. So I type in my repositories. And there are a couple that I want to show you. And once I've got them selected, I can save that. That brings me back to Sonar Cloud, where I've got a couple more steps to get through. So I have to name, set a key for my organization. I'm going to go with the default. I do want the free plan. Sonar Cloud is free for open source projects. So I'm going to create my organization like that. Now, Sonar Cloud is asking me of the repositories it has access to, which ones I want to analyze. I want to analyze both of them. Now, I click Setup. And what's happening now is Sonar Cloud is checking out my code. And it's taking a look at it to see if it can automatically analyze it for me. So I don't have to do any CI CD setup here. It's just going to handle it for me. So it looks at my code. It says, yes, I can run an automatic analysis on this. And it's analyzing the latest version of master. And from this point forward, for every commit on my main branch and for every new PR, it's going to run that analysis for me, reflect the results in my PR in GitHub with a check on my PR. So now, my little application has already finished analyzing. Let's jump in and see what I've got. So here's my overview. Zero bugs. I've got some vulnerabilities. I've got some other issues. But what I really want to show you here is the issues. So here, I've got my list of issues. It's not terribly useful, though, to just see a list of issues without context. So I'm going to dive in here. Let's look at the blocker issues and look at the rules. And I've got database queries should not be vulnerable to injection attacks. So let's see which ones those are. And I'm going to click on this to see the issue in the context of the code. Now, this application was crafted to demonstrate vulnerabilities. And so what we're seeing here is a really compact vulnerability flow. But the reality is that in normal projects, the vulnerability flow is going to span not just functions, but probably pages as well, different files in the project. We've crafted the UI, even though you're not quite seeing that here, to make that flow across functions and files easy to understand. So that's what I wanted to show you in this project. Now, I'm going to return to my list of projects. And my other one is done analyzing by now. So I want to jump into that one. And again, I've got my overview here at the top. And I want to show you something on the issues page. And that is here under the list of languages. So now, we're here to talk about JavaScript today. And that's primarily what I'm looking at. But I do want to point out to you that I've got issues raised on both the JavaScript and the HTML code in my project. It's a reality today that most projects are not monolingual. Most projects have multiple languages in them. And so for the cost of that one setup, I'm getting not just the analysis of my JavaScript, but of the other languages in my project as well. So that's pretty cool. Now, again, to narrow it down to blockers, just to look at the most interesting things. If I look at the rules that are being broken, here's a dynamic code execution for injection attacks. Let's see what that one's about. All right, so here, I've got a little bit larger issue flow. Now, maybe I'm not savvy about security. Maybe I don't understand why this is a problem. If that's the case, I've got the rule description here ready at hand so that I can understand not just why I should be following the rule, or not just what bad thing can happen if I don't follow the rule. But I've also typically got some code samples so that I can see broken code, bad code, and then I can see that same code fixed. So I can apply that pattern to my own code to make the fixes in my code. So I'm almost out of time. But fortunately, I'm out of everything I wanted to say. Thank you very much for your time and attention. And I'll talk to you later. Thank you.


G. Ann Campbell

Node Congress 2021

The Security Toolbox For Node

Milecia McGregor

JSNation Live

JSNation Live 2021

Securing Node.js APIs with Decentralised Identity Tokens

Welcome to this talk, where we will learn more about securing a Node.js API using decentralized identity token. My name is Mohammad Shahbaz Alam, a developer advocate at Magic. In this talk, we will learn what is a decentralized identity token, build a Node.js API using Express and then protect that API using Magic. So what is DID token? DID token created by Magic is adapted by prior tech like JWTs and W3 DID protocol. It is encoded as a base64 string, a JSON string tuple, which is representing proof and claim. It leverages the Ethereum blockchain algorithm and elliptic curve cryptography to generate verifiable proof of authentication and authorization. These proofs are lightweight digital signatures, which is shared between client and server to manage permission, protect routes and resources and authenticate users. A typical DID consists of proof and claim. Claim is the unsigned data representing the user's data and proof is by signing that using Ethereum's personal sign algorithm and using user's private key. And then you get the DID token by calling b2a and using base64 JSON tuple string. So this is how a basic generating DID token looks like, which consists of issue.expiration, subject, DID, not before time and all sort of information over here. The issuer is the user's public key in the claim and when we are signing using sign function, we use the user's private key, which is again, we don't look those data. And then you get the, we encode the DID token so it can be easily transported over HTTP. And the easiest way to get started with Magic is using Magic's client SDK. The client SDK is where you get the DID token. So you use that, pass on the API key, which is like two type of API key. One is the publishable key and another one is the secret key. Secret key is used for server, publishable key is for client applications. You call a function called login with email and then pass on the user's email. By default, you will get a DID token of a lifespan of 15 minutes, but if you want more than that, you can call getIDtoken function to get that. The user flow or the auth flow is that a user calls the client to get, by authenticating himself or herself, they get the DID token and they trade that DID token in the authorization header to the server and server validates that token and then allows the protected route. So let's build the API. Easiest way to get started is to run npx make magic and select the template express API. So I have already done this and you would see that I ran an application. I'll just showcase what it looks like. For example, npx make magic template express API. It will ask for your application name, test API, and then you can use the publishable secret key. For example, you can get this secret key by logging into magic and signing up. It's free to do that and copy the secret key from the application folder. If you're not seeing this, you select this and select your application and then reveal the secret key. Just paste in here and then select your application. That's it. Once that is done, it will be open and it will look something like this. So your application is running on port 8080. It has multiple routes. The normal route is the basic route, which gives you an unprotected route. The other one is the secret route, which is protected by a middleware, which we have wrote, which you can always see by seeing the example. So I have already created an application called JS Nation. Just see this in this function, you would see that nothing much is happening, but this is a very basic API where we are using magic secret key from the environment variable. We are using a port variable as well. And then we are instantiating the magic here. And then this is a list of to-do, which is simulating the database, but obviously you would need a proper database. So this is an unprotected route. This is a protected route. You protect this by calling isAuthorized. So I'll show how it isAuthorized function looks like. So this is a middleware and these to-dos are like unprotected API routes. It's getRequest and getOfOneID, like getting the first to-do or the second to-do. These are unprotected. So another way of using the protected route or the middleware is to use app.use and pass on the authorization functions, what we have called isAuthorized. And then all these routes are by default protected because we are using here. So if we want to use it the older way, we would have to pass on to all of the functions over here. So let's see how the isAuthorized looks like. It accepts request, response, and next. We check first the authorization header is not defined and then extract the DID token from the header. And then we call magic.token.validate, which shows you if there's an error, they will say that there is an error. And else we would continue by calling next. And vice versa, you can find more of the details when you run NPX MakeMagic and this template. So the easiest way to see this is by getting a DID token. The easiest way to get the DID token, again, to run the NPX MakeMagic and template, use the next template, which is what I have used. And then it will run your server and it will, once you log in, it will give you a DID token. So once you do that, just pass on the secret key over here. And I have pasted this and you would see that this is asking for that, like we are allowed. And if not, we would say that this is failed. And it has update, put, delete, all sort of restful verbs, HTTP verbs. So more on that, you can find more. So easiest way to run is by getting the DID token is from the front end, by running this particular command, NPX MakeMagic and selecting a template next. By default, next won't give you much help, like in terms of DID token. So what I have called is that I have taken a DID here and then calling the get DID token and then displaying the DID token. Feel free to explore the docs at Magic. And then, yeah, this is the resources you can find and learn more about. And if you run into any trouble, just run NPSMDSPZALM, my username, and then all bunch of information would be there. Feel free to reach out to me if you have any question. So yes. Thank you again, GS Nation, for having me and for a wonderful conference. Hi. Bye-bye.


Mohammad Shahbaz Alam

Automated Security Testing for JS Apps & Underlying APIs

What's up, JS Nation Live? Scott Gerlach, co-founder and CSO of StackHawk here. Thanks for taking time to check out what StackHawk has to offer. Real quick, StackHawk is a dynamic application security testing tool. You can use it to test your running HTTP applications. That's application and API security testing. REST APIs, GraphQL, server-side HTML, and single-page apps. StackHawk was built for automation in CICD. Makes finding and fixing security vulnerabilities very, very simple. A little bit of how it works. First of all, it scans your application, and by scans your application, we mean it runs anywhere. You can run it on your local host while you're writing code, testing your application, back that up in CICD, test your application there before you push it to prod. And then again, if you want to, you can run it in prod. It's built to scan those modern applications, like I mentioned, server-side HTML, single-page apps, REST API, where you have an open API spec, and GraphQL, where you have GraphQL introspection queries turned on. All of those things help inform the scanner as to how to do a good job testing your application for security vulnerabilities. Once the test is all done, it does a really good job of showing you where those problems are found and potentially how to fix them. Finding and fixing those security issues is super simple with the StackHawk platform. The StackHawk platform presents you with the criticality of an issue, the issue type, the path, and the request-response pair that actually generated the issue. The other thing that's really awesome about the StackHawk platform is there's a curl recreation of that finding. So there's a curl command that you can copy and paste and run the same attack that the scanner did against your application. To be able to put your application in debug mode, step through that code and quickly find where you may have made a mistake. All of that is set up for CICD, and you can break your build. You can set up the StackHawk scanner to exit non-zero if it finds an issue of a severity type medium or higher, high or high or higher, low or higher. All of those things are totally configurable in the StackHawk platform. It does not do that natively. You can configure that for your own work. StackHawk integrates with your engineering stack. As you can see, I've got icons from some of the major popular players in CICD. StackHawk works with all of them. It's because it's Docker based, if your CICD system can run Docker, it can run StackHawk. Let's jump into a quick demo to see how StackHawk works. Here you can see I've got my vulnerable Django application. This is just a basic Django application, so server-side HTML, and I'm testing it with my StackHawk scanner. The way that looks is I've got a simple Docker command, docker run stackhawk hawkscan. I pointed out the configuration file, which we're going to take a look at next. What happens is the DAST scanner crawls your application, looking for interesting things to test, and then tests it. Once that's done, you get a simple summary of what's happening, what StackHawk found. Here you can see I've got a cross-site scripting issue, a SQL injection issue, and some lower issues. We'll focus on those highs for today. At the very bottom of this, I've got a link back to the StackHawk platform. This is exactly the same output you'd get in CICD. If you chose to break build in CICD, you'd have a link to be able to go triage these issues. That StackHawk configuration file we were just talking about is as simple as this. We believe in configuration as code, so DevOps principles. This particular configuration file lives with the code that it's testing. Is checked in a Git? You have Git history on who's changing what and when. Now importantly here, the things that you need to make StackHawk work are these fields right here. You've got to tell it the application ID, which is something we get out of the platform. You've got to tell it where to find that running host. In this case, my Django app is running on local host port 8020. What environment do I in? That's it. That's all you need to make a scan work. Obviously there's more that you can do to configure this file and make the scanner work better with your applications. Things like authentication, paths to ignore where you don't want it to test, where to find the rest API, open API spec or the GraphQL introspection, etc. But in this case, we're working with a server side application. Let's jump over to the platform. Here you can see the output of the scan that we just ran. So you can see my cross site scripting issue that we found, the SQL injection issue that we found. There's lots of other great information on this panel, but you can also see what plugins ran in StackHawk as well as the paths that the scanner discovered. This helps you get a good sense of what's being tested and how good that coverage is in describing your application. Let's go look at that SQL injection issue. So here you can see we've got a SQL injection issue on this polls SQL path in both the post and get methods. But over on the right hand side of our panel here, we've got request and response for both of these things. So selecting them changes the request response and you can flip in between. So you can see in this post issue here, we can see exactly what kind of post was made to our application and we can see how the application responded. Here's that validate button that I was talking about. So here's exactly the curl command that the scanner ran against your application. Now I can copy and paste that, get my application into debug mode and try to find where I've made the SQL mistake. Now you'll notice that I've already triaged these two particular issues and put them into JIRA tickets. We have a native JIRA Cloud integration to be able to push information out to JIRA Cloud. And you can see this is exactly what it looks like. So when I push this, if I can't work on it today as a developer, or I need to get it prioritized by our product team, I can push this out there as a ticket, get it prioritized. But the really important thing is once this ticket comes back around and we find out that we need to work on it, it has a link that takes you right back to this triage screen. So you can get into the context of what I need to look at and how to fix it very, very quickly. Other interesting things that happen in here, StackHawk has the ability to break down all of your applications into their microservices and test them individually. That makes scans faster, more accurate, and less false positive. So here I have all the applications that I remember testing, and I could go through this and kind of get a good overview of the security posture of those applications. Integrations that we have, as we mentioned before, lots of CICD integrations. All the major players are in here. And if they're not in here, it almost certainly works. We just haven't documented it. I've also got that Slack notification turned on in my account so that I get notifications of when scans start, when scans stop, and the summary of those scan findings. And then again, that Jira Cloud integration. If you want to check out StackHawk and see how it can help improve the quality of software that you're putting out there, reduce the amount of security bugs that you're publishing to the internet, you can always hook up a free StackHawk account and check it out for an application. I hope you have a great time at JS Nation. Thanks for checking out StackHawk.


#security