 All right. Welcome back. So now welcome to our Q&A with our board of experts, all in AppSec from a very varied field of AppSec. So we have lots of questions. Thank you guys. So how about we start with a broad one? And I think it's an interesting question. What do you guys think is an underexplored part of AppSec? So if you had infinite time or what do you think would be a field that's not, that doesn't have the visible teacher? So the question is for all of you. So feel free to jump in. I can jump in here. So in my opinion, an area of AppSec which is underexplored is the entire infrastructure that goes around with deploying a website. All the times during a penetration test, you know, a company will go in and they'll take a look at specifically the code, you know, or they'll take a look at specifically the APIs or the, you know, the front-end code. But often the entire, you know, infrastructure and everything that goes around deploying the application goes untested. A lot of times, you know, how often do people actually look at the build process, you know, and the actual deployment of that. And I think that's a very, a very underrated area, not only because it's often vulnerable since people aren't really on the lookout for that, you know, people are just looking for an RC in code. But it's also often very impactful, right? If you can take over a build process, or if you can, you know, get before the, get somewhere before the user actually gets to the website or whatever in your infrastructure, it often results in a complete compromise. You know, there's been many recent hacks, a whirlwind hack, I believe was an issue in their build process. And so I think that's an underrated area of security. It's not very well understood. It's not, it's not often looked at, and it often can have devastating effects. So I'd say infrastructure surrounding a website and an app sec is the biggest area, in my opinion. I can add in addition to that, if I may. This is a great point. And I think one of the problems that we have today in our field is when, you know, we're looking at pen tests that are typically scoped, we're either focusing on a specific application that may be a line of products. And same thing with the red team, which is kind of an unscoped engagement. And the problem with the red team, in my opinion, and it kind of connects to this problem is that once you hire a company to try and penetrate into whether it's an application like, and to the infrastructure, they're going to find one loophole and go with it. But maybe there's more. So it's a kind of a one-time engagement that you do maybe annual or bi-annually, but you don't really test the whole thing. Once something is found, then they're going to go that route. And I think in terms of coverage, you almost get a false sense of security by doing that because you haven't explored everything that's possible. You may be patched up whole, but you don't know about other things. And I think it connects to this exact point in how we actually do application testing and find vulnerabilities in general. All right. Anybody else want to jump in? I can add into this. Obviously, I don't think this is even arguable. This is definitely one of the most important and overlooked area. My perspective is in a very short time, there have been just so many different ways of coding up applications in terms of different technologies, languages, frameworks, that it's hard for security to keep up with all those new and neat technologies. And to top it off from the infrastructure point of view, I don't think we do a very brilliant job as an industry from a detection perspective. As much as attention we have given over years to the actual code of it. So there is definitely a lot of things which falls off crack in that department. Great. Well, thank you very much. We have another question for this one, I think would be for Doliv. There's been lots of requests for a link toward your GitHub, your slides. I think there's a... So do you have any plans on sharing these slides? Yeah, absolutely. So the then vulnerable GraphQL application link is already in Discord, and I'll share the slides right after we're done here. Oh, great. Thank you very much. There is a question regarding both the repo jacking and the electron. So the question is, is the JavaScript ecosystem inherently less secure or just more visible? And the question is both for you and... Well, for everybody, in fact. Yeah, that's a great question. So in terms of repo jacking, effectively JavaScript is one of the languages which I found to be more impacted. Now there's always a trade-off and kind of a double-sided coin with usability and security, right? And that applies to the end user, obviously, like very long, complex passwords. No one likes them, but they're more secure. But it also applies to the developer. And you can see that a lot in different languages and how languages implement things. So for example, JavaScript has NPM, which is their package manager, and it's really convenient. It's super easy to push up to NPM, it's super easy to draw down, and so people will just download a library in literally 15 seconds and use it. And so that usability also does add a certain level of... You know, it's easier to mess up, if I'll say. Whether the actual language itself is less secure, I would say no. I'd say, I mean, the language is just secure as the people using it. But the fact that it is easier to use in certain aspects can make it to trip up and have those security mishaps. So I think it is important to kind of differentiate that between those two aspects. JavaScript itself is one of the only languages that people are trust enough to basically run code from websites. If you think like a website is someone else who made this code and you're running on your computer, and that's in JavaScript, and that's very secure. Very sandbox. Well, okay, I'm very secure. That's arguable. But at least, I would even dream of having a Python code run from a website arbitrarily or C or anything. So it does have those security measures, but it is always up to the developer to make sure... So the ecosystem of JavaScript is less secure inherently. I'd say because some things are easier, it can make more mistakes. But if you're sharp and you kind of know what you're doing and you're aware of security as you're developing, it's at no point less secure and you can, in fact, make it very secure. I'll add that because the JavaScript ecosystem is so visible and such a target, everyone knows that it's insecure and wants to find out the new ways that it's insecure. There are a lot of eyes there and there are a lot of resources. If you don't read anything, you're at a bad time, but if you can learn all the problems that people have had before you and all the solutions they've had to the problems, the tooling is really mature, the documentation is mature. And when I compare that to most popular NPM packages, and yes, I could do, for instance, trust them more than the modular crates.io packages simply because they're that much more popular and I've had that many more people thinking about ways to break them and ways to secure them. So the visibility in some ways is actually a good thing. It gives you the resources to do something about it. Good. A question for all of you folks. This one is about, well, there's certain that I'm merging in one. How do you break into AppSec? So you're all experts in your field. How do you work into AppSec? And same line of thinking. How do you pivot from being a software engineer to an application or offensive security? So how do you talk to us about the work you're from? Yeah, that's an open-ended question, so please go ahead. Yeah, I mean, I can talk about my personal experience and how I got into AppSec. So I used to be a web developer or an institutional web developer and then got into security because it was fun and interesting and became my passion. And in my opinion, if you're looking to get into AppSec and you're coming from nowhere, I would say start by taking a look at web development. Start taking a look at these frameworks. Look into Tron, look into GraphQL, look into all these different frameworks coming and literally build a website. Like literally go out there, make whatever you want and start the website. And as you do, slowly understanding AppSec for what it is and eventually you can pivot to more security-minded where you can go back to your old projects and be like, oh, I really messed this up because I know I've definitely done that many times. So I'd say if you're just starting out, start by going a web development route and keeping in mind security and then you can always go there. And if you're looking to pivot from start development to AppSec, I think that's a lot easier. I think if you already have that experience as a web developer, moving to AppSec is just kind of a change in thinking. And instead of thinking, how do I make this code do what I want it to do, you try to think, how do I make this code do what I don't want it to do. So a lot of Q&A experience helps there as well. You can look at your code and try to break it. And the question I think also includes whether you can go back and that's complete up to you. If you keep up your development skills and you continue working project on the side, you can definitely go back and you'll be a great software engineer once you've done the AppSec side since you know everything that can go wrong. So that's my personal path I took and the path I would recommend for someone going in. I can add to that. So my background is like DevOps or system engineering and AppSec is just one part of what I do. But I 100% agree with what you just said. And I think one thing that we're not doing or we started doing in the industry is skip certain stages. I think we got to a point where pentesting is the go to and we don't spend enough time on basics. We don't spend enough time on building. And I think as security consultants and you know, if a company is a security person, you're going to work with people at the end of the day. And you need to show compassion when it comes to fixing things. Everybody likes to to tell them, oh, your app is broken. And I think we need to be learn how to appreciate building web applications. It's easy to break things. It's really hard to build resilient well. And I think if you don't go that route of building something, specifically AppSec, but not only AppSec, you know, pentesting, learn networks and stuff. So if you don't go through that route of building things, you will not be able to appreciate how hard it is to actually come up with resilience, cure applications. And I think you will only get better if you buy learning how to build so that you can actually learn how to break it. So I think as an industry, we should spend more on the blue side first and then maybe red side after. Thanks. Continue this conversation ahead. I also started my career enterprise web developer and I was given a pentesting report by one of the companies that go fix all the SQL injections and cross-site scripting bugs and then I lost service kind of attacks. And that's when I got an appreciation how hard it is to actually think that way. So yes, just add to both ends. Definitely most of the good companies these days have a security program, start taking more interest, see how you can help fixing things. If even I'm a huge fan of open source, go on GitHub, look for security bugs, look at how you can help contribute there. That's a great starting point. It will help you in that defensive direction. Thanks. Especially breaking into crypto is, I wouldn't say one of the, not the hardest, but it's an intimidating field. Like there's lots of math, there's lots of expectations. So any suggestions to break into crypto especially? Breaking crypto or getting to no crypto because I think I'm more in the side of getting to know it better and I don't, I mean to get it to know better, you have to understand how to break it either, how to get into that. There are a lot of good resources. I personally learned a lot from the posted by a Matasano company called CryptoPals. It really gets you started from the very basics of zeros and ones and exhorting and takes you all the way to how to break an elliptical crypto. Yeah, if you can keep up with that, I think that's a great. As a FYI, I am posting the changes in the link right now to CryptoPals. So that's cool. Thanks. Anything else, Mitch? About getting into AppSec? Well, in my case, I was lucky enough to join a company that had a culture of AppSec throughout. I didn't join on the security team. In fact, I didn't even join originally as a developer. I joined as a technical writer and learned through osmosis immersion and discussions with people who were very passionate and knowledgeable. And I don't even know that there was a point when it happened, when suddenly it was my responsibility to also ensure AppSec. But the thing is, it was everyone's responsibility. Like every junior developer who joins, that's what we're interested in as much as their ability to write performance programs. It's to write secure programs and understand what that means. So I think just joining a culture of people, whether it's a company or an open source project that already cares a lot about this and makes it one of their values, is going to teach you the ropes of AppSec and why you should care about it and what to do about it. Thank you. Now, let's do a fast round of GraphQL, because we have a few GraphQL questions. So let's do like the four of them in a row. So first question. Would you recommend sticking with a REST API due to the less than ideal mitigation tooling that exists for GraphQL right now? That's a great question. And there's no one answer to this. I think that when there's advantages in using GraphQL, if you're aware of the GraphQL challenges, I don't see a reason why you wouldn't want to go that route. If you have the resources to invest in actually hardening GraphQL, you're not going to get the security out of the rocks, unfortunately. And obviously REST is a more battle-tested infrastructure, like we're more used to working with it, so more eyes on REST API. But I think if you do enough research on what could go wrong in GraphQL, we're starting to get to a point where we have enough resources and security eyes on it. I don't see a reason why you wouldn't want to at least try and harden that and try to see how that works for you. Thanks. Next question. Would you say that DLF service flaws are the biggest threat to GraphQL implementation at the moment? I'm a little bit torn. I think that DLF service is a very common thing. There's a few ways you can bring down GraphQL. But the mitigation against most of us is fairly trivial. But again, it's vulnerable to all REST top 10 and beyond the top 10, just like REST API. It's just that I think GraphQL is more prone to now of service attacks, I think. Thanks. If I can jump in here also, Laurent. I've also noticed in my experience, the other huge thing that you see in GraphQL that's messed up is authorization. Authentication, you can kind of do like in front of the endpoint, but that authorization saying, oh, you're allowed to view this field and this type, but not this one and stuff. That's another huge one that I often see missed. So that's just from my personal experience. You're the expert. That's why you're on a panel. So thank you for jumping in. Now, question for Mitch. Are platforms, sorry, my stomach here, are platforms for cross-platform applications other than Electron any more secure than, I guess, Electron? Well, I mean, I don't know. I haven't used all of them. But one thing that I found interesting when we were starting this project and sort of doing a review of the options is that a lot of cross-platform use SDKs kind of promised the world. But when you actually went to their documentation, like, there wasn't much for security. And maybe they in fact were more secure, but it was hard to do that sort of initial threat modeling and be confident that we could rely on that. So with web apps, there was a ton of information. We knew the risks going in. And with Electron, again, there was additional documentation and a lot of close presentations that we could rely on to see a sort of picture in our heads of what the challenges were. And that's one thing I'd want to see from any development framework. Like, don't just tell me it's secure or insecure. Tell me what the risks are and how they're mitigated and what can't be mitigated. And then I'll feel much more confident regardless of the overall sort of perception of it being secure or insecure. Thanks. And I guess we're a little bit early for our very last question today. I'm not sure if it's more of a suggestion. Take your time because this one's for Indiana. To detect the these type of hijackings, could they compare the emails of previous commits to make to detect these past these types of attacks? So that's a great idea. So the idea is basically take a look at the commit emails that were previously committed when the repository was under legitimate user and then potentially try to catch a repo jacking attempt by seeing new commits under new user email. So that could potentially work. A couple of issues here is that a lot of or some repositories don't only have one user who's committing to them. So you might have 10 different users who's committing to them. And so it would be hard to differentiate who is a legitimate user and who's actually a malicious user just by looking at commit emails. So it could potentially kind of be a mitigating factor. You know, if you have something that kind of pops up like, hey, there's a new user who just committed to this repository, then that could help. But unfortunately, I think it'd be hard to manage to get that to work every time. Great. Do you have any parting words, any advice or anything you would like all of you to share too close? If I may, I would like once again to thank you very much first for your generosity for technical expertise for being so early in the morning. I know not everyone are based the EST. So thank you so much. And the floor is yours for the last time today. If you've got anything to share, of course. I want to share just one thing. Turning in who might be watching this conference, it might be getting into AppSec or security in general. A lot of time you can see some talks and get discouraged or might think like, whoa, some of this stuff is too complicated. And I was watching Nancy's talking about cryptography and that went way over my head. I'm not a crypto guy. But I just want to remind everyone that it's a good time to get into the field. So even if you're new, keep at it, do challenges. Just have fun with it. And you shouldn't be intimidated. Everyone should give it a shot. Even if you're a web developer and you're looking to get into security, now is the best time. So I say go for it. All right. Well, if there's nobody else, usually I would ask for a warm applause for our speakers. Now with COVID, please imagine it. But I'm sure everybody's very grateful for your attendance. Thank you again. And let's see you after the break. Next category will be the platform and privacy. So thank you very much and have a nice day.