How to Exploit Real World Vulnerabilities

Rate this content

This workshop will lead you through installing and exploiting a number of intentionally vulnerable applications. The applications will use real-world packages with know vulnerabilities, including:

- Directory traversal
- Regular expression denial of service (ReDoS)
- Cross site scripting (XSS)
- Remote code execution (RCE)
- Arbitrary file overwrite (Zip Slip)
- These exploits exist in a number of applications, most of which you will need to install either locally or on a cloud instance.

You can do this workshop in 2 different flavours:

- Using the prepared Docker images OR
- Install everything on your local machine.

47 min
17 Nov, 2021


Sign in or register to post your comment.

Video Summary and Transcription

We'll discuss the benefits and vulnerabilities of open source software, including the importance of being aware of transitive dependencies. Open source supply chain security is a growing concern, and tools like Snyk can help identify and fix vulnerabilities. The workshop covers topics such as directory traversal, cross-site scripting, and catastrophic backtracking, demonstrating how these vulnerabilities can be exploited and fixed. The key takeaways include continuous scanning, checking vulnerabilities in new dependencies, and using tools like Snyk for secure software development.

Available in Español

1. Introduction to Open Source and Software Security

Short description:

We'll go over an overview of open source, its benefits, and how it saves time. Then we'll hack an application. My name is Noa, a solution engineer at Snyk. Feel free to ask questions in the Q&A messaging system or chat. Fork our Node.js booth app on workshop. What is the future of open source software security? Let's discuss. The majority of code is open source, and vulnerabilities are often found in transitive dependencies.

Hey, guys, thank you for joining my session. We're going to just an overview of what we're going to do. We're going to go over some slides just to understand open source, why it's awesome, how it saves us time and everything, and then we'll actually jump and actually hack an application. So let's get started.

My name is Noa. I'm a solution engineer at Snyk. And obviously, if you have any questions throughout the workshop, you have the question, the Q&A messaging system if you want to be kind of anonymous or you can ask me in the chat. I'll be looking there as well. And if you haven't already done so, please go to slash Snyk slash exploit workshop, that's where the actual hands-on session is going to be and fork our Node.js booth app, which is going to be connected with the first repo.

Cool, so starting off, isn't open source awesome, saves us a lot of time, it gives us, you know, makes us less frustrated, we don't have to actually write the code ourselves sometimes, we can just bring it from outside. And just kind of a question to ponder upon, what is the future of open source software security? Is it going to be, are we going to have more open source, less open source, you know, because sometimes it can bring vulnerabilities, and we're going to touch that very soon.

So as developers, you know, we write code, we debug code, we get over the code, and obviously, we, we get excited over the code when we fix issues. However, the code we actually face every day is very small compared to applications. So it's just the tip of the iceberg. And for those who actually looked at the code, were you able to find any security issues. And this I'll give it a second, if anyone wants to try out. I'll send the workshop links over here in the chat. There we go. So exactly. Yeah, the inputs are not sanitized. And we kind of just send them straight without checking what it is first. So that's the security issue. Good job. Great.

So when we think of code, as we said, we just looked at the tip of the iceberg. But actually 80 to 90% of the code base is open source. And 80% of vulnerabilities are actually found in transitive dependencies. So it's even the dependencies we're not aware that are in our code. So let's say I bring a dependency. But I don't know what dependencies they're bringing in.

2. Vulnerabilities in Transitive Dependencies

Short description:

80% of vulnerabilities are in transitive dependencies. We need to be aware of what we bring into our code. Tools like Snyk help us find and fix vulnerabilities. Our application is built on more than just custom code. Open source saves time but can introduce new vulnerabilities. Awareness is key. Do you know what's inside your dependencies? Supply chain security issues have occurred in the past.

So 80% of vulnerabilities are in the transitive dependencies. So here I have for an example of an open source package, Dust.js LinkedIn. And I see that it has a vulnerability. So I may not know where the vulnerability is. But at least I should be aware of it. And that's where we need to, you know, we need to be aware of what we're bringing into our code.

So we can use tools like Snyk, which later on, during the workshop itself, once we get to the hands on, we're actually going to create a login, like a user at Snyk. So we can actually find vulnerabilities. And later on after we exploit it, we can actually fix them and prevent them from happening. So again, I don't know where the issue is, but I know there's an issue. And I know the version that I'm at in this, in this dependency and I know what I want to fix it to, to get rid of the issue.

