Liran Tal joins the Jabber to talk about how to secure your applications and how to check for security vulnerabilities in your application and its dependencies and infrastructure.

Liran explains how to check your supply chain and your own code to make sure you're not leaving things open to malicious actors.

Panel

Guest

Sponsors

Links

Picks

Contact AJ:

Contact Charles:

Contact Dan:

Contact Steve:

Special Guest: Liran Tal.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: Hello from cloudy and cool Portland. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hi from sunny Tel Aviv where it's actually not so sunny anymore because it's evening, but anyway. 

CHARLES MAX_WOOD: Doesn't this new mic sound so nice? Silky smooth. That's right. Dan smooth Shapir. All right. We've got AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from pleasant, really, really hot Grove. 

CHARLES MAX_WOOD: I'm Charles Maxwood from devchat.tv. And this week we have a special guest and that's Liran Tal. 

LIRAN_TAL: Hey everyone. Thank you all for having me today. I'm joining you from, from Eshdad, which is probably one hour south of Dan. Still not so much sunny here as well, because this is a very tight time zone here we're still on the same. What's up? Good deal. 

DAN_SHAPPIR: Yeah, in Israel, everything is more or less an hour away. That's just the way it is. Small country. 

CHARLES MAX_WOOD: Yeah. And you work for a SNYK? How do you say that? 

LIRAN_TAL: It's always a problem pronouncing that one. So I know where it is. It's SNYK. SNYK. 

CHARLES MAX_WOOD: OK. Good deal. Yeah, that fancy purple shirt that you're wearing that our listeners can't see. Yeah, I've been in 2019. I went to a bunch of conferences and SNYK was always there right but I'd always show up too late to get the large shirts right because the large and extra large shirts would always be gone and so I'd get the medium and the small shirts and so my kids so whenever I see those shirts I'm like oh my kids have those shirts 

DAN_SHAPPIR: but I'm still shocked that you're talking about the shirt rather than the hat go ahead But hat. But that's a hat? I don't know. It's quite a big... It has a really interesting hairstyle. 

AJ_O’NEAL: Well, I'm confused. Is it a Yoda or a Mickey Mouse or a Goat Yoda? 

LIRAN_TAL: It's point is to confuse them for security by obscurity. But it's a funny story. I won't say all of it because I think we need to drink a bit before that. But it's yeah, it was bought from a Disney store. So there you have it. But it was pre the whole...New franchise thing. This was like 10 years back. 

DAN_SHAPPIR: So you were drunk at Disneyland? 

LIRAN_TAL: Can you not be? Drunk on happiness. 

CHARLES MAX_WOOD: Gotcha. So it's the Mickey Mouse ears on a Yoda. 

LIRAN_TAL: Yep. 

CHARLES MAX_WOOD: Yeah. So somebody was drunk when they were making it, but let's, let's dive in and start talking about security and stuff like that, which is what sneak does. 

 

This episode of JavaScript Jabber is brought to you by Digital Ocean.DigitalOcean recently announced their new App Platform service, which is a solution to build modern cloud-native apps. With App Platform, you can build, deploy, and scale apps and static websites quickly and easily. Simply point your GitHub or GitLab repository and let the app platform do all the heavy lifting. As it has support for Node.js, Python, Go, PHP, Ruby, Static Sites, Docker and Container Images, DigitalOcean runs their app platform on their own infrastructure so your costs are significantly lower than the other products. Plus, they built this new app platform on top of DigitalOcean Kubernetes, providing a smoother migration path so you can take more control of your infrastructure setup. As a listener of JavaScript Jabber, you can get started for free. Better than free because DigitalOcean is giving you $100 credit when you go to do.co.jabber Again go to do.co.jabber to get your $100 free credit on DigitalOcean's new app platform. We want to thank DigitalOcean for sponsoring this episode of JavaScript Jabber. 

 

CHARLES MAX_WOOD: Do you? I'm just trying to decide the best place to start because when I went and would talk to you folks usually we'd be talking about like container security and stuff like that. Is that mostly where you're focused or I don't know, where do we start? 

LIRAN_TAL: Yeah, that's a good question. Where to start? Because I guess security could be interpreted and like lend into different areas. And so, SNYK kind of like operates, I think started like the roots of SNYK was like in the open source packages ecosystem. So it was doing dependencies and things like that, like looking into it. And there's a whole security research and teams around this, validating the information and finding them. And then SNYK went into the container space. So looking at Node.js, Docker images, for example, for all the JavaScript developers listening, you may have some runtime vulnerabilities in the Node runtime itself, or you may have container vulnerabilities in packages installed, libraries on the container operating system. And then you could go further to the right if I'd say so, like more to the back end SRE sort of way, which is infrastructure as code. So you build an application, you containerize it, but then you need to orchestrate this into production in some way. And so you maybe write a Terraform or a Kubernetes YAML file and say, I need two replicas of this, five replicas of that, etc. And so you may have security issues there. You may have open ports or privilege escalation because the container is running as a, you know, could escalate into root privileges and things like that. So all of that, going all of that way. And then what I think would be interesting to talk about more today is actually more of that shift left, which is security vulnerabilities that come in from your code, from my code, from basically everyone's own code, which is like a new thing that's SNYK is doing and super interesting in the way that we're doing it. 

CHARLES MAX_WOOD: So you went total DevOps, dude. He did. He went total DevOps and then he said shift left, which is a DevOps term, which usually means you go to the application code. So anyway, go ahead, Dan.

DAN_SHAPPIR: No, so I was just to get the, to understand the exact perspective. So are we going to talk mostly about the security in the code that we write ourselves or mostly in the code that we use libraries, packages, stuff like that that we import into our code? 

CHARLES MAX_WOOD: That stuff's all secure, Dan. 

DAN_SHAPPIR: For sure. I'm still, I, so, you know, we spoke about, we had this interesting episode with stack blitz where we're talking about them having the implementing their own NPM, which works within the browser and how you load all download all the stuff. And the one question that I didn't bring up, AJ was, was asking how do they manage to download like gigabytes of code and stuff really quickly. And I'm like, my thought was we were building, especially for the web, we're building bundles that should weigh something like, I don't know, 100K, 200K. Why do we need to download gigabytes of NPM stuff if at the end of the day, all we want is 100K? 

CHARLES MAX_WOOD: It's a good thing AJ's got something in his mouth. 

AJ_O’NEAL: I don't want 100K. How about 10K? Well, 10K might be a little shy, but 30K. Anyway. 

DAN_SHAPPIR: 30K. Yeah, but still, why download a gigabyte of stuff for 10, 20, 50 K worth of code. Anyway, 

CHARLES MAX_WOOD: 1.21 gigabytes. 

AJ_O’NEAL: Design by committee. 

CHARLES MAX_WOOD: All right. Let's let, let's let Liran have a crack at this one. 

LIRAN_TAL: That is a, this is funny because I, I guess I convert that in my head, uh, from the front end part of it to the backend, which is for me is like, you know, one gigabytes of node modules folder or something like that, but you know, always that get back into, which is if you think about it, it's, you know, less painful, right? That doesn't really impact the end user in a way. It's the developers or the end user and you back it up somewhere and deploy it. So that's a different kind of concern. But I hear you, Dan. I think what you're raising here is, and will maybe shift a bit from secure coding or security for developers to different concerns, which would be an interesting way to connect it back. And that is supply chain security. This is, you know, we are all part of this open source ecosystem, this driving ecosystem, especially in JavaScript. We're all using open source. It's pretty much impossible to use anything that's not open source. And, um, we are targets for others, others to basically infiltrate with the malicious things. And, uh, I have actually pretty interesting ways of how we connect that story from supply chain security into code security, but, uh, you know, I'm happy. To just start off with that, then it would be actually very interesting for me to ask you, are you concerned, anyone on this panel, about open source supply chain security? And how do you think that, where does this meet you as a developer? 

