Security Testing, Spec by Spec, with Bright

00:00:00

Speaker 1: But thank you very much for joining this this webinar workshop on security testing spec by spec. I’ll let everyone do their own introductions as and when they start, but I’ll joined today by Joe Fish, CTO and co founder of Brite Security. Jeremy Tank, Core core contributor at Lucky. And my name is Ollie, head of product Marketing here at Brite. So just a quick agenda for today, just so that you’re all aware this is being recorded. There will be ample time for questions either via the chat or ideally via the via the Q&A functionality. So what we want this to be is conversational, relaxed. I think Barr and Jeremy will also be having quite a relaxed approach to what is hopefully going to be more of a conversation rather than people talking at you. And hopefully you’ll you’ll agree that we’re going to be showing you some some nice, interesting, cool features when it comes down to security testing, specifically related to the crystal language and of course, the lucky framework. I’ll provide a quick introduction into abstract testing and perhaps why it’s important. I know you’re not probably here to hear that, but I’ll just try and set the tone so we’ll be as quick as possible. Bar will then just run through the step tester itself and how you can use that against your crystal project. And then we’ll move across to Jeremy, who can showcase the lucky framework and the step tester integration and how that can be used as part of your lucky project. So yeah, let’s see. So there were a few more late, late stragglers that have entered, which is great to see you guys. So just just to say it is being recorded and please do feel free to chat away and answer any ask any questions. Sorry. In the Q&A itself. So just a quick intro into Bright, by the way. So we provide a developer focused Dynamic Application security testing scanner to scan web applications, APIs, web socket based architectures, mobile apps. I know this may not be so specific to Crystal itself in some ways, but it would be very relevant in other ways to perhaps other work we’re doing. We’re really about putting security testing earlier into the developers hands, and this is really where the spec tester comes into play. So I’ll let Barr talk about that a bit more seamlessly integrating into your pipelines. Automatically validating every finding that we get. So you do not have false positives, which I don’t think I need to tell you the benefits of that. And really a security scanner that’s been built for developers, for those that aren’t security professionals, to detect, remediate and fix issues as early as possible, as well as providing some really cool capabilities in terms of not just carrying out your trivial injection attacks, but actually trying to break the logic with business logic, vulnerability scanning or testing capabilities as well. Now, why is that so important? The application layer is always and has been and continues to be one of the weakest layers. It’s certainly the one that results in the most number of data breaches that we’ve seen pretty much continually for a number of for a number of years. The attack surface certainly is growing, particularly with the rise in APIs, for example, and it’s really the need for security testing to keep up with developers rapid release cycles. With multiple builds per day comes the introduction of security vulnerabilities at the same pace. And it’s everyone talks about shifting left and putting security testing into the hands of developers, but that security testing needs to match your speed. The developer speed integrated at all phases, but ultimately doing it as early as possible. And this is really where the unit testing part in order to test every spec by spec really, really comes into play and comes into focus. You know, you may want to ask when you’re carrying out security testing, and I know that Jeremy will be able to talk about why he was so keen to introduce security testing into a lucky framework. But typically this is this is an afterthought carried out manually, perhaps maybe with a peer review, But it’s typical that security testing takes very much a backseat. Right. Periodic scanning, periodic testing potentially by a third party. And actually it’s the tools that we use are actually inhibitory that may lack the ability or the agility to carry out these tests quickly against scope, define tests, i.e. against each spec, for example. There’s no feedback to the developers because it comes too late. It can’t integrate very, very well and it lacks that consistency in testing in order to build what is a comprehensive security program so that whatever you’re shipping into production is going to be secure by design. And this is really, really where you need automation. Automation with security testing that I mentioned is going to keep up with those development pipelines seamlessly integrated, but would also enable you to run multiple tests, ideally concurrently, that don’t run for days or weeks, but run 4 seconds or very few minutes so that it’s scalable. I don’t know the size of the organizations that you’re working with. I know that Kristol and Lucky are still obviously a language and a framework that are that are growing and gaining more traction ultimately, where others have failed. Hopefully you can start to succeed early on by adopting the security testing automation now and ensuring that whatever it is that you’re developing in your Crystal or Lucky Framework project has that security in built in, maintain and build that build and maintain a culture of security testing. And we all know that the earlier that we can detect and remediate security vulnerabilities, the easier it is to fix, the cheaper it is, is to fix. And ultimately, it means that you’re not you’re not going to have this context shifting because you need to then go and suddenly fix the security bug, perhaps that you inadvertently introduced one week, one month, one year ago. So. A little bit just to sort of set the scene in terms of what Bright are some of you may be familiar with, say, software composition analysis that looks at your libraries and dependencies to make sure that they’re up to date and patched. You may be familiar with static application security testing that looks at the source code pretty much from a one dimensional perspective, not looking at the running application. But that’s something that you may be familiar with in and around your work. Are a dynamic application security testing tools. So we’re really looking to detect vulnerabilities that would be exploitable in in the wild that would be. And that could be exploitable by a malicious user on the built compiled application. So really looking for things like cross-site scripting, interacting with the application itself to find real life, real real world security issues. And I’m not I know there’s a lot of information here, but I’m just going to go through it very, very quickly. We’ve sort of built our technology around developers, right? Not for security professionals, and that’s the sort of blocker when it comes down to security bar. And Jeremy will be able to talk about this a bit more. But here’s just a brief snapshot of the key aspects that we took on board, built by developers for developers, but obviously for the security, the security focus to test a multitude of different sort of applications. We really wanted to try and make security testing to be intrinsic to the developer’s experience, controlling scans directly from the CLI via configuration files, YAML configuration files. I’ve already mentioned the no false positives, so you can start to trust the output and know that this needs to be fixed, which is great for prioritization of fixes so that you can understand what needs to be remediated. We have seamless integration across the pipeline, very, very scoped defined tests. Anyway, this unit testing part with the SEQ test to be able to test each spec really enables you to define the scope of the test that enables you to run. I’m sure Jeremy will show it Tests that run 4 seconds that aren’t going to slow you down. One key focus for us is ensuring that you can detect as much as possible as early as possible. We’re not here to talk about those capabilities now. However, we have a very, very smart engine that really, really can go above and beyond to detect more and often. Without further ado, I think I’d like to hand the mantle over to backlash against CTO and co-founder here of Bright, and he’ll take you through perhaps more of a traditional look through it for Crystal in general, and then Jeremy will take the mantle thereafter. Thank you.