So let's visualize this, I guess, in our, in our head, this is our application, right? You're working on an application, you write the code. So this may be what you guys are thinking of, you know, some lines of code. However, as we said, the picture is a lot larger. So our application is built on a lot more than just our custom code. And that is why. Sorry, no questions. And that is why we need to be aware of it.

So we can also see that open source is heavily used. There is new packages created by ecosystem per year. It just keeps growing and it doesn't stop. Because again, it saves us so much time. It saves us a lot of frustration and it is super useful for us. So so the fact that we're using open source is great and fantastic and it helps us. But we shouldn't be surprised, you know, when new vulnerabilities are being added to our projects. So open source is great, bringing in new vulnerabilities as well. So there's kind of this like, is it amazing? Or is it not amazing? So again, awareness is key here. So how well do you actually know what's inside your dependencies? How well do you know them? And there's actually a supply chain security issue in 2018. I know it happened again in 2019. And again, I think pretty much we hear of like one big deal every year.

3. Open Source Supply Chain Security

Short description:

Open source supply chain security is a buzz word in the security world. A package called event stream had deadly transitive dependencies, making users vulnerable. We need to be aware of transitive dependencies and search for what they bring in. The US government is seeking a solution. Checking contributors and using tools like Snyk advisory are important to understand what's inside our code.

And open source supply chain security is kind of always a buzz word in the security world. So what happened is that there was a package called event stream. And with like hundreds of thousands of people brought this dependency and used it and then the next version, they the next version they published actually had a deadly dependency, transitive dependencies that event stream brought in. So the people who updated, you know, upgraded their dependencies without looking at what they're bringing in, were actually becoming very vulnerable to this. And that is why when we bring something, we really need to be aware of those transitive dependencies, especially them, because, you know, we can't fully know we need to actually search and see what those dependencies are bringing in.

So open source has been a really hot topic, even the US government is actually trying to find some sort of solution, you know, we need to understand how this issue can be solved. So there's a cyberspace solarium commission who was in charge of those open source issues. And then going back to this question, that how much do you really know about your dependencies? So for anyone who wants to write in the chat or maybe answer, what do you guys do when you download a dependency that you want to use? Do you search? Is there any or do you just say, oh, I know this library, I'm going to download it without checking the version? I'm going to wait. Don't think about it that much. Most people don't. So that's totally fine. Cool. So it really is like there's no we have a limited OCA solution. Cool. Checking contributors is also really important. Awesome. Thanks guys for answering. That was awesome. So to understand what's inside our code. So obviously the community to check how many contributing developers are there. You know if it's one and if it's one person we can't be too sure about it. So Snyk actually has an advisor. So the Snyk advisory. I'm sure if you guys are using something else that's fine too. This is what it would look like for example we have the package moment and over here we check the popularity. So how many downloads it has. You know so it has a lot of downloads means people are using it. It's great. So it's bringing up the package health score maintenance for example if it's not maintained you shouldn't use it just because if an issue is found no one's going to fix it later on in term of security. If it has vulnerabilities you know sometimes moment doesn't have vulnerabilities but it's using another dependency that does have vulnerabilities which will make moments vulnerable.

4. Open Source Community and Dependency Scanning

Short description:

Community understanding contributors. Vulnerabilities in direct vs. indirect dependencies. NPM's vulnerability in indirect dependencies. Tools for automating upgrades. Using Snyk to upgrade. Fork the repo and set it up. Scanning normal and dev dependencies. Checking package.json for vulnerabilities. Fixing vulnerabilities with upgrades. Visit for more information.

And lastly community really understanding like those contributors to the open source repo. So really got to check all of those. And again touching that the vulnerability is coming from direct dependencies versus indirect dependencies. I know this is a Node.js conference so NPM is actually very let's say if this was a contest it would be winning the most vulnerable indirect dependencies in the game. So we really because open source is such a big deal now. You know we have to have tools that even automate to keep updated. For example a new version came up and we found out that the old version is vulnerable. We need to have some tool that can even automate those upgrades. So we're actually going to use this today and we're gonna use Snyk and you can see how you can use it to upgrade it.

So I know this is like the fun part. So let's get started on that on that application. Have you guys forked the the repo? Did you get it to run? If anyone is having trouble, let me know. I'll give like two minutes for you guys to set it up and then we can I'll explain how it's going to go.