DAN_SHAPPIR: Well, of course I am, because at the end of the day, a significant portion of the code that gets shipped today is code not written by the developers of the applications. I recall statistics like like three fourths of downloaded code into the front end is third party code. Whether it's bundled into the same package or brought from an external source, it doesn't really make a difference, especially in the context of the browser, because it's all running with the exact same privilege within the browser frame or tab or whatever, what have you. And on the back end, it's the same, but even worse because all the code has like, usually has really significant privileges into the operating system, the ability to touch files, open sockets, do whatever. And, and, and again, we were talking about downloading gigabytes of stuff in order to create 200 kilobyte bundle, regardless of whether it's running front end or back end. Who has the time and inclination to wait through that the gigabyte of stuff and figure out what's what's all the stuff that's in there and what it's actually doing. So, so for sure I'm concerned, but for a lot of developers, that's just basically the cost of doing business. 

CHARLES MAX_WOOD: Well, the other thing with the supply chain stuff that's fascinating to me. So I'm going to back this up for just a second. We have adventures in DevOps on the devchat.tv podcast network. And we've had conversations about this stuff, right? With your dependencies and you can go listen to some of those. I'll put links to some of that in the show notes, but what's fascinating on, on top of that was, uh, the solar winds breach, right? And how that all came about. So sometimes we think about some of this in the context of, okay, you know, there's something in the tool chain that's dependency of a dependency of a dependency somewhere in the chain provide some helpful utility. That's why it's in there. And then it's got some malicious code in it. Right. But the way that the solar winds hack happened was that they actually hacked the build server, right. And so it wasn't that somebody took over the package and then went in and said, I'm going to put in this key logger or I'm going to put in this, send me all the password stuff, which is kind of egregious. Usually it's a little more sophisticated than that, but just to be obvious, right? I'm going to put this bad stuff in here, right? No, you know, they get on say Travis CI, right? And, or they get on some build system somewhere, right? And so Coder Dude goes and writes this awesome utility that I need in TypeScript. And then they had some build system out there. And so before they ship it in their web pack build in one of the plugins right? It goes and it says, Oh, and give me access to this. Right. And so it's, it might be in their tool chain that has the breach to my toolchain. Right. And so it's even more insidious than that. And we're not even thinking about some of this stuff. Right. And so I don't even see it because it's buried because it's, it's sophisticated in the way that it was put in, in the first place.

LIRAN_TAL: Yeah, for sure. I mean, this is SolarWinds as one example, I think, making the headlines and we can talk about more. I have a whole talk about talking to the CISOs where I go around supply chain security and what it actually entails. And I think what you're kind of like Charles talking about here is developers are basically now targeted as malware distribution vehicles. We are now developers in their CIs and their tools we are being targeted. Event Stream has been a great example of that. You know, 2 million downloads, a package that was, you know, largely, you know, I wouldn't say un-maintained, but it was, you know, it wasn't really actively maintained. And, you know, Dominic, the person owning that, you know, is a very good person, but he was maintaining 500 other packages on NPM. You know, someone chiming in, they want to help. Of course it, it'd give them some help. And, you know, that's kind of like how hijacking happens. 

CHARLES MAX_WOOD: We'll put a link to that episode in too. 

LIRAN_TAL: Definitely. So I think if you want to be like, you know, if you haven't been concerned enough about open source supply chain security, I'll give two perspectives here. It starts from winding back into, you know, 1984, there was this maybe anonymous developer to some of you here, maybe not this Turing Award winner called Ken Thompson. So not a very popular guy. Maybe some people know him. Yeah, you should. So this person had this paper called reflections on trusting trust back in 1984. And he kind of like describes how we backdoors the Unix login program. And then he continues and says, well, I'll go ahead and add a backdoor to the C compiler. So like when the C compiler compiles the login program, that's when, you know, the backdoor will get injected, but then he goes and says, well, you know what? People use compilers to compile stuff. So what I'll do, you know, people might look at the compiler source code. So I'll compile the compiler that compiles the login program. And you might need to listen to this a little bit more, but this is basically explaining how you could hide a Trojan, any kind of malicious code inside other code, because you have to have a level of trust somewhere. You need to trust either the login program or the compiler, or the compiler binary that compiles the new compiler. So you have to trust something. It might not even be the keyboard that you trust because someone could have keyloggered it or whatever. So this is the whole supply chain security. You need to trust something and that's the concerns that we have and the balance between what do we trust? Where do we put security controls and the mitigations versus what is good enough like UX, like with passwords? 1, 2, 3, 4 is a very convenient password, but it's not really a good password. So we should do something about it. And that's like where, where there is friction. 

STEVE_EDWARDS: Oh, I better go change my password. 

LIRAN_TAL: I just changed mine actually, but I go ahead and charge yours as well. So I want to connect this into, into this, into our supply chain and talk about what secure coding is because it can be, I think, anything from your dependencies to, you know, your own code to the Docker file that you build that may have vulnerabilities, you know, in the way that you build it, which is insecure. And the way that they'll connect it to JavaScript developers is now, SNYK was just now, we have this research team, so they just disclosed this security research where we found vulnerabilities and Visual Studio Code extensions. Right now, these are not malicious packages. These is our extensions that I use for Markdown, I can view it nicely in VS Code, and Lattx and something else, all of those cool blog posts that you read about, like the 10 must-have developer extensions for VS Code. Now, one of them had vulnerabilities, actually four of them, if I remember the details correctly, four of them had vulnerabilities. In total, they had received over 2 million downloads. That's 2 million users that are using them are potentially vulnerable. Now the thing is, the way that we connect that now to secure coding and the whole supply chain to secure coding is I've now basically downloaded package. It's not malicious, it's innocent. It's just doing markdown files, but it has a vulnerability. And what we demonstrate in that research is you know, Charles, if I send you that link, any link on Twitter, you know, what's up, whatever on this zoom call, I asked you to just open it. It's a nice, really cool, you know, thread on Reddit. They're never cool. But anyway, if you go and open that and click on this link, just by the fact that you've clicked on it, I can basically do things from path traversal to like, which means basically I can read any file that you have locally stored on your development environment which is bad because that's anywhere from your.npmrc, which is your NPM token, if you're a maintainer, up to your SSH key and other very sensitive stuff. So it could be that and it could be remote code execution and I could run anything on your development and write it on your Mac or on your windows or anything else. And this I think connects the whole thing where supply chain security, which is a package that exists as an extension on VS code, which I go to the marketplace and download, and it has vulnerabilities inside it which someone can actually, which I never thought about this as like as an attack vector, right? But someone can exploit the fact that I did not write my extension correctly. And just by that fact, they could actually get into my computer. And that's, that's for me a bit insane. And you know what we're probably going to see more and more in the, in the coming time. 

AJ_O’NEAL: I'm a little confused by this because if I'm thinking of a Markdown plugin, I just don't know where the vector of attack would be because this shouldn't be running a web server locally. So I shouldn't be able to get into it from a web page. And if it's marked down, it shouldn't be executing any code in the document because it's a text document that displays it doesn't execute. So where, I mean, I don't know if you just pulled that example out of the air or if, is that a real thing? 

LIRAN_TAL: I love that. Yeah. I love that, uh, that example, uh, the case that you gave because. Actually that Markdown extension has over 100,000 downloads. And what it does is it does spin off a web server that serves the Markdown file in HTML. That's how you see it in the, in the VS code tab when you open it. And indeed that was, that has an insecure coding vulnerability where it has, you can do path traversal. So it's enough for me to send you a link that works locally on your machine and I can retrieve any file there and then send it back to me. Now the actual exploit is a little bit more, I'll say, comprehensive and complicated than just that, because how do you open stuff in the browser? And even if I send you a link, how do I get to, you know, your local host? How do you send something back without being stuck by cores and other, you know, kind of like security mitigations, but, you know, we've got it and this, you know, this is live and on a, like a GitHub repo, like people can, you know, see it and, you know, view it and replicate the whole attack vector. But this is exactly what's happening. And remote code execution is also possible due to vulnerability in latex, you know, an extension that gets downloaded 1.2 million times already. 

AJ_O’NEAL: Wow. I, I never thought about that. I just assumed it generated the HTML file. I didn't realize it was running a web server. I feel so naked now. 

CHARLES MAX_WOOD: I'm closing my eyes. 

DAN_SHAPPIR: You feel vulnerable. Hi, AJ. Oh, 

CHARLES MAX_WOOD: that's better. I'm opening my eyes now. 