00:09:29

Speaker 2: Hi, everyone. Good to see you all here. Is that a good size everyone can see?

00:09:38

Speaker 1: Yep. Looks good.

00:09:41

Speaker 2: What’s. Nice. All right. So going from what I always said, the thick tester and just generally doing those kind of security testing in the specs has two parts. The first part is just the generic SDK, which is the sex tester ACR that I’m going to showcase. And then if you are using the Locky framework, there is some very, very sweet integration that Jeremy did, and he’s going to show you basically everything you need to do to get a project with the sex tester all integrated automatically. It’s really great work from his side and the integration is really flawless. So without wasting any other any time, let’s go into what’s the point and the use cases of using the Shard. So obviously, if you’re using Crystal and I’m sure that all of you have already created at least one project in Crystal, just adding it to the dependency obviously is the first step should be very easy installing the shards. The only external dependency that you might notice is the exploit SLA utility that has to be installed into the into the basically the environment that you’re running. So if you’re running the unit testing either locally in your own laptop or you’re running it as part of the PSI, this part will need to happen installing it, which is very simple. And in the end of the redmi there is even an example on how to actually install the CLI inside of the GitHub actions. So really it’s super simple. It just needs to live there. You don’t need to do anything else with it. It’s just a dependency and hopefully it won’t be a dependency for long. The other type that we need to do is to register for a new religion account or a bride account To register is very, very easy. You can just click on the link and let me just once again, sorry. Right.

00:12:28

Speaker 1: So sorry to interrupt. Just to say that this is that those that are joining, if you haven’t already done so, you can do this now as well with Barr, right?

00:12:36

Speaker 2: Yeah. You don’t need to you don’t need to have done that before. If you want to do the workshop with us, if you want to try out the things that we are right now showcasing, just feel free to do it with me. So. Up that new religion dot com. Either log in or sign up. You can either click on the try it free. Right? And then you can just create the account. So I’m going to create a new account just to show you how we’re going to go through this.

00:13:09

Speaker 1: So I would just say sorry to interrupt. We did say this is going to be conversational, so I will be interrupting for those of you, for those eagle eyed viewers of you, you’re thinking, hold on a second. All of us just been talking about brights. Barr is talking about Bright But we’re looking at the word new religion. So just to for any one of you that’s confused, we did go through a name change. We used to be called New religion. We are now called brights. And I’m sure you can all understand that whilst all the marketing stuff has been done with Brite. The last thing to be changed is the is the engine and the everything you see now. So don’t be perplexed or confused about that. This is definitely the right thing and eventually it will change. I just thought I’d just clarify that for everyone.

00:13:59

Speaker 2: So once you get all of that configured set up field, you can just click on Create a free account, You will get a confirmation email. You just need to follow up on that and. Yeah, obviously I have already created that, so I’ll just create. Sorry about that. I never remember which.

00:14:35

Speaker 1: You’re going to have to start getting some. Yeah.

00:14:39

Speaker 2: I always move the. Let’s try this one. I don’t think I have that. Let’s try. Sorry. Right. So my password. Everyone, please look away.

00:15:02

Speaker 1: It’s just password, right?

00:15:03