Yeah, so actually, we scan normal dependencies. The dev dependencies, we can scan them, but we need to add a flag for it, just because we know that sometimes we don't really care for those dependencies. So, we can scan them. It's another flag in the scan. Excuse me. My dog is right on cue. Cool. So, I'm going to assume you guys have the application running. It should look something like…something like this. Yeah, so…can you send the…yeah, I can send the repo again. So, sneak checks for those open source vulnerabilities. Specifically, you know, NodeJS, the Package Manager MPM. We look at the package.json file, and we look at the dependencies over there. And then, we actually run those against our database. And then, according to what you have in your project and the version, we actually give you…we tell you which ones are vulnerable and if you can actually fix them with an upgrade, for example. So, for those who do have the app running, you can go to Definitely gonna send it here as well.

5. Scanning and Exploiting Vulnerabilities

Short description:

We have a free version that you guys can use. No need to add your credit cards. Scan your code and get vulnerabilities. We'll have different tasks, starting with directory traversal. Set up the project, write code, and scan it with Snyk. You'll see the vulnerabilities in your app. The first issue is a directory traversal vulnerability. You can read about it and try to exploit it. Use the dot-dot option to navigate through files. Let's go to the command-line and try to get the website's content.

We have a free version that you guys can use. No need to add your credit cards like some companies. You can use it for free and you can actually integrate with your GitHub account or wherever you, if it's Bitbucket, or anywhere else. And you can actually scan it. And then you will, after a few seconds, you will get the vulnerabilities. And I guess while you guys do that, I'm just going to explain how it'll work.

So, once you get everything up and you scan Goof with Snyk and get the vulnerabilities, the workshop is, we'll have different tasks, and I'll go over them soon. But for each task, for example, you actually will, for example, we have direct traversal. And you need to hack using this vulnerability. So, you can actually look at Snyk to understand what the vulnerability is. And then you'll get hints of steps of how to do this. I mean, if you know how to do it, amazing. Can even go straight to the last one. But I think it's better if we do step by step. And I think the best way to do it is once, like, we give like 10 minutes for each one. Go over the solution together, and go to the next one.

So, the first issue we're tackling, let's imagine, I mean, I'm pretty sure for those who just got, who saw it, and for those who didn't, imagine someone changed the context of your application. So, that's something that can happen with directory traversal, and that's actually the first challenge. So, with a Docker, you would go, sorry, yeah, you need to, oh, you would just unzip it, go to that file, and then do docker compose, the exact, so I would download it, and then these are the commands, yep, maybe later, yeah, so these, docker load, minus i snkdemo2goof.tar, and then, also the mongo, and then docker-compose-up, great, so for those who have the project up, over here, and you can actually write, you know, hello, it's a to-do app, it's great, we can go to the about page, the bestest to-do app ever, I mean, if you really want, you can play with the, the CSS, but you're not gonna get very far, our team will not, accept those PRs, so going back to my to-do, I have hello, I can remove it, and play around with it, and then in terms of sneak, once you've scanned it, you can actually see, our super, super, super vulnerable app, we actually have 88 issues in this app, where we see that, a lot of them are high, and we have some critical as well. Cool. So, for those who have it up and running, in our goof, start playing around with it, and then, as we said, our first issue, is a denial of service issue, so we will go, sorry, I didn't mean denial of service directory, traversal, and it's going to take us over here, we can actually read about it, this is a screenshot that you can find at SYNC as well, you can read about it, the issue, we can see an overview of it, and then we can actually try to exploit this vulnerability. Directory traversal. Most, how would you, you know, when you think of, especially in the command-line, right, when we go to a different file, we would just go, you know, cd, and then if I want to go backwards, I can do that. If I want to go back to my Goof workshop, I'm going to go back to it. So the dot-dot is really an option here. So if you go to Goof, we kind of try, you know, doing the dot-dot, nothing really happens, right? So maybe it's just a browser issue. So let's be real hackers and go to the command-line. And I'm going to cheat a little just because I'm too lazy to write out the website, so I'm going to copy it. I actually want to see if I can get the website's content over here. Okay, so I got the about.html content here.

6. Directory Traversal and Cross-Site Scripting

Short description:

We'll discuss how to bypass dot-dot period and use URL encoding. Moving back from public allows us to find vulnerabilities in dependencies. For example, marked 0.3.5 is vulnerable. Directory traversal lets us access unauthorized places and override files. Next issue: malicious link leading to cross-site scripting.