DAN_SHAPPIR: But I wanted to ask, so, okay. So yeah, so we live in a scary, in a scary world and people do, you know bad things, usually by mistake, sometimes maliciously. But what can I do about it? I mean, you know, am I gonna just stop using VS code extensions? I mean, VS code itself is open source. Maybe VS code itself might get compromised. Like what do I do? 

AJ_O’NEAL: Well, you go back to Vim, right? 

CHARLES MAX_WOOD: You audit everything. Audit it all all by yourself. 

AJ_O’NEAL: Or does the Vim Markdown extension run in a web server too there? 

LIRAN_TAL: I have no idea about the Vim one, but I'll take a look afterwards and see. Yeah, Dan, it's a scary world. And I think that is why supply chain security scares me a lot because I will not give up using this code either. And even if I'm like a little bit more concerned about the extension that I use, I just gave an example where the extension was fine, but you know, it still had some flaws that allowed someone to get in and I'm not going to go and like read code review every package. That's like insane. So we kind of need to accept the risk to a sense. But if you think about it from the other way around. It all kind of starts with us, right? As developers, what if you Dan, as a developer, you build extensions, would have, you know, tools and ways process as whatever, you know, secure coding with users or such that would help you to basically write secure code, just like you want to write, you know, secure, sorry, performance websites and secure websites, right? You have, you know, web tools and Lighthouse or whatever, and you care about the bundle sizes and everything else. Security is something you actually want to care about, but it's a bit hard because from like, I think the assumption that people, it looks a little bit foreign, there's an expertise that's needed and so on. So it looks a little bit maybe unreachable. And I think that is really what we're trying to help developers at SNYK with that SNYK code, study code analysis tool, helps them find them. 

DAN_SHAPPIR: So just to clarify what it is that we're talking about. So again, from my perspective, and I'm not an expert in the field, they're really too general approaches that I can take, I think. One is I can limit the capabilities of the tool or the environment. So, you know, for example, one of the things that Dino does compared to Node is basically say, unlike Node, which basically allows anything or everything, Dino by default doesn't allow anything, and you actually need to tell it explicitly to allow certain things. So certain applications that bad code might still be injected, but then would fail because it just, the environment that it's running in won't give it the permissions to do the bad things that it wants to do. But on the other hand, it's kind of like the permission thing on mobile devices. You want that app. So that app says, yeah, but I need permissions to access your photos and your contacts and whatnot. And you say, but I really want to play that game. So you let it have them. And that's kind of my problem with this permission based thing is, is, is yeah, if you're rigorous about, about it, you can block a lot of attack vectors. But then the end of the day, there, we want the software that we want. I understand that you're actually advocating or describing something else. Tools that are saying, yeah, we live in this dangerous world. We are going to help you at least write less exploitable code. Is that, is that what you're talking about? 

LIRAN_TAL: Yes, but I'm not saying this is the only thing. I know security is all about putting layers of security, you know, principle called security in depth, which is, you know, if, if we can limit the, you know, what, what, what VS code extensions allow, you know, what VS code allows extensions to do. If we can limit that scope, you know, the same kind of like security model that Dino has, that's great. Like let's do it, but you know, it's not done today. And is it realistic to expect that every new sublime and your VS code and your I term and everything else that has a marketplace will adopt it? No, and it will take time. So what I'm saying to begin with, we as developers writing code, it would be great if we start off with ourselves and write more secure code to begin with. 

CHARLES MAX_WOOD: Yeah. But the problem is, is that like, how do I put it? So you're saying, well, you need to go and write the plugins that that are secure. But my problem is, is that I don't even know. I don't know the vulnerabilities that I don't know, I guess. Right. I don't know where my gaps in my knowledge are. And so, I mean, I can go do research and I can go and try and figure out where kind of the low hanging fruit is or where the obvious issues are. Right. And I try and stay up to date on this stuff. Right. Because I have a full time job at a large financial company that they, I mean, they put us through a bunch of training. Right. It's like don't do any of this stuff because we could get in trouble, right? But at the end of the day, there's just so much to know, right? And you can go read up on OWASP and you can go do all this other stuff, but yeah, you know, it's impossible to know it all. 

LIRAN_TAL: You're right. This is tough. And that's kind of like, uh, I think we're the world aligns with what we're trying to do with developer first security tooling, right? Which is not, not just there's two things here. There's finding the issues and then there's fixing them. So let's start with finding, like you said, Charles, like how do we know if we are writing insecure code? So I'd say there's, we could try as developers to use different tools. One of them is if people use ESLint as a linter, most JavaScript developers probably are aware of it and you'll probably use it. 

CHARLES MAX_WOOD: Yeah, we're using it. 

LIRAN_TAL: Exactly. I use it as well. But it says, more popular as the code quality slash code style kind of, you know, maybe guidelines around your code base. You want to make sure that everyone writes in, you know, in the same way and on the team and so on. It's less known as a security tool and rightfully so, because it has, there's a, there's like an ESLint plugin security nodes, kind of like a NPM package that you could plug into ESLint, but it finds it's too brittle, right? It finds things like if you're doing object inside an object. So it's it considers it as an object injection, which is truly what it could be. But that's a lot of false positives. And if you're doing something like child process, you know, because you're writing a CLI or you need to do something, it will complain if it doesn't have, if it has a variable versus, uh, actually, uh, you know, a hard coded file name or something like that, so it's still brittle. So we tried those static code analysis tools for security and it doesn't really work too well. Like I don't know many developers using those ESLint security plugins, plus that specific one is very specific to Node where you have a whole large attack surface on the front end with, you know, view and react and Angular and all of those. But the other way trying to help developers is this terminology for a set of tooling called SAST, which is static application security testing. They are basically the same thing as a Niaslint, but just a little bit smarter. They understand how the code works, kind of like translating it into an ASD, an abstract syntax tree, and trying to say, well, if something flows from the user input from, say, the express request object into a SNYK, which is something that's a sensitive kind of like operation, like a database call or something like that, then that is a potential, maybe an SQL injection or something worse. So we want to use tooling like that. And the problem that I think we had in the industry until now is we haven't had those SaaS tools that were built for developers. Like they were built in terms of they were meant to kind of like be used in a CI. They would take hours, if not days to run. So I remember using that back when I was working at HP Enterprise, you know, maybe like five, six years ago or so, we were running them on the weekends. And even at that point, we're running them with deltas over our code because it took time and then we needed to go through the reports. And usually there's a lot of like false positives, like you maybe sometimes have with, you know, dependencies as well. So you have to try agile of this and go through it and it takes time and so on. So it's not really, really dev friendly. And that's kind of like the problem with this. And I would go ahead. 

DAN_SHAPPIR: If I can ask something about that, how much of the problem in that you're describing has to do with the fact that we are coding in JavaScript, JavaScript being such a malleable and dynamic language. I mean, would it been like a lot easier or at least more possible if we were using some, something that more static language, more declarative type programming language, one of those reason ML sort of things or Haskell or I don't know, something along these lines? 

LIRAN_TAL: Well, yes and no. I mean, there's definitely a significant factor in terms of like, have we ever seen, you know, tooling for JavaScript, you know, at a very good level? I don't think we have seen that too much before. And that's something to observe and see if we're able to find a tooling that helps with this. But also, I would say SaaS tools are built by security companies. And the question, I'll flip the question the other way around. JavaScript has been a clear winner in the language ecosystem for not for too long. It hasn't been there a clear winner for the last 40 years. It maybe has been the last five years, maybe a decade if you want to shout that back at like Angular from 2010 or something like that. So tools, you know, even, you know, at the beginning, like tools were focusing on things like Java and something else, you know, they weren't focusing on JavaScript. So there wasn't a whole lot of research and, you know, working with dynamic languages wasn't, you know, that much of a, of a, of a focus. But nowadays it is, it is at least like with, you know, the stuff that I'm involved with building and that's really, really fun and interesting. And the other part of it is beyond now understanding that this is a really good focus, yes, the language might have some challenges in terms of how we can identify in a very good way without false positives, a source to a sink and a potential vulnerability. But a lot of times there are very simple, I would say practices that developers don't do in terms of how they build up maybe a logic. And that leads to potential significant security issues that are not really hard to find out. For example, path traversals. For example, like, you know, we understand the logic where you're trying to access a file or save or upload or, you know, do something with it. And you are concatenating two variables without actually using a sanitizer before, or you're not concatenating them in a bad way and so on. It goes to open redirects and, you know, many other, I'll say, potential vulnerabilities in your code that are not that hard to detect. And actually really easy sometimes to fix as well. So that's really great if we can surface those. 