Speaker 2: Yeah, obviously. Password. One, two, three. You have to be secured. Obviously, you don’t have to put blowfish as your full name or this is this in the email. That’s basically mine. So. Right. Okay. No, we got it. So we’re getting the link verifying. Going in. Now you can create an organization, give it a name. The organization is basically a workspace that you can invite other users to join in. See the the results, see the scans. This is especially helpful if you’re working on, let’s say, an open source project or internal company project, and you want a few people involved to share their thoughts or just to have collaboration around that. Basically, if you want people to actually offload the fixing too, then that’s a great way. Just invite people that you think are going to go and fix the stuff. That’s the best way. So I’m just going to create, as you can see, borrowed. Yeah, and I’m going to create it. Then the next step is to install the next ally. So you can see that we actually have all of the configurations and all of the steps to actually install it here as well. You can just click next and choose whatever whatever way you prefer, either as a Docker container, as an NPM package, or as a Windows installer. We will even automatically create these for you. So we’re going to generate a repeater ID, we’re going to generate a token for you all, so you can just copy that and paste it into the terminal. Once that’s running, you will see that this becomes connected. And then you can click on done. Now, the whole point of that was really just to make sure that everything is okay, you have it installed, etc. so you don’t have to actually install it where it where you want to to have that actually running. It’s just to make sure that everything is working before you start. Now our second step is actually to generate the API key. This is done from our UI. You just click on your user settings. Here. You scroll down all the way. You create an API key. You give it some kind of a name. So let’s call it tech tester, for example. And there is in the knowledge base the exact configuration for what you actually need from that. But just because we really care about security, we’re going to just select all of the scopes. And I’m going to click on Create. Now, obviously, this is a secret. So if you’re doing some kind of a streaming or a workshop, don’t let people see that, right? Because it’s secret, especially if it’s if it’s been recorded and then you share it with others. So don’t let people see that. Once it’s generated, you can just copy that and close. Do note that you won’t have access to the full API key later, so better save it somewhere safe. Obviously there is no limit on the API keys. You can just create as many as one. So even if you forget it, you can just create a new one.

00:19:05

Speaker 1: Yeah. Once that’s closed, you can’t see that value anymore, right?

00:19:11

Speaker 2: You can just see the prefix because you can actually edit the scopes after creation, but you can’t see the full API key. So copy paste it somewhere safe while you do your configuration and then you can start playing around. Now, the preferred way to actually initiate the scan if you’re using the Barebone SDK is to set up a bright token environment variable. So if you’re running this in your CI or you’re running it in your terminal, just bright token equal and paste your token before you call crystal specks, or if you’re running in the actual CI. And let’s say you have actions, then you just go to your settings, you’re going to secret, right? And you just create the bright token repository secret and put that API key is your value. This is really important if we want to get everything working. Now, what’s the actual use case? The main use case for this shard is to test web based targets. Right. For web based vulnerabilities, we’re talking about OS top ten, which will 25 application security tests. So most of the use cases around this is web based platforms. In this example and this is really like a quick a quick server, so we just set a server, we create some kind of a logic to just print out the name. Obviously, we’re also decoding the data and then just put it here without escaping. This will actually have an excess vulnerability or cross-site scripting vulnerability. Then we create a new tester object we call the run check model. We give the scan some kind of a name. We decide which tests we actually want to run. Now, I will show you exactly the full list of tests that are that are available. And we set up a target. Now, the target object can be an either a single URL or a full configuration. So let’s look at that for a bit, because this is really important. The target actually accepts multiple parameters. So we can set the method. We can set the URL. We can even set what the response response supposed to look like. So if you have like a mock server and it’s just going to respond with something, but you want to set it to respond with something else, this is the way to do it. You can just define exactly how it should behave. Now there is an option and this is something which is unique to our freestyle sector, S.R. We also have 60 Easter eggs for JavaScript, but this thing is super unique to the crystal one, and that’s the ability to test a single function without needing an HTTP or web based target. It uses. It’s a bit more complex in the configuration, but basically you just do a span. You set up a while loop, you receive the payload, you send it into your function, you get back the response from your function and send it back into the channel. Those both are channels and will run whatever tests you configure here. This is very similar in the logic to an active sast, which is something that you won’t find out there. If you have stuff like let’s say an HTML rendering shard or you have just let’s say some kind of a database shard that you want to make sure can handle SQL injection stuff. You don’t need to actually set up a whole HTTP server. You can just send the payloads directly to your functions and get back the response. Those have to be strings. It’s also it’s also specified in the documentation. The next thing, because that’s actually the whole point of doing security testing is to fail by severity threshold. What do I mean by that? Let’s say your CI is very important. It’s very important for your CI to finish or you have some known vulnerabilities that you’re okay with and you don’t want to fail your CI for every cookie security issue or any of the low severity findings. In this case, you can set up either medium or high as the severity threshold. So the Shard won’t raise an exception for issues which are not either medium or high in severity. If you set low, then it’s going to raise for low, medium or high. If you set medium, then it’s going to raise for medium and high. And if you raise for high, then it will obviously raise only for high. It can be configured like that, basically. And this is how it looks inside of the full function. A bit about the scan options, by the way, if anyone has any questions, if you want to do anything, feel free to just send it in the chat. Send it in the lucky Discord. I have eyes in there to our own discord, whatever we are there. The last part is the scan options. Basically, you can have some extra configurations that you can do, which is which can basically add more thoroughness to the test. There is documentation to what those do specifically. There is in our UI a thing called projects which can accumulate all of the findings for multiple applications or for multiple scans in a single place. So if you want to use one of those, you can even set the project ID. Those are all optional and has default and have default values. I think one of the most important parts is choosing the right test. The AI is something that has to run quickly, right? We all know that we don’t want to waste 20 minutes testing for every vulnerability there is on every basically on every entry point or every unit test or every spec. So in that case, it’s really important for us to optimize it by choosing with the tests that are actually relevant. How do we know that? Or what’s our rule of thumb? Basically, we think about functionality. If you have a database involved, use SQL injection testing. If you have HTML rendering, you can test for excess. If you have, let’s say, a templating engine, you can use xdai. All of this information, by the way, is available in our documentation. And the cool thing is that if you use lucky, it’s going to do all of this thinking for you, but we’re going to get there soon. The full list of tests are available in this file. Oops, sorry. I think that I need to just fix the link, but basically it’s here, so source test. This is all of the supported tests that we have right now. If you want to know what are your what’s available. So there is everything from testing file upload vulnerabilities, brute force login if you have a login forms, email injections, JWT tests. If you have like a function that verify JWT, you can use this test. It’s very, very thorough and very advanced. OS injection, remote file inclusion, a lot of.