So now I'm going to try to do the same or maybe go up you know, one directory. And I'm getting something strange over here. You know, the best kind of the goof to do which is the main page. So let me try to do one more. Go up one more directory. And I'm actually getting the same result. So for those who already got there or those who haven't but still want to answer how can I bypass the dot-dot period over here. Any ideas? Yep, exactly. Not how to defend yet against it. We want to first hack and then defend. So URL encoding, which does anyone know what they are? What are the URL encodings for periods? Yep, exactly. So we need two of those, right? Now we are going to go up one. So be moved, okay, what does that mean? We moved one and we actually, let's just do this. Oh, one second. Curl, instead of going back key by key. Okay, so we moved back from public. And now we can go around and actually find things. For example, if I look at package.json, I can actually see all the dependencies that are in this project. And by knowing the dependencies in this project, I can actually find where those vulnerabilities are. Right. So, for example, I'm not kind of spoilers, but marked is the next exercise that we will exploit. So, actually, by knowing that they're using mark 0.3.5, we know it's vulnerable and we know that we can exploit it. So the directory traversal actually lets me get to places that I shouldn't get to. And, for example, if they even have like right permission, I can override files and, you know, get passwords and usernames and really confidential stuff if needed. So I'm going to clear this. And we're going to go back to here, present. I'm going to give you the next scenario, and you guys are going to tell me what issue that could possibly be. So if one of your users was given a malicious link by your website, what would have like, what is that? How would that happen? Cross site scripting. Exactly. So that's our next issue.

7. Exploring Cross-Site Scripting and Markdown Links

Short description:

And I'm going to give you like five minutes to go over it again. The next topic is cross-site scripting. We'll discuss what it is and how to hack it. We'll go over the solution step by step. We'll explore the use of scripts and alerts, and understand how the application's sanitizer works. We'll also learn about Markdown links.

And I'm going to give you like five minutes to to go over it again. Again, all the steps are here. You can go to the next one.

This. Up next one is this one. Cross-site scripting. I kind of skipped one and we're going to go back to it. So cross-site scripting. And you have over here. Explanation. What cross-site scripting is. And of course, the hint. How to hack this.

So I'm going to give you five minutes and we will go over the solution. So if there's no volunteers, I'm going to go over the solution. So in a simple way that when we think of cross-site scripting, we actually think of, you know, adding and JavaScript script. So using something like this, and I'm not typing it out just because when I click on it, you'll see all the answers. So we're going to do it step by step.

So for example, if I try using scripts and add like some sort of an alert, nothing is going to happen. And the reason for this is that when this application was built, it's using the package. So if we actually, we can play around and, you know, make it bold and beautiful. And that's actually coming from this. We see Mark over here. And we're actually using a sanitizer for Mark. And that sanitizer is looking for some specific things about JavaScript. So, for example, it sees the script, alert1. Because it sees the script, it knows some sort of JavaScript and it just creates it as a string. And that's why we see it like this. So, if we read about Markdown and what it actually lets us do, we can actually use Markdown links. And those Markdown links are being used like this, for example.

8. Exploiting JavaScript Sanitizer

Short description:

And if I do it, I can click on it and it's going to take me to the syncUI. The reason for this is that Mark sanitizer is looking for the JavaScript word followed by a colon. We can try again with some encodings, representing the semi colon bracket. This trick confuses the browser, allowing us to exploit it.

And if I do it, I can click on it and it's going to take me to the syncUI, which is cool. And if I go, like, let's say I want something else. So I can actually do something that looks like this maybe. If I try that, you know, I have my JavaScript alert over here and my bad link. And I'm praying that it's going to work. Okay, but it still didn't work. And the reason for this is that Mark sanitizer is looking for this JavaScript word, you know JavaScript, and then the colon. So, it has regex behind the scenes that is actually looking for this and if it matches it won't let you won't let you post it. So we can be smart, and maybe try again with some encodings, and represent the semi colon bracket, like this. So, hopeful again that this will work. Okay, so this didn't work as well. And the reason for that is same concept, the reg x is also looking at JavaScript semi colon, and JavaScript and sign, hound sign, 58, so it's actually looking for all of this. And it's saying, well, I know that's that's the representation of the semico of a colon, so I'm not going to let that pass as well. So, thinking again thinking again. Okay, what if I add this. Adding this. So this trick. Actually works. Does anyone know the reason why this works for us. So, in a way, specifically this is used to confuse the browser. So the browser is saying, well this, the word this doesn't really match here, but they probably meant like it was probably a mistake and they meant to have it without this. So in this specific use case, the browser is actually ignoring this, but the regex since there is a this doesn't catch it. So the browser is actually the reason we're able to exploit it.

9. Open Source Community Issues