DAN_SHAPPIR: It's really amusing how after all these years, concatenating files, directories, paths, or URLs remains such a challenge. 

LIRAN_TAL: It is. Yep. This is the story of like that Markdown extension. It had path traversal, it just concatenated to strings. And sometimes by the way, it's, it's the fact that developers do not understand exactly how the underlying APIs work. So even if you do like path join, like the node API to do, to join to directories, you do path join and you do a dot slash in the beginning to make it relative. It doesn't stop me from, you know, doing dot dot slash, you know, as the user inputs later on and escaping or, or, or people like, you know, sanitize, they say, oh, people will do dot dot slash dot dot slash, I'll go ahead and sanitize it and then concatenate the strings. But people do not understand that you could encode like URL, encode that into 2% E 2% E, which is a URL encoding for dots and that works and that has been a bad reversal in the ST module. The NPM package that served, you know, was like a local HTML server and has been, you know, people writing those pieces of code and not understanding exactly the best practices, exactly how to use the API, exactly how to, how to escape or how to work with data. And we make those mistakes all the time. 

AJ_O’NEAL: That really is strange because we've had SQL injection for a little while that was bad. And then every single SQL library since, I don't know, 1999 or so has had a secure by default query method. It's interesting that we don't have across every language is secure by default path join. You bring up a really interesting point. I'm glad you mentioned that about the, the URL encoding. I didn't know about that. 

LIRAN_TAL: Yep. I'm glad we're like learning new things here, what, you know, this is part of the, of the solution, right? It's educating and creating awareness in terms of how to do things correctly and having the tooling that helps us do it as well. 

AJ_O’NEAL: I'm going to create an MVM module real quick path.safetune. 

DAN_SHAPPIR: So going back to the tooling, you started mentioning the type of tooling that, that you guys are either doing or looking at. So can you elaborate on that? 

LIRAN_TAL: Yeah, definitely. So, right. So SNYK does this, uh, has this, uh, product called SNYK Code and it's freely available, but much closer to the developers, it's available already in the extension marketplace. If you're using VS Code or IntelliJ, you could go ahead and install it and use it. And I think that is a lot of the mindset, the mind shift of understanding where developers need security. And that is very early on. So it has a CLI as well. You have the SNYK CLI, you can run SNYK code test and you can use that if you think about it a little bit more, that's what I want to do more, is position this as kind of like a linter. This is another part of your local CI step, if you want to call it like that. And you can use it as like pre-commit hooks, which makes sure that all of your open source dependencies are clean and make sure that your code is clean. And then if you go back to the developer experience, that is, think that you are just writing a path concatenation kind of like logic to do something, I don't know, for whatever reasons. But if you're doing that, while you're actually coding, the IDE plugin analyzes your code, sends it to our remote server. It happens super fast. It's, this is like seconds. You, you know, the moment that I do command S to save the file, that's when, where it takes place. And at that point, if I've done something that potentially bad, I'll get, you know, that's kind of like, you know, the linter kind of like where it underlines, uh, the API called the function of what I've done. And it will tell me what is wrong with that. Whether that is a patch reversal or an SQL injection or something else. And I would say I'll go now to the to the extent of where I really love where this is going and what we're developing. If you use the extension, what we actually do is not only find those issues and surface them, when you look at the show suggestion to fix it, like Linter is kind of like want to do, it actually opens for you a tab, which in VS Code, in another view, and says, these are three commits that I found that had a similar issue, and they showed you the committed div that actually fixed it. So if you think about it, it's kind of like bringing stack overflow, the website into your IDE for security. And I'm not going to recommend this now, but in an essence, it's like you could copy paste the correct code into your code base from that suggestion of some other commits. If you trust it enough, if you have verified it, and so on. And this is the fix. So we are going to help you find, but not only find, but actually fix the problem. And this is, I think, where the whole developer friendly mindset really works well and where I would love to see this tooling evolves and get more adopted by developers. 

DAN_SHAPPIR: I'm just amused though, that you're now kind of selling us on this VS code extension after getting us all scared about VS code extensions. You know, it's kind of a recursive sort of a thing, but I definitely agree. I mean, if we can get to a point where there's this squiggly line under a piece of code that says, this code is potentially unsecure or unsafe. And in the same way that currently says, this code does not meet our coding standard or unused variable or I don't know, whatever, and in the same sort of way, I have this option that says, fix it. And maybe it's just fixes it alternatively, shows you several possibility of fixes and that's me, that's me choose the appropriate one. I would definitely go for something like that if the quality is good enough. 

LIRAN_TAL: I agree. Yeah. I, I think what we, the challenge is how do we give good information with super small flesh, no, uh, false positives, because I think the more that you have the false positive and that's what happened with, you know had other false positives, people avoid like when they see it, you know, too much time and it's a false positive and they know it, they'll go ahead and ignore it and you know what happens at the end of the day, they'll ignore something that was actually true at the end of the day, right? Which is what we want to avoid. So tooling needs to evolve to basically give you zero false positives. So you would have a really good way to find issues and actually attend to them. 

CHARLES MAX_WOOD: Um, I want to push a little bit here because one thing that I've seen with Linters, I mean, linters is a terrible example, honestly, for this. But some of the other tools like a CI or some of the other tools that I've seen is that people become overly dependent on the tool. Right. And so they kind of assume that the tool gives them a positive false positive, true positive. It doesn't matter. They become dependent on the tool to just tell them everything's okay. And then they just coast. Right. And so they don't they don't put any other practices into place, right? They don't actually go into, Oh, I need to learn code structure. I need to learn design patterns. I need to learn some of the other coding practices that are actually going to improve their code, right? I need to learn how the framework works. I need to learn how the language works. I need to learn basic fundamental architecture and coding structures. Right? So what are, if we keep talking about this term, secure coding, like what are secure coding practices, right? If I were going to become a practitioner of this, right? Not a tool user of this. What does that look like? 

LIRAN_TAL: Yep. Great question. I think there's probably not one answer to that. You know, there's no silver lining kind of like a silver bullet. That's right. That would work for everything. But if you, what I found the most impactful practice and culture to have is to put it in your head really, really deep and thick that input is problematic and you have to handle with inputs. And I'm saying this and it might look obvious to people, of course, user input, you know, I never trust it, but input comes in so many ways, especially in today's cloud native kind of like world. And what do I mean by that is imagine the fact that when you think of input, you think of query parameters and, you know, form input and whatever, but actually user input comes from different areas. Let's say that you're building an app that uploads an image to a server somewhere. Now that goes, this is now cloud native, everything is event-based, that goes into an S3 bucket. And there's a worker thread by another team that does this Node.js worker thing that listens to a queue, handles that S3 bucket and downloads that message, sorry, that picture. And it needs to extract metadata out of it with XSafe or maybe it needs to convert it to specific resizes and whatever. So it does that and that specific team may not understand or like completely realize that this file has been originated by a user and there's so many ways that the user, an end user could have impacted and modify data in the file. Everything starting from the file name to the fact that the exif metadata that I was just seeing a tweet today of like a security research of someone basically inserting JavaScript inside an exif information the events, specific data inside an image, which another application actually used to extract and show this like metadata that you see on like a website, like what is the geolocation and things like that. And they rendered an XSS. So from a file to an XSS. So it's, that's why I'm saying like, if you are conscious to the fact that user input comes from so many ways and you need to treat it correctly, whether that's, you know, escaping it or sanitizing it or validating it to a schema or whatever, that goes a long way. If you could have, if you could master that I'd say as like an awareness thing, one thing that you take from security and you code review everything with those eyes, I'd say that's a pretty big win. 

DAN_SHAPPIR: So code reviews, obviously awesome. And awareness is important, but taking us back to tooling and I'll say why tooling is so important from my perspective. First of all, we have come to rely a lot on tooling, which I think in this case could be a good thing. I mean, we are using Prettier, we are using Slint. We usually abide by their suggestions. So if you can create a tool that gives good suggestions in this context, I think people will use it. So that's a plus. And another thing is, you know, we have so many people coming into the industry, so many juniors, and a lot of them are not getting the ideal mentorship that they might get. And there's no reason to assume that they would be even cognizant of this sort of these sorts of things from the get-go and with nobody around to tell them, tooling is like the best thing that you can get because if it becomes standardized, if you know, when you install VS Code, this is, it's going to recommend that you install this extension, then that could really make a big difference. So this brings me to this question of how good is the tooling, right?