00:28:31

Speaker 1: Test my WordPress against Lucky.

00:28:35

Speaker 2: So, so for example, this is a good point. So if you’re using Locky, obviously there is no need to test for WordPress, which is exactly why you’re optimizing and choosing the right tests is something that is very important.

00:28:52

Speaker 1: Surprise, I once built a Rails app that was literally half rails, half WordPress all integrated into the same code base.

00:29:02

Speaker 2: That sounds horrifying.

00:29:06

Speaker 1: It was.

00:29:11

Speaker 2: And I guess the last part is about integrating into the CI. So it’s really, really, really easy. You just install a repeater. You set up the exploit token. You set up the Brite token. Sorry. By the way, this is this is incorrect. I’ll also fix that if you want to see an example of how it actually works. You have the six testers own unit testing available so you can see this uses the Brite token. Right? And you can see all of the steps that are actually happening. Not only that, the six testers, your specs are actually spec six this the specs. So you can also see how to use the target, how to set it up. You can see all kind of use cases like testing for X from the rhythm and also testing for other stuff. For example, how to set up specific headers. You can see how to set extra headers in the context. You can see, for example, how to use the severity, the options. And also if you want to start and you scan with extra options, there is an example for that and how to actually do this function thing. Single function test. You can see that there is a definition for my function which basically just returns the same data that it gets. This is specifically relevant for X success because it tests for reflection, but obviously as long as it returns a string or you can just do two X on the response, then we can digest that and try and evaluate if this function is actually a. Susceptible to anything. Last thing before I hand it over to Jeremy. You know what? Two things. So first, if you are not sure. You can always use Neil in Crystal. We really love Neil. So that’s an option if you just pass Neil or don’t defy the. Define the tests. It’s going to use all of the tests. It’s going to take a lot of time. It’s going to be inefficient. But if you want, you can do that as your first step, basically, and then say, Oh, I see that I have those problems from this point on. I’ll just use those specific tests. And basically there is an example of the Shard in action on the Lucky Stick test report. But I’m going to hand it over to Jeremy because that’s basically what he’s going to talk about. And if you want to just play around with it, there is also a CLI that I created to test the library, but it actually has a nice output and allows you to scan a single URL for all of the vulnerabilities. So if you want, before integrating that fully into your workflow, just to get the feeling of like how a scan looks and what it can find, you can just use that. It’s super easy 2 seconds to to start just clone a child, build and use your bright token as the option. That’s it from my side.

00:33:00

Speaker 1: Any questions? Yes. I was just going to say, just before moving to Jeremy, are there any are there any questions for Barr just before.

00:33:14

Speaker 2: So quiet.

00:33:16

Speaker 1: Yeah.

00:33:17

Speaker 2: Yeah. Is anyone. Can anyone hear us?

00:33:20

Speaker 1: Yeah. Alexander says that. Not yet.

00:33:25

Speaker 2: Not yet. Well, that’s obviously Bob. Congratulations. You obviously did a good job.

00:33:30

Speaker 1: Yeah.

00:33:32

Speaker 2: It’s so.

00:33:33

Speaker 1: So obvious and so clear. Well, that’s why we use crystal, right? All right, so I’m stopping my sharing and moving it past to Jeremy.

00:33:50

Speaker 2: So I’m presenter now. Time for me to take over.

00:33:56

Speaker 1: Yeah. Take over.

00:33:59

Speaker 2: All right. Let’s just. Share this whole thing. Participants can now see my screen. All right. So you all can see my screen. Everything.

00:34:12

Speaker 1: Yeah. All good, Jeremy.

00:34:13

Speaker 2: Cool. All right. Yeah. So let me just talk about what Lucky is. Just to start real quick here. So Lucky is a web based framework that’s written in the crystal language. I’m sure that most people here are going to be crystal developers and already know. But for anyone that might see this recording later, new to Crystal and whatever. Yeah, Lucky is just a web based framework. It’s a full stack framework, so it covers everything from developing APIs. To the full front end and everything. Now, one of the goals that we have when building lucky is to be able to catch bugs sooner than having them hit production. There’s a lot of other frameworks out there where you can build your applications really quick. Write, prototype them, get them up there, you get them up into production, and then all of a sudden there’s a bunch of edge cases that you didn’t quite think about. You start seeing all these weird random errors coming up and whatever. So what we want to do is we want to have a framework that you find the bulk of that stuff while you’re developing it. So when I was talking with Barr about the spec tester, actually, well before even integrating it, I used it myself just to give it a shot because I was like, okay, well, what is this all about? I personally don’t know anything about doing security. So I’ve never done any type of security testing before, like ever. I’ve shipped all kinds of massive rails apps and in whatever out there into production. But yet who knows how wide open they are. In fact, I know one app that I worked on actually did get hacked due to some security vulnerabilities. So I was pretty interested in like, how exactly does this work and all that integrated the spec tester into a lucky app, tried it out and still didn’t quite understand exactly what all it was doing, but it was definitely given me a lot of information, which was pretty cool. But once I started talking with Barr and he was saying, Hey, we should look at just integrating into this into Luckey directly, my first thought was since one of our goals with Luckey is to try and catch the bugs before they hit production. Well, I mean, that totally makes sense, right? What we’re doing here is we’re basically saying you’re going to generate an application you’re going to have out of the box security specs, and then you’re going to run that in your CI. So let’s say like GitHub actions or whatever, and then that’s going to tell you, Hey, look, you missed a couple spots, you have some security holes. And at that point, if you do like a CI full deployment from there, we can catch that before that deploy actually goes out. So depending on how you have your deployments set up, if your deployment is set up from GitHub, then we can actually run all those specs, run the security checks, and before you actually deploy the application to production, we can stop you and stop the CI and actually report back to say, look, we found some SQL injection holes, some cross-site scripting or anything like that. So it was just kind of like a real nice addition for us to add. Now, with that said, this is a new thing that we’ve added in since I started working with bar on it, and the actual tester itself has grown by leaps and bounds as far as like what it can do and everything like that. So it’s still sort of a work in progress as far as the integration goes. But what I’ll do is I’ll actually generate an application and show off the entire thing. So let’s go ahead and just do that now. Once you’ve installed Lucky, you can come over here to the Lucky Framework network guides and then just go through your installation. I’m not going to show that process right now, but once you have it installed, you’ll have this lucky SEAL tool here. And normally you would run lucky in that to get started with your application. But for now, what we’ve done is we put this behind a small flag just so that way we can kind of get out all the little issues and work out the flow of how the integration with the tester works. So for now, and this will change in the future, once everything becomes more solid, you’ll just run lucky and into custom and then you’ll give it a name of your application. So in this case we’ll just call it a super bright and then we’re going to add this great name. Yeah, you like that? And then I’m going to add this, this flag here. Now, what I can do is if you’re ever unsure, you can run. Just dash. H. And then you can see there’s a lot of different options here. So just the WITSEC test. And what this is going to do is this is going to actually add the sex tester integration into your lucky app. So this means that you don’t have to have it if you don’t want, but. Eventually we’re going to start really pushing for this, probably be in default or whatever. All right. So we’ll make our super bright application and say with test and that’s it. It’s going to generate the application and then I can see the into there. Follow these instructions, the config database. Depending on how you have your PostgreSQL setup. Lucky out of the box only works with PostgreSQL, so that’s going to be what’s assumed for me. Everything should just work default. So I don’t really need to do anything. But what I’ll do is I’ll go ahead and just run this script setup and I’ll talk about what this is doing while it’s going. So what this is going to do is I’ll let the applications come with this script to go ahead and sort of bootstrap your application with everything that it needs. Make sure that we can actually install the application and run it. We have some node dependencies because by default I didn’t say I wanted an API only. So this is actually going to generate a full web application, front end, HTML, CSS, JavaScript, all that kind of stuff, running yarn, it’s installing stuff, compiling the assets. Lucky comes with Laravel Mix. So it’s setting up mix. It compiled my JavaScript and CSS, and then we move on to the crystal side where it starts installing all of the crystal dependencies that luck needs to run. You see all this going and stalling a couple of post installs here to make sure everything’s working. And just about done. Now, while that is running, what I’ll do is I’ll just go ahead and pull up the lucky sex tester shard. Now we have neural region or the bright set tester. And what we’ve done is we’ve actually worked on a separate lucky set tester. What this is, is it’s basically just a thin wrapper around the actual sex tester itself. What this does is this allows us to basically take some of the heavy lifting off of writing the specs, and it makes writing the specs a little less cumbersome. When you’re writing the test with the set tester, you’re writing out your URL’s, your targets and saying, Well, this method is a get and this method to post and all that kind of stuff. But with Lucky, we have our actions action classes, which already know of all that information. So the the lucky set tester allows us to actually just tell it, hey, run against this action and then it builds out everything for you. All right, so we’ve created the database, verify that we have a connection to it, set up migration and everything like that. Now it says, I can actually just run Lucky Dev. So running a lucky dev is going to boost the lucky application and make sure that all the assets are fully compiled and then boots the actual crystal web server. And so I can come over here and there it is full application running and you can see in development it’s. Pretty fast. So this is running in just a few hundred yards. So less than a half of a millisecond. But yeah. So we’re here to talk about some specs, though, so I’ll go ahead and close this out. And what I’ll do is I’ll just open this project up here and break down exactly what all was generated from this. So here’s an example of the the lucky application. Now, when you’ve added the lucky test. It adds in the development dependency for this lucky set tester. And then what we get is we get a few additional things here. Like in our spec setup, we get this setup here that tells us no, no updates. It’s obviously this looking for an exploit token. Like I said, this is still a work in progress because at this current time everything’s pointed to NULL Legion. This is what we were calling it was an exploit token. So in future updates, I’m sure this will be renamed to Bright Token and then rename the environment variable. All you have to do is just add in your environment variable, your API key that you would get. And just like var showed earlier, I’ll actually show mine real quick so I can just sign up with GitHub. It’s going to log in and this is the account that we use for the lucky CLI. Any time a pull request is submitted to Lucky to change the framework, whatever, we actually run against Nerf Legion or the bright set tester tests here. On all of those pull requests. This ensures that whenever someone makes a change to the framework itself, we’re actually testing these specs live against a actual generated application to ensure that no one’s introducing any sort of new security bugs or anything like that. This kind of helps us get a peace of mind that as we develop the framework itself and improve the framework, we’re also adding security testing as a first class citizen. It’s not some sort of afterthought. But yeah, So you can go in there.

00:46:44

Speaker 1: From the get go.

00:46:46

Speaker 2: Yeah, exactly. Exactly. So you go once you’re logged in, you go to your user settings, you create your API key, and then that’s what is going to go in here. You can set that as that value. The next thing we get here is under spec flows. Now, from Lucky, we actually have quite a bit going on here. We have all this testing guides and all this. One of the things we have, though, is called Lucky Flow. And what Lucky Flow does is it tests your front end for just. Um, interactions and UI and whatever. So you can say go to this page, you should see a button that says this or click this button and you should be on what page. So that’s what the lucky flow does. And what we’ve done is we’ve added in the security spec. Now, as you’ve seen, I didn’t write any specs yet, but yet I have several specs already written for me. And that’s because when you generate with that dash with test flag, we’re going to go ahead and give you this. Now, there’s a small caveat to this. The specs themselves actually do take quite a while to run. For me, running these is about. 25 minutes locally on SCI. They they generally tend to run a lot faster, maybe about 15 minutes or so. But yeah, locally for me it runs in about 25 to 30 minutes, somewhere in that range. For that reason we give you the option to basically opt in. So by default, if you just run crystal spec, we’re going to go ahead and skip these. And for another reason too, is because. When you get your account with Brite, they’re going to give you a certain number of what is it, bar scan hours or.

00:49:00

Speaker 1: Yeah, I think. And only you can keep me honest here. But I think. And I think there are like, like ten, right? Ten or something like that. Scan ours. Um, in regards to the free account.

00:49:20

Speaker 2: Yeah. Yeah. So out of the box, you’re going to get a certain number of hours, whatever that is, for your accounts. And as you’re building your application, you don’t want to be running up those hours and spending all this time, right? So it is a nice thing to run locally here and there. Maybe. But the real idea would be to run this in your CI. So when we generate the CI, we actually set it up to where it will automatically add that and they’ll automatically run that for you. So in your CI, it’s automatically going to run those. So I can run crystal spec and funny thing here is so I ran this yesterday and I realized that there is actually a failing spec I must have missed on the last update. So I have to actually update that.

00:50:12

Speaker 1: Just going back. Sorry Jeremy, this is what you’re doing that to the the scan times. I noticed that one of the tests on there was the access testing. If you go back to the flow. So yeah, that’s probably one of that’s probably one of the longest testing cases that you can do using the bright scanner for a multitude of different reasons, which maybe Barkin can go into. But I think the beauty of this is also that. It doesn’t need to be like all or nothing. Right. You can, as you mentioned, refine the testing, perhaps by removing certain tests that might be that might be quicker, you know, giving yourself maybe less coverage from a testing perspective, but at the very least, enable you to run a full suite of tests that perhaps aren’t going to take as long and then perhaps run a longer test later on if if you didn’t want to be slowed down during this process.

00:51:18

Speaker 2: Yeah, exactly. And this one here, actually, we run all of the tests, including the WordPress. So we are testing your lucky application for WordPress vulnerabilities. Yeah. I mean, this might be something that like in future releases, we could just comment out or whatever. What we really wanted to do is since so many people are going to be new to the concept of the security testing and how this stuff works, we wanted to make sure that we’re giving you enough examples so that way you can kind of build off that. One of the other nice things too, is when I generated this application, I generated a full stack web application. So for example, this here is testing DOM access and such like this, right? If I generated an API only application, the lucky CLI will not generate these tests because DOM access dom cross-site scripting doesn’t exist on an API level. So instead what that would do is it would generate more API centric tests like testing JWT for example. Yeah, we have cookie security here and we can test against JavaScript as well, which is pretty nice. But like I said, if you’re generating a an API only application, then the CLI won’t generate these web related or front end related tests because they’re just not relevant. I guess I can break down what this is kind of doing here. So Bar was shown earlier how you can create these targets and when you create the targets, you specify the URL, the HTTP method, some different headers, and whatever The lucky suck tester shard gives us this thin wrapper where we can actually just pass in the class actions. So for example, sign in’s new here. So if I look at my actions and I look into Simon’s new. I’m already testing against. I know it’s slash sign in. I know that it’s going to be get and all this and that kind of gives you. An easier way to run this test without having to write a bunch of boilerplate code. So I’m missing my environment key here. I need to set that up so I’ll go ahead and remove my current env because it was blank. And then I have a sample one that I will just move to right here and now. What I want to do is.

00:54:25

Speaker 1: Irma, are you able to. Are you able to make this this screen that you’re working on now bit bigger? Just a comment from Alex on the chat.

00:54:32

Speaker 2: Oh, the code. Oh, here we go. Yeah, sure. How’s that? Perfect. I won’t see that. Okay. Sorry about that. Yeah. So what I’ll do is let me go ahead and I’ll just comment out a couple of these so that way I can run them a little bit faster. And what I want to show is. I’m going to I’m going to actually take this out here. Bar mentioned the severity threshold, but I’m going to show what this looks like when it fails. All right. Those should be all right. Yeah. I’ll come out. This one too. Just so that way these run a little bit faster. And I want to show how this looks when it fails. So if I run Crystal speck, it’s actually not going to run these tests at all, because, like I said, this is going to skip Skip unless I add that flag. But we can see that we have a failing spec that I need to work on. So now I’m going to go ahead and run it with this test. Since I’ve added my environment variable, my my API key in here now it’s going to run those tests. So here it goes. You can see it’s taken a little bit longer.

00:56:09

Speaker 1: The moment it starts, though, it’s pretty awesome because you can already see in the platform in our own UI, the scans are the scans go to pending and you can see the information of the actual scan. So you can see already the scan is bending and the engine starting. If you go into this scan, you can actually see the configuration that you did. You can go to once the scan started, you can go into the entry point information to see exactly how the request looks and how the response looks. You can go into the site map just to figure out exactly like how your rail looks. You can see the target that was set already, which is like the route target, right? So you can see it’s local and there is just like the random port or it’s not the trend or it’s like whatever the lucky dev port, I think it’s 3000, right.

00:57:11

Speaker 2: Yeah, well, locally, I think the specs are running.

00:57:16

Speaker 1: On five 5000. Yeah, I see. 5001. I think maybe you can refresh that. Yeah. Yeah. So as you, as you can see, the kick start of the engine takes around. We can call, I don’t know, between 30 seconds to one minute, depending on the size of the scan. But if you are, one good strategy to save time is to put a few tests inside of the same spec, because then you save time on kick starting multiple engines. We are also working on improving the start time of engines so that starting scans will be quicker because you will see that the actual time for a scan is usually like 50 seconds or something like that. Not talking about the one scan with the new value for this, which obviously takes some time because it scans for everything. But Jeremy, can you click on refresh for a second? I think the scan is done. Yeah. So you can see that it’s already done. If you click on an entry point in the tab. Yeah. So you can actually go in and you can see like real information about the request response, how it actually looks like. In this case, there are no parameters, but you can see like what the, what we sent. You can see what the lucky app actually responded with. So, you know, it’s all there. You can see even the authentication information, you can see the cookie, the session. So you can really drill deep into what we did. It’s not just like some kind of magic. There are there is like real information about it. So, you know, it’s not just a checkmark that goes green and you can actually see that there were tests running. Yeah, I think it already moved to yeah. To start the next one here. You can see that also in tests you can see exactly which tests were were running. In this case, we’re still.

00:59:50

Speaker 2: Loading that fancy animation.

00:59:54

Speaker 1: The power of gifs. Yeah. And if you click on progress once the scan starts, you can also see like where we stand in regards to all of the tests that you configured so you can really play around with it. One more thing that you can do talking about the generic SDK is to actually use that for QA automation. So if you want to test your staging application that’s already up, you can just create a crystal file that runs in your CI and you just set the target to whatever the target of your web application is. In the case of the unit testing example, obviously it’s local and as you saw, it’s very nicely automatically generating the actual target. So like the localhost and whatever is needed. But if you want to look at it in a different way, then. Okay. So you can, by the way, see that we have already findings. And you can also see in Jeremy’s terminal that there is an error showing.

01:01:13

Speaker 2: Yep. So it’s just wrapping up here and we can see that this one here had six low priority issues. Now, one of the the issues that we’re going to see pop up on here is from the cookie security. So it’s recommended that when you have your cookies, you have them set to HTTP only. Right. Or you have them set for secure. Now, when you’re running tests locally or whatever, by default, we’re not going to have luck. He’s not going to have the cookies set to secure. Just because this is going to be based on if your cell handler is turned on, and that’s really only going to happen if you’re in production. So in this case, having your cookies set to run on HTTP. Is sort of a low security priority. We know that those will be enabled in production. So it’s really going to be up to you. You can decide whether or not you want to ignore that or not. So what we do is where do I remove that? Here we go. Is we have the severity threshold where we can actually just set this to medium since it’s a low priority security. Now this the severity threshold. It is an enum. So if you happen to try and type in medium and it doesn’t work, you’ll want to use the tester severity enum. That’s just mainly based on how crystal passes the auto casting from symbol to enum. It doesn’t work when it goes through several wrapper layers of methods like we have on the lucky duster. Okay. There it goes. Here’s the actual failure. This is the one that I was actually waiting on. When we get the failure, we actually get quite a bit of information back from the set tester to let us know things like what happened, how important it was, what the error was. Different details on how you can possibly fix it and everything like that. But this is the way the failures will look. And again, the only reason that failed is because I said go ahead and raise on all severity levels as opposed to just medium. But. I mean, we could probably talk about this all day, but are there any questions? Yeah.

01:04:28

Speaker 1: Let’s see.

01:04:32

Speaker 2: Can I see?

01:04:33

Speaker 1: No questions so far from my side. Alexander I’m pretty sure that you’re the only one that actually listens to us. If there are other people, at least just say hi, like you don’t need, oh, two of us listening. That’s what I’m talking about. All right, so at least two people. Oh, so three people. Awesome. We will also have a topic. We will also have Russell. Everyone is spamming the chat. So we know they’re actually here. Awesome, guys. So we are going to have a recording of that. So if you want to watch it again to hear us talking about it, if you have questions, by the way, the work that we Brite did with Jeremy and Lucky is is a show of trust from the Laki crew to us and from us to them. It’s a real collaboration. So if you need help in regards to that, I’m also in the Lucky Discord all the time. So if you have questions, you can find me there if you want to. We also have our own discord, but again, I’m also giving support in the lucky discord regarding that integration. So bugs, questions, stuff, whatever you need.

01:06:16

Speaker 2: Let us where are we going to post the the link to the video? Probably post it in the Lucky Discord for sure. Maybe in the bright discord. Probably all the social media is if you’re not.

01:06:28

Speaker 1: So also also anyone that registered for the event. You’ll also get an email to the recording. But yes, Jeremy, of course we’ll add it onto the discord. I’m sure Jeremy can find a nice place for it on the on the lucky framework dot org websites as well.

01:06:48

Speaker 2: So that will end up being here.

01:06:52

Speaker 1: Yeah. So, so we can do that. I mean a question I’ve got to those that are listening before they all jump off with their thank yous. Are you using. This already. Have you tried it out? And if not, will you be trying it out after after this talk? That would be that would be what I’d like to know. Did you get enough from this to use Bright and also to look more into Lucky as well? Alexander says it might be worth mentioning that lucky users will be happy if anyone decides to contribute. Absolutely. And yes, Bright are looking for crystal developers. So. You know, if. If you’re interested in working with the future of security testing, then. Then, Yeah. Reach out to us. Okay.

01:07:57

Speaker 2: By the way, David, if you want to test or play with the sex tester and you’re not using crystal and you work in backend, that’s also great because and again, this is we did one workshop around it and it’s still really in.

01:08:24

Speaker 1: Alpha.

01:08:24

Speaker 2: Alpha, but there is also sorry, let me send it to everyone. There is the sex tester. GS which still lack proper, proper documentation, but it’s there. We know that it’s working. Not great yet again. It’s still not a fan, but if you want to try it out to play around with it, then you have that option as well.

01:08:52

Speaker 1: Yeah. And I would also say that if you’re not already follow Lucky Framework on Twitter, follow Bright Apps at Bright App on Twitter as well. We will be having an exclusive introduction to the JavaScript SEQ tester on the 9th of June, which will be a very, very hands on workshop where we’ll be going through that as well and watch this space as we add multiple different languages frameworks over the course of the next few months to really enable you all to be able to use this. But of course, due to our very close connection to Crystal and of course Lucky we had to do it there first. So you can obviously start benefiting from that now. And yeah, keep an eye out for additional content on Discord on Twitter. As I mentioned, for other releases. Yeah. And Ruby absolutely is certainly one that’s on our on our radars. So watch this space.

01:10:06

Speaker 2: So especially because it’s so close to crystal. And if you take a look at the sector structured source code and it’s again it’s open source obviously mid then you’ll see it’s very slim. It’s just an API around their own backend. So it should be pretty easy to quickly port that to Ruby. We have that in our own roadmap, in bright roadmap. But if anyone is interested, you know, that could be an awesome collaboration project. So I. Well, we would love to play around with stuff like that.

01:10:51

Speaker 1: Yeah, that’d be awesome to see.

01:10:55

Speaker 2: But let’s be honest. Crystal is much better. I’m just kidding. Not starting wars. All right. Awesome. Thank you, everyone, for joining in. And again, if you have questions, as we said being us, let us know. Thank you for everyone who joined. You’re amazing.

01:11:17

Speaker 1: Yeah. Thanks, everyone. And we’ll be hanging around on the discords and such if any other questions happen to pop up?

01:11:26

Speaker 2: Absolutely. Thank you, everyone. Look out for the recording. Keep in touch via the socials, discord, Twitter, etc.. We’re all here for you. Thank you.

01:11:34

Speaker 1: All right.

01:11:35

Speaker 2: Bye bye.