Short description:

Open source communities lack responsibility and maintenance, making them vulnerable to exploitation. Cross-site scripting vulnerabilities can arise from using certain documents. The lack of accountability in open source can lead to security issues. Denial of service attacks can block users from accessing websites. Dependencies like M.S. and M.S. can contribute to these issues.

And actually another issue with open source community is that no one is really responsible for anything. And if I go over here, this was actually an issue that was brought up specifically that if we use documents or this, it's going to cause a cross-site scripting issue. And this was brought up September 2015. Sorry, May 2015. And it was actually closed a year later. So in terms of using open source, you know, there's no responsibilities. It's just a community that does it. And if the community doesn't maintain it, it could be exploitable.

Instead of this alert. Let's try that. I'm not sure actually. Let's try. This. Delete. Nope, did not work. If I'm sending the GitHub link. Cool so that was prostate scripting. Go.

And now Another case for you. So, it's Christmas time and you own a very nice sweater shop, and people want to buy to shop online, and something's blocking the user from getting onto your site. What is it could this be. Very denial. Yep. Denial of service. So, again, same concept. We have, we have the steps over here. And I want you to create some, you know, use the command line use whatever you need and kind of block your website freeze it. This issue is actually coming from my direct dependencies that are bringing. It's called M.S. and M.S.

10. Using M.S. Package and Catastrophic Backtracking

Short description:

We're going to use the M.S. package to add an item to our to-do list and see the result on the webpage. By adding multiple fives and zeros, we observe a delay between each addition. Adding our name multiple times doesn't have any effect. This behavior is known as catastrophic backtracking.

is actually bringing a transitive dependencies dependency called I got the exact name of it. Have an open over here. So yeah ok. So M.S. is their direct dependencies and this is actually brought in by my humanized M.S. So this specific issue that's brought in by transitive dependency.

So we're going to again be good hackers and go to the command line and we're actually going to use that command. Use the M.S. package and we're going to you know we're just going to you want to add another another thing in my to do list I want to buy milk in five minutes. I'm going to enter that and we see that the finished and if I go over here and I refresh the page I see my milk five minutes. Cool.

So I'm going to do that again. So five right a lot of fives. Let's see what happens. OK. I'm going to refresh my page again. Still works fine. So now instead of manually writing all those fives I'm actually going to use this command which prints fives a lot of times. So I'm going to do that. And we see we're starting to see that there is a tiny bit of a delay between each one. So let's do the same thing and add another zero. OK, so we were starting to see that delay So I'm going to do it with one, two, three, four zeros. That's four. Yes, I'm blind. Yep. Four zeros. And. OK, it's taking a bit longer and I want to remove stuff and add things. Adding my name a lot of times and nothing is really happening. So behind the scenes, something that's called catastrophic backtracking is.

11. Catastrophic Backtracking in Regex

Short description:

In this specific package, we're using regex to look for numbers followed by words like minutes or hours. However, a change from 'S' to 'A' caused catastrophic backtracking, where the regex tries to find a match but panics when it doesn't. This smaller example involves finding a sequence of 'A' or one or more 'C's followed by 'D' at the end.

Sorry, I completely forgot that. I actually. OK, apologies for this. I skipped a step in my explanation and I totally forgot. So what happens here in this specific package is that we're looking for some kind of number. And then with using reg ex and then using and then looking for the word minutes or hours or anything like that, really. So. This is what we're looking for now in reg ex.

There is something that's called catastrophic backtracking, which is saying. It's it's trying to look for a match. OK, so what I did that caused the denial of service is that I actually change the S at the end. To an A. So if we go back to my the last command that I ran, you see over here, I switch to the S to an A. And that's the reason that causes the catastrophic backtracking. So what it does, it's looking, you know, it's it's going through all those numbers, you know, like a lot of fives looking through all of them finally gets. It's like, OK, I found in them. Great. I found an I. Great. All the way. I found an amazing last letter. Oh, no, it's not an S. What I do. So then it's it's starting to panic. The record starts to panic. So it goes back and it really, really tries to find that match. So this is a smaller example and a smaller scale because we don't have time to go for hundreds of examples.

So this example, we have a and then B or C plus. So a lot of C's, at least one C needs to be there. And then all of this expression needs to happen at least once and then it has to have a D at the end.

12. Exploiting and Fixing Vulnerabilities

Short description:

When we change the 'D' to something else, the number of steps jumps from 9 to 38. This causes panic as the match is lost. The same happens with 'minutes' changed to 'minutA'. After some time, all the additions are eventually made. We exploited the application, and now we want to fix it. By upgrading the version, we can resolve the issues. You can learn more about this issue in the learning module.

So the way it would look for this is something like this. This is steps. OK. Now, if we remove the D over here and we actually change it to something else. We can see it from nine steps. It jumped to thirty eight steps and this is just five letters. So now it just really panics and tries to find back that match. And that's actually what's happening with that minutes with an A at the end instead of S.

So now we see that after the time passed, it did eventually add all my Noah's. And milk. Any questions about this? Did that make sense? I'm sorry. Totally skip that super important step.

Cool so so now that we actually exploited. How do we get that right to see but I can send it to you over here. I just it's online it's a breaks one on one calm. I just like to, for those who love reg x this is a really nice website to to find matches and all that. Almost like Tinder. Just kidding. So now we have you know we exploited. We exploited the application now we actually want to fix it. So if you if you go to sneak and actually have them all been already those specific issues. So each one. This is the mark we're looking for. So each one has you know it has for example SD the first issue we we we exploited. So we can actually see all this information about it. We see that where it's introduced from from version zero point two point four and where it's fixed. So if we upgrade it only you know zero point zero one version up it's not vulnerable anymore. And actually if you want to learn more about this directory to results you there is a whole learning module that you can do over here that really teaches you kind of hands on what this issue is even though we just did it. So you guys are all experts now. And also, kind of an overview of what this issue is.

13. Fixing Vulnerabilities and Testing

Short description:

Prevent vulnerabilities by using the common vulnerability scoring system. Access vulnerability and open a fixed PR. Sneak runs tests to ensure no new vulnerabilities are added. Did anyone try the fixed PR? Rebuild and test the application to see the impact of the version.

So it would prevent for for this to happen you won't be able to deal with it. So of course, additional information like the common vulnerability scoring system you know which is an industry standard and of course, if you want to learn more about this specific library then you can read it all about over here. So with an easy, you know, click of a button.

I'm just gonna access vulnerability. But it's going to do it's going to now take me to a page where I can add if I want to fix more vulnerabilities, for example, I have a directory traversal over here by Adam's if. But I don't want to fix it right now I just want to focus on on St. So I'm going to open a fixed PR.

Now sneak behind the scenes going to write a commit message and open a new branch for this issue. Take a little time. I open my github and go to my goof app. I can see it isn't this one. OK, so my Internet is a bit slow. But in general, once you open that fixed PR, it's going to look like this. It's going to look like this. And you're actually have you're going to have that commit message with all the information about this issue. If it has a fixed or not the CBS or what kind of issue it is. So this one actually is an out of service one as well. But it's coming through mime it's a different issue.

So in addition to that, sneak will actually run additional tests on your on this branch to make sure that you're not adding any new vulnerabilities into your application. Because we have some sort of, you know, beginning phase where we just want to clean our application from vulnerabilities rather than adding new ones. So we're actually making sure that we're not adding any open source security issues, any license issues, and any static code analysis issues on the free plan, I believe that you will only see this one. So we're making sure we're not adding any new vulnerabilities into this. Did anyone get to try it out? Were you guys able to try to use the fixed PR? Anyone? Let me try to fix marked. I think it's maybe an issue on my side. But once you fix them, you can run your application again. After you obviously rebuild it. And once you do that, try to hack it again. Try to exploit the application again. And see that the version really matters. So in that terms here.

14. Fixing Vulnerabilities and Takeaways

Short description:

We upgraded the version of marked library, fixing the cross-site scripting issue. Takeaways: connect your source code repository for continuous scanning, know your sources, use Snyk advisory to check vulnerabilities in new dependencies before downloading them. Snyk is available for free.

There we go. So we got marked. So we're able to do a pull request for mark and we actually upgraded a version. And we see that all checks passed. Great. And I can actually merge it and knowing that actually fixed the cross site scripting issue. So now when I when I merge it and rerun my application, I won't be able to exploit it using the marked library. So wasn't that fun, guys? What can you do about this?

So takeaways for today's session is connect your source code repository to continue to continuously scan them. And obviously know your sources. If you're bringing in new dependencies, you can use Snyk advisory to check them out before. That way you'll know which version is vulnerable, which one you're waiting for the test to pass. Awesome. So you can use advisory to really understand what you're bringing into your projects before you actually download the package. And, yeah, if you guys can use Snyk for, you know, for free. Right here.

Watch more workshops on topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.