CHARLES MAX_WOOD: Can I chime in on this real quick too, Dan? Cause I agree with you and I'm going to add one more reason. And that is, is that this is a constantly moving target, right? The, all of the vulnerabilities that we're talking about here and Liran pointed this out right with VS code and with all of the different, like all of the different plugins and stuff and all that, they're going to be new plugins. They're going to be new vulnerabilities in the plugins, new vulnerabilities in the new version of VS code. And so yeah. If we, if we are updating our tooling and we get new tooling and we're using the latest tooling, it's going to automatically pick up some of that stuff. So I completely agree with you there and, and it's an easy win. So yeah, how good is the tooling? And I also want to throw in, how do you choose good tooling? 

LIRAN_TAL: Okay. So I would say, I would say a good tooling is one that works with your workflows, whatever they are. So if you are fine, now waiting the weekend for, you know, I've been a SAS code can, a static code analysis can running and going back at it. That that's fine. If you like move at that space as well, that that's okay. If you need something more, you know, in your workflows, like fast giving you all this information, you know, there's tooling for that as well. So whatever makes you productive, whatever actually makes you secure, whatever helps you solve the problem. That's what you need them, you know, not going to say here, you know, use this or the other in terms of like vendors, but I think, you know, we understand in general and thinking the security space and I'm not going to represent the security personas, but I think there's a really great understanding that security tools that were up to a few years ago were built towards the security personas have now realized that what you need to do is build security tools for developers because they are key to fix things and not just keep ignoring them or like work on a backlog of whatever items that need reviewing that's, you know, I'm going to put the line in the sand there so that we are, we don't go into comparing vendors. 

 

Are you ready for core web vitals? Fortunately, Raygun can help. These modern performance metrics play an important role in determining the health of your website, which is why Raygun has baked them directly into their real user monitoring tools. Now you can see your core web vital scores are trending across your entire website in real time and drill into individual pages to focus your efforts on the biggest performance gains. Unlike traditional tools, Raygun surfaces real user data, not synthetic, giving you greater insights and control. Filter your score by timeframe, browser, device, geo-location, whatever matters to you most. And what makes Raygun truly unique is the level of detail they provide so you can take action. Quickly identify and resolve front-end performance issues with full waterfall breakdowns, user session data, instance level diagnostics of every page request, and a whole lot more. Visit raygun.com today and take control of your core web vitals. Plan start from as little as $8 per month. That's raygun.com for your free 14 day trial. 

 

CHARLES MAX_WOOD: That's fair. I guess. 

DAN_SHAPPIR: Yeah, but, but still I'm going to push on this a little bit more. I apologize, Chuck. 

CHARLES MAX_WOOD: I was going to put, no, I was going to push too. So go ahead. 

DAN_SHAPPIR: I'm not asking about a particular vendor. So I'm not asking you to say like this, this product is great, but in this one is not. What I am saying is what's the current state in general of, of the industry. Like, can I even get good tooling? One that would safeguard me to a reasonable extent. 

LIRAN_TAL: So there are a few, I think it depends, like, where do we want to draw? Like what's the scope? Uh, you know, obviously if you look at, you know, third party dependencies, there's like the GitHub advisors and all the other tooling that exists. And I think that's good enough, right? That's for, for an individual developer, maybe maintaining an open source project, you know, those toolings in the NPM, all of those things, they're good enough. I have my own views and you know, I can share some of the data as well in terms of this, of why I think other toolings that have more security depth are more important. But if we look at, I'll say maybe secure coding perspective of the SaaS kind of things here, I don't know of many security, secure coding tools in terms of the SaaS, the static code analysis aspects that are for JavaScript and that are free. And I think that's kind of like the mind shift change. Like if you look at the other vendors, the big players, It's this whole shift that, you know, SNYK has in a sense of like, you know, offering stuff for free for open source and even private repositories. It doesn't exist. That is something that, you know, we've kind of like, you know, rocked the boat. Like if you wanted to buy, you know, you usually buy security and for a lot of money, and I think in that sense, we've made security more accessible to developers, to everyone to use. And there are other tools that you could use that are maybe open source, like, you know, Sonar cube. I've heard people, you know, using that for Java and JavaScript. And it has this find bugs and some security rules that, you know, helps you. So I haven't checked and saying like what's the, uh, the overall state across the ecosystem. I think that would be an interesting, uh, maybe a benchmark of sorts, uh, to say. But I think there's a really great and bright feature, uh, future in terms of what's coming ahead for developer, uh, uh, you know, secure coding, uh, tooling. 

DAN_SHAPPIR: What I'm getting from you, although I, I understand your reluctance of being like too marketing is that. Yeah. So, so I'll just phrase it like this. My understanding is that you're saying that even today there are tools out there, even for free, which it's worthwhile to use. 

LIRAN_TAL: Yes, definitely. Like I, I, I'm not going to call out, I'm not going to recommend you to use ESLint or the plugins around linters to do that. I think I definitely have, I think an objective and like a database, like the perspective on this, like don't use, that's not good enough. Like this was not created for security, for secure coding and security reasons. So don't use plugins for your slint and stuff like that. I think that is not mature enough, but if you use, you know, go for the others that are, you know, they definitely position themselves as a static code analysis for security, that's probably, you know, a good enough practice to start using. 

DAN_SHAPPIR: So what, so if I'm looking for that, oh, sorry Chuck, go for it. 

CHARLES MAX_WOOD: I just want to qualify good enough as I can be confident that it's going to catch the majority of common security issues that are gonna foul me up one way or the other. 

LIRAN_TAL: Probably. I don't, I'm not going to, you know, commit to that. 

CHARLES MAX_WOOD: Yeah, probably. Yeah. No guarantees, but yeah. 

LIRAN_TAL: No guarantees. But then the question is like, how many of those would be false positives? So, you know, it's, it might fun, but that's kind of the problem. How do you need to go back? You know, when you need up to like the left, the signal to, uh, the noise to signal ratio that, you know, you are good with. 

DAN_SHAPPIR: So what you're saying is that the current generation of tools will help you identify security issues, real security issues in your code. But there's a real also risk or probability that they might show you a lot of false positives and create a lot of potential extra work to find the actual issues and not just the... 

LIRAN_TAL: Yeah, yeah, definitely. I think that last part of really fine-tuning the findings and making them, you know low false positives is what we need to invest in so that developers can actually concentrate and focus their time on working with fixing, working to fix real security issues rather than chasing ghosts. So that's what I would like to see in the bright future of developer security tooling. 

DAN_SHAPPIR: And what should I Google search for in order to find such tools? 

LIRAN_TAL: So the term professionally is called SAST, which is Static Application Security Tooling, or I think that's probably, you know, Sanonim with code security or static code analysis or security. 

DAN_SHAPPIR: And beyond tooling, what, what also should I be learning? I mean, where should, if, if I want to understand at least, you know, the basics there, because I think that even the best tools you need to have at least, like, especially given the false positives, you need to have a certain understanding of, you know, what real issues look like where can I find this kind of information? 

LIRAN_TAL: So, PortSweager is, they have a really good security content, like information. 

CHARLES MAX_WOOD: I'm sorry, say that again. 

LIRAN_TAL: That's PortSweager. They've been, I think they're generally kind of like being a good content creation around that. If you go, you know, they have some examples of what things are, and I think they have, they are doing a really, you know, decent job in terms of explaining you know, technical things and technical firms in a good way. Like they have visuals and stuff like that. And it's, it's pretty good content. 

CHARLES MAX_WOOD: I'm in the right place where it says burp suite on their website. 

LIRAN_TAL: Yeah, possible. 

CHARLES MAX_WOOD: I love these names. 

LIRAN_TAL: The burp suite is a, is a, we want to go into that, but it's a middleman, not proxy. And anyhow, I think that's a good one. If you, I think we're doing a good job at least the sneak blog to create, curate information. So like we have this you know, five coding injection conventions that, you know, you, you should follow slash, you know, be careful of. So there's like a, you know, a bunch of security best practices. I felt like trying to also work with other people in the, in the community and help with like creating awareness and building them and, you know, making sure that's available for, for developers. And I would say lastly, I'm going to connect this to the, you know, the awareness and user input, but you know, when you are working with, you know, working with data, you know, one good practice as well to to do to follow is understanding how data flows is pretty critical to understanding what is the impact. I'll put two practical examples around this and I'll connect this to SQL injection, which AJ was raising in the beginning, and what's the impact. So in the last week, I've been spending some time doing a bit of security research and writing vulnerable code so that I can detect it with this SAS tooling that we have. And I realized some interesting bad practices that you could actually do that are not very obvious. For example, let's say you are working with a MongoDB database and imagine you have an API route that's accepting input, for example, the profile information. So you would do const profile equals request.body.profile, something like that. You get a JSON request, you parse the, you know, the profile information as an object out of it and fit it into something. Now to that specific example. There are two different vulnerabilities that I've seen happening this week. One of them is that it could actually be a NoSQL injection sync. Why? Because MongoDB, it usually works with structured data like JSON. So if you've ever seen a MongoDB API, kind of like the SDK API of how that works is you do user.find, for example, and you feed it, you know, JSONs and like objects, right? And if you get that object from the user directly and you don't do anything, you know, to sanitize it, you just kind of like pass it into the, into, uh, into that user that's fine query. You will not have the regular SQL injection problem where you concatenate strings because it's an object. It's not a string. You don't concatenate it with anything. So it looks, you know, innocent to begin with. It looks like, you know, there's nothing wrong except specifically with MongoDB. Mongo has these operators where you could do, you know, dollar rejects in your object and then something. And what happens if I, as a user in my profile object, I now send you, you know, $regex equals, you know, nothing else or anything or something like that. Then I've essentially created a no SQL injection that's modified a whole query. And this can be a find or an update or anything else. That's one example of how SQL injection, no SQL injection vulnerabilities just happen just by the fact that we're passing data around. And sometimes if you look at understanding the code structure and the code architecture, sometimes people might do, you know, that some, you know, the, the snippets of this vulnerable code might be five lines of code. But if you look at really, you know, large teams, you know, developed applications, there's too many kind of like layers of obstruction. It goes from a controller to a service to a repository to an ORM to, you know, it goes through different levels. Usually different developers are kind of like working there. So you kind of like might assume or maybe at one point in time you've put some validation, but at a little bit further in time, someone went in, did some refactoring, and now that validation is gone, or that validation logic is working differently, without that person understanding that it came from user input. Maybe if they understand it came from user input, they did not understand that someone can add data, which they don't need to sanitize the data that exists, but they can add new properties to the object that now effectively change it. And that's the problem. We do not always have that grasp that, you know, those kinds of modifications happening to our code as it flows through the entire application stack. That was a, that was a mouthful. I know it was taking you towards several code flows, but I think I have more examples of how this things happen. And I think, you know, understanding how code flows is super important, but it's also super hard. That's why we need static code analysis tools. 

DAN_SHAPPIR: Yeah. Well, basically the thing that we always need to remember is that SQL injection is just a special case of a general problem. It's the moment you put instructions inside a string, you're kind of screwed. And it might be SQL, it might be XSL, it might be JavaScript and HTML, and now it could be no SQL or any other type of domain-specific language. Basically, it's something that we do we do it because it's easy to do it. We do it because we need to pass these instructions around across the network and stuff like that. And it's going to be a vulnerability. 

LIRAN_TAL: True. And that exact same example of taking an object from the request and pushing it onto some function could actually also be compromising you in terms of a prototype pollution vulnerabilities, which I know people have kind of like deemed them as false positives and ignores and what's the actual impact. I have a few examples of, I've seen one of them this week. I've actually tweeted about it and like made a whole, like, well, let's find this thing together where, you know, we inject an object into a view and the rendering engine of the view templates. Like for example, EJS or handlebars or something else, it's actually, you know, rendering it and the impact of that, of that exact JSON, because I can control it and that's what's been passed to the view is being interpolated and now it can access actually several layers of the prototype chains of object in JavaScript and that leads to prototype pollutions. 

CHARLES MAX_WOOD: Yeah, one other thing that occurred to me too was that so we have on the... So JavaScript runs kind of everywhere, right? And so we have sort of these semi-trusted... 

LIRAN_TAL: I don't know if that's good or bad. I don't know. You were like saying that and it's like, uh, is it good? Is it bad? 

CHARLES MAX_WOOD: Yeah, well, it depends, right? And it depends on how your security is compromised. So we kind of have these semi-trusted API consumption engines that we usually use for rendering and communicating on web pages. It all functions as a web application. But then we have more highly trusted things that use API keys or some forms of authentication. And we run mobile apps or desktop apps or set top like Amazon Firestick, Apple TV apps that are all written in JavaScript and things like that, right? And we fully authenticate them and we just kind of trust the API information coming in from them. And so if those systems are compromised, we may be swallowing whole information coming in that we may or may not even be taking as we may be trusting our application to sanitize it. And if that application is compromised on its build process or anything like that, I mean, any of that could be coming in as well. It just, it just occurs to me. I mean, any part of this, you know, you're talking about this workflow. Any part of that workflow is compromised and the whole system is compromised. 

DAN_SHAPPIR: I know that we're approaching the end of the show, but maybe it still might be worthwhile for the, for listeners. If you gave a really brief description of what a prototype pollution actually is. You, you mentioned it in your description before. 

CHARLES MAX_WOOD: Yeah. 

LIRAN_TAL: Yeah, sure. So you need to have some basic understanding, I guess, in JavaScript to understand that there's a prototype chain and the way that objects are built. And objects are usually kind of like inherited from that, you know, bigger basic object entity. And what happens is if someone is able to, well, I mean, even you could open the dev tools as you know, like maybe listen to this podcast on, on your browser or something, if you open dev tools and you do the object curly braces and you do dot underscore underscore proto underscore underscore and dot something else, add an object to it. And then you do a console log for a new object curly brace with that key, you know, that, uh, that property that you added to it, you will find that it's there. And the reason to that is because that data is inherited. And like when JavaScript looks at, you know, a property and it doesn't exist on the specific object, it goes up the chain and tries to find them. So it's, you know, I think when you think about it like that, and you have that kind of like, you know, a visual in your head, you now understand that if someone is able to give you, you know, an object structure, any sort of object structure or maybe you create an object structure out of data, insecurely, then someone is able to now, this is what we call prototype pollution, they're able to pollute, basically to add or change specific properties of the base object. And usually where we find it is, when we began finding those incidents of prototype pollution, we found them in utility libraries like Lodash and others, because people were using those to merge objects, merge one object with another, give it the query, the function parameter that says, you know, do a deep merge. That deep merge that does, you know, recursive merging of data was insecure. So if I had left, you know, a string that says, you know, underscore, underscore, proto, underscore, underscore, it would actually, you know, now flow into the real object that exists on the base object. And it will, it's basically similar to like doing an object, that constructor, that constructor and doing something else. So all of those are like attack vectors that someone can actually pollute or add modified data on the base object. And it can be anything from, you know, you could think about someone adding data to it. Like maybe the base object has isAdmin and somewhere else in the code, you know, the backend or whatever, they are checking that, you know, there's like an isAdmin property on it. When it doesn't exist on the actual user, now the prototype pollution plays in because what JavaScript will do is it will look on the base object and that one has is Admin. So that's kind of like the classic example of like, how a prototype pollution flows, but it can have devastating impact on running applications because I can actually pollute the base object so that toString as a function that exists on the base object would not be an actual function, but something else. And then when you run it, you get a denial of service because you're trying to invoke a function for something that I've now changed and it's not a function anymore. To String is now some variable that returns true. So that's kind of like how prototype pollution flows in. And the cases that we've seen it that you should be careful for is all those JSON merges slash when you are creating potentially insecure structures of JSON from input, you are maybe creating them and merging them in an incorrect way. 

CHARLES MAX_WOOD: Interesting. I hadn't thought of coming at it that way before. 

LIRAN_TAL: I'm still very intrigued when I see prototype solutions in different ways as well. It's a, it's not an easy concept, I think, to grasp because it may have different impact in the way that it actually flows in an application, but it's always interesting to see all of... There are many libraries that has this from type ORM, which is an ORM, like an SQL library, and it has a prototype pollution. I actually have a really working demo of that. I'll give you the links afterwards that you could look into it and understand how maybe prototype pollution actually impacts a vulnerability in a third party dependency. The coder is insecure and you could actually work from that prototype pollution to create an SQL injection so that the whole kind of like a tag virtual in play. 

DAN_SHAPPIR: I think that another way to look at it or to think about it is simply the fact that JavaScript is intentionally malleable. The whole thing about prototypes was created from the get-go to enable the language to be retrofitted with new functionality and the same mechanism that enables us to add missing language features to support all browsers can be used to modify existing features for nefarious purposes. So I could literally go in and modify the behavior of, like you said, of toString or concat or whatever, and wreak havoc on the application. And again, it's because third-party code and first-party code within the browser or within Node run with the exact same privileges. 

LIRAN_TAL: Right. Perhaps adding here maybe a mitigation that we've kind of like discussed as an ecosystem, as a way to kind of like work around this is you could freeze objects. So you could have an object and say object freeze and freeze specific methods or properties on the object and say to basically tell the runtime, I do not allow anyone to try and modify this. And that's one way of treating those, what we call usually primordials, the objects, the array, the basic objects from being altered. So, prototype pollution will not be a way of doing that. Realistically, it's like you said, like JavaScript is malleable. So like I could go ahead now, create an object, freeze it, send it over to React, which will pass it as props, props, props, and somewhere down the lines, which will break the application. Why? Because I've basically did that and there's some library that expects different things. So it's practical way, not really useful way of doing it. 

CHARLES MAX_WOOD: Awesome. Well, we need to get to PIX actually, I have a hard stop. So let's go ahead and do picks. But this has been really, really fascinating. Really enjoyed it. 

 

I remember working my tail off to become a senior developer. I read every book I could get my hands on. I went to any conference I could and watched the videos about the things that I thought I needed to learn. And eventually I got that senior developer job. And then I realized that the rest of my career looked just like where I was now. I mean, where was the rush I got from learning? What was I supposed to do to keep growing? And then I found it I got the chance to mentor some developers. I started a podcast and helped many more developers. I did screencasts and helped even more developers. I kind of became a dev hero. And now I want to help you become one too. And if you're looking forward to something more than doing the same thing at a different job three years from now, then join the dev heroes accelerator. I'll walk you through the process of building and growing a following and finding people that you can uniquely help as you build the next stage of your career. You can learn more at devherosexcelerator.com. 

 

CHARLES MAX_WOOD: I'm actually going to start with picks and then I'm going to let the rest of the panel finish the show because I actually have to go to a coaching call. So I have probably been picking who not how like every week for the last few weeks. I am still really, really enjoying that book. So I'm going to just shout it out again because it is really making me think. I have been reading other books. What I do, my process, I'll just kind of throw this out there is so I get up in the morning now at like 4 a.m. and I read my scriptures and then I read another book and then I read a little bit of who not how and then I'll go work out. And so I go work out at five and then I come back and I do usually two hours of focused time because I don't have to drive my kids to school anymore. And then I'll do some family time and then I'll get to work. And so the other books that I've been reading or listening to more are I'm just going to throw them out there. So one of them is as a man thinketh. It's an older book. It's pretty good. It's a little bit dense, like information wise, like a lot of other books, they'll kind of mix in like, hey, here's a story. Here's an example. And so they kind of illustrate it. And he really just packs in the information and doesn't give you as much of the other stuff. But it is really, really good stuff. So I've really been enjoying or have I enjoyed reading that one. And then I'm also going to pick Discourse, which is forum software. And I've moved a few of the show's prep documents over to it, as opposed to Google Docs. And the guests and hosts that have been using it so far have really liked it much more than Google Docs as a way of being able to collaborate on the just being able to prep. So the guests have been able to just drop in and say, Hey, here's some of the things I think you ought to ask. Here's some of the other topics I'd like to cover. So some of it has been interesting because it's been, oh, well, we're gonna change the focus of the episode a little bit to this, and then we'll have you back on to talk about this other topic, right? And just stuff like that. And so it's been really kind of fun to dive in and see how this is all working out. So it's just been this migration process over to that. And then, but who knows how has also been helping me just focus on getting these processes together for the shows. So I'm gonna I'll pick all of that. And then my other pick is monday.com. And I think I've picked that before too, but that's the task process system that we use for tracking all of the podcasts and things like that. And it's been tremendous. So been happy with that. And there was another book I was going to pick and I can't think of what it was. So unless I can find it in the next about two seconds, I'm going to let Dan go. Oh, cyber psych goes cybernetics is the other book, which kind of goes along with as a man think of it's a little bit more concrete in its approach. So the one is more conceptual and the other one is a little bit more concrete in just kind of how you visualize and think about what you want so that you can manifest it. So yeah, those are my picks. Dan, why don't you go ahead and go, I'll type these in and then yeah, if you guys can wrap up and then get us stuff for the show notes, that'd be great. 

DAN_SHAPPIR: Thanks Chuck. So yeah, I also need to leave a little bit early. So I asked to go after Chuck. And I actually have two picks which are actually both of them related to this podcast in a way. So one thing is a while back, it was episode four four two, we had the Denny Thompson on the show and, and this was before he became like a real rock star in the industry. I think he had, uh, like something like 10,000 followers back then compared to the over a hundred thousand followers that he has now, he's really come amazingly far in an incredible short period of time. It was an awesome episode. I think it's one of our most popular ones, but it turns out that it had, and it still has a positive impact beyond its initial impact. It turns out that a lot of people are listening, still listening to this episode and finding a lot of inspiration in it. And recently I came across this story about this guy, Sam Seigmor, who actually turned out that he was kind of like at a crossroads in his life, thinking about where to go next in his career. He wasn't in tech at all. And then he heard this episode with Danny, and that kind of made up his mind to try going to tech. And nine months later, he's working in tech and making a living. And this is just an awesome story. And it's so great and so inspirational that we're actually going to have him on the show as well, hopefully, I think like in a month or so. And it's a really interesting story. And I'm really happy about this kind of situation where we have this sort of a gift that keeps on giving. So that's one pick that I have. And the other pick that I have is also about somebody who was on our show. And that's Alex Russell. He was on episode 439. His episode was interestingly titled, more jabber about less JavaScript. Alex is really a big proponent of the, of the open web and the success of the web. And talking about how we are building using the web to build the front ends that don't scale in the sense that they're too heavy for many of our potential users and intended audience. We are pushing down, we were talking about today in this episode about pushing down so much JavaScript, you know, in the context of NPM and all the security challenges that it can bring about but it also has all these challenges around simply building interfaces that are too heavy for the devices that a lot of our users are using. So that comes up very often in Alex's talks, and he's recently written a really interesting article about it titled the Mobile Performance Inequality Gap for 2021, in which he shows that while on the one hand we're moving forward with the types of devices that we have. Like the newest iPhones are often faster than our laptops are at running JavaScript, for example. The end result of that is that we're actually potentially widening the gap with a lot of our users. So if we write, developers often have the latest and greatest devices. And if we write our code, so that it works well on our devices, it might be that we're leaving behind something like 80% of the world's users. Now, the reason that I'm bringing Alex up is that after 12 years at Google, Alex has actually recently announced that he's leaving Google. I don't know where he plans to go next, but I really hope that wherever he goes, he remains involved in the success of the open web. He's been involved in a lot of projects around that and we all owe him a debt of gratitude for it And those are my picks for today so thank you Liran for coming on our show and I have to drop off as well. So bye everybody. 

LIRAN_TAL: Bye Dan Thank you. Am I going next? 

AJ_O’NEAL: If you want to typically we have the the guests go last but you can jump ahead I don't know.

LIRAN_TAL:  Go ahead. Go ahead AJ. 

AJ_O’NEAL: Okay, I Will try to make mine long today because sometimes I say that I'm going to try to make it short and then I make it long. So I figured maybe I'll just tell the truth this time. 

LIRAN_TAL: Go for it. 

AJ_O’NEAL: All right. So the first thing I'm going to pick because it came to my mind very early on in our discussion is the OMG USB. And this guy's Twitter account will probably link to his blog and his products and other stuff. But basically you can do really creepy stuff with electronics these days in terms of spying on people and microchips have become so small and so powerful that you can literally insert spy hardware inside of a USB cable and all sorts of other things too. And so I think this was the one I actually didn't double check. I just did a quick Google search for what I thought it was and the name sounded familiar. So whatever. But if I remember correctly, this was the Twitter channel in which I saw something about how they would replace half a battery with a, from an iPhone with a GPS tracker and, and stuff like that or at least that that discussion led me here. Anyway, it's just it's weird. It's weird what you can do with hardware. It's crazy. Also, not a super related topic, but kind of sorta related. So we think of North Korea in America is mostly a joke. And by that, I mean the average person, I think, thinks of North Korea as a joke, because it's kind of a meme and you hear about it and nobody has any connections to it because well, it turns out that you probably can't. And I did not realize there's an interview I started watching with a girl from North Korea, Korea that details her experience. And it sounds somewhat like if you were to mix The Dispossessed, which is a book that hardly anybody knows, but it's where the term Ansible comes from that then went into Ender's Game. So it's kind of dystopian novel. And then The Hunger Games, if you could mix those two together. That's what North Korea is like from her description. She has a book called In Order to Live. I haven't started listening to it yet, but I just got it and I will because I'm very interested to know. But basically, I mean, we live such pampered lives and I didn't realize the reality of dictators and people who believe that they're creating the perfect society at all costs, no matter how many people have to starve in order to create that perfect society and such. So I'm picking that because I think it might be a good thing for a lot of us pampered people to be a little more aware of. And then beyond that, I've been working on an authentication library. Well, actually, it's not really that I've been working on a library as much as I've been working on some authentication stuff for two different companies. And I am live streaming as I create it. So by the time that this airs, I'll probably be done with it. But so far there are five different parts and they range between half an hour and two and a half hours each. And so if you want to watch someone create an off library and talk about some of the securities concerns and whatnot as I go along, I'm just talking out loud as I go, it's not structured. I didn't know what I was gonna do ahead of time. I do a little bit of code and then I go figure out a little bit more of the requirements and I do a little bit more of the code and it's just real actual live work. And then the usual, if you want to follow me on beyond code, Facebook, YouTube, and Twitter, I've got the links to that. And, uh, typically post the more structured videos on the beyond code channel and my more live unstructured stuff is, is on my cool age 86 channel. But that's that Steve. 

STEVE_EDWARDS: Okeydoke. Well, I'll, uh, start with a non dad joke and then get to the dad jokes. Cause I know that's what everybody listens to this entire podcast for us. Do you hear my dad jokes came across a. GitHub repo as a view developer, this is the kind of stuff that's interesting. And it looks like a good starter kit for playing with view three, something I haven't been able to do too much as I've been buried in a very large project that's still in view two, but it's called the view three starter kit, view three starter by Coutia software company. Looks like it has a lot of stuff built into it already. So take that for what it's worth. I'll put the link in the show notes. And then for my jokes for the day.

 

You know, in the past, I've talked a lot about, you know, my job history, like, uh, getting fired from the bank. Cause the lady came in and asked to check her balance and I pushed her over. This one's a little different in that, uh, I turned down an offer to invest in a company that made crystal balls, but I just couldn't see a future in it. And then, uh, talking about, you know, my mom and she used to say, you know, the only way to a man's heart is through his stomach. She was a very lovely woman, man. She was a terrible surgeon. So anyway, I'll put links to, uh, both of those in the show notes and for everybody listening, I'm watching two people really laughing, but they're muted. So you can't hear them laughing. So you're just going to have to take my word for it. So those are my picks. 

AJ_O’NEAL: It's true. I was laughing. I actually did laugh. 

LIRAN_TAL: Say you're respecting you with muting in so we don't, uh, interrupt everyone else. 

STEVE_EDWARDS: All right. So I think that's all we got. Right, AJ. 

AJ_O’NEAL: Yeah. We w but they around what, what are your, oh, I thought it went for some reason. 

STEVE_EDWARDS: I'm sorry. And I'll always kind of make mine short.

LIRAN_TAL: bit geeky on the cyber side of things, just like follow ups. I'll start with working out, which is like just an advice I want to give everyone else, just staying healthy in some way of, uh, this is definitely something that I've in the past year of like, try to emphasize for myself. I think I'm kind of like burning out in a minute from work, but, uh, at least I try to stay healthy. So please, you know, think about yourselves and, uh, you know, take care of yourselves. This is to begin with. My two picks would be a book and a podcast. A book is you know, if you are into cyber security, but are interested to kind of like understand what it was like when things were just starting out in terms of hacking groups from like the eighties and all through the nineties, there's the discrete book created, written by Joseph Mann called cult of the dead cow, which is a name of a hacking group back then. So this was all like modems and BBSs and things like that, and how everything connected, everyone connected, how conferences, security conferences were run, how actually some of the most active security members back then were part of government agencies today and security companies. Super interesting book, kind of like a go through the life, the livelihood of hacking groups back then. This is Cult of the Dead Cow. The other one is a podcast, which is pretty popular. It's called Darknet Diaries, but if you haven't heard about it, this person basically curates stories, supposedly what seems to be a real, um, you know, real information, real stories. Some people kind of like confess to, you know, to him, and then he creates a podcast out of it, or that person reads into government records, uh, from courts about data breaches and like explains how the LinkedIn data breach happened in, you know, 2012, 2012 and things like that. So super interesting podcast and book completely recommend if you have some time on the background to do this. 

STEVE_EDWARDS: That's so they're on speaking of cows, you know, to call a cow with no legs. 

LIRAN_TAL: I don't know. 

STEVE_EDWARDS: Ground beef. And then what you call a cow with two legs, lean beef, you know, 

LIRAN_TAL: how do you know what sound the cow makes? 

STEVE_EDWARDS: I would say moo would be too obvious. So I don't know what it's. 

LIRAN_TAL: If my, my nose counseling was counseling that, but that's the sound of when you put it on the on the griller. Oh my god, I'm so sorry for all the vegan. I'm getting converted to being a vegan with all the healthy stuff. So I'm so sorry about that. 

STEVE_EDWARDS: But that was a sorry. That's awesome. My version of PETA is people eating tasty animals. So I appreciate that one. 

LIRAN_TAL: Cool. Oh, folks, it was amazing. 

AJ_O’NEAL: Yeah, it's good to have you on. And by the way, using path.join, So I did test that because I was scared because I've written code where I was expecting dots. But I think you mean URL resolving. You have to worry about the percent two E not path resolving or does windows. Where did you see that percent two E turns into a dot?

LIRAN_TAL:  I guess it depends whether you are encoding it or not, because if you are getting sent percent two E, you may be just getting it as is and fitting it somewhere else, maybe to another URL or something else. So I don't know if that joint specifically handles that or not, but usually that's a sync maybe sometimes before it. 

AJ_O’NEAL: Okay. Yeah. I see what you're saying, but yeah, if somebody is checking paths, when they go to the file system, they will not be vulnerable to that because I was thinking. Yeah. I was I was, I was thinking the O S level at the O S level, the path.join was doing that. So you scared me. You scared me really bad, 

LIRAN_TAL: but send me over your code. I'll look at it. Let's see what we find. Let's scan it with, with, with SNYK code. Let's see what we find then. 

AJ_O’NEAL: Okay. Well, so yeah, where was the link to that? Is that down in here? 

LIRAN_TAL: I haven't added it, but let's meet it now. 

AJ_O’NEAL: Yeah. Add that link because I want to check that out. 

LIRAN_TAL: And ping me if you find something or, uh, I guess that code is not actually a public rights, but, uh happy to look at some snippets if you find them. All right. There we go. 

AJ_O’NEAL: Well, with, with that, snyk.io slash product slash snyk.io. code. I will be checking this out. Thank you very much. And with that to all of our listeners who can't see me making wild hand gestures and emphasizing emphatically as I speak. Adios 

STEVE_EDWARDS: Adios 

 

Bandwidth for this segment is provided by cash fly the world's fastest CDN deliver your content fast with cash fly visit C A C H E F L Y.com to learn more.