XSS attack automation

- [Instructor] Security testing automation is a lot of fun, and now let's work with our first real automation test. Here we'll use one of our scanners to test for cross-site scripting on our test site, Gruyere. You want to make sure Gruyere is up and running. To do this, let's go to the main repository. I'm changing directories to security-testing-class. Now that I'm in here, I'm going to use make gruyere-start. Alright, this has Gruyere up and running on localhost port 8008. We can do a docker ps to check and make sure this looks good, and there it is. Now, let's also open a browser and head to localhost:8008 to make sure everything is running. Alright, there it is, looks ready to test. Let's get to writing an attack. I'll clear my screen here and let's get started. I'm going to open up a new attack file, which I'll call xss.attack, and I'll put it into its own directory so we can logically group attacks together. The final version of this attack can be found in the exercise files. First thing, from the main security testing directory, I'm going to type mkdir and then ./attacks/xss. Let's open up xss.attack inside there. I'm using vim, my IDE, for this. Now, I want to start with a feature and I'll type this one: Look for cross-site scripting using arachni against our site. Okay, that looks good, pretty simple. It tells us what we are testing and what tool we are using. Now features can have one or many scenarios. So let's create a scenario right now. I'm typing do a quick check for cross-site scripting and verify no issues are found on the login page. Remember, the scenario needs to give the reader an idea for what is going on in the test. Try to use as plain English as you can. This scenario is clear on what we are testing for, what we expect to find, and where we are testing. Next, we need to get started running our tests. Let's make sure the tool we want to use is installed. This best fits into a given step. Let's add our given step. I'm going to say given arachni is installed, simple enough. This is telling Gauntlet to look in the path for tools it needs to run. In this case, it checks the path for arachni. Since we are using Gauntlet docker, it has arachni already loaded in the path available inside the container. I really prefer this approach to put the Gauntlet and all the tools that I want to use all in one container. This makes it easy for Gauntlet to access everything it needs and adds isolation of these attack tools to the rest of our development system. Okay, remember, the given step is all the assumptions for our test. Right now, our assumptions are incomplete since we have information about the attack tool arachni but nothing about the target, so let's add that. I'm typing and the following profile and giving a couple of values here. Gauntlet lets you add profiles with this simple statement to set up a name and a value, that makes a map here. Here I'm adding a variable called url that I can later use in other steps in this scenario. You probably noticed I'm using a long host name here, docker.for.mac.localhost. This is a special helper that docker provides so that we can talk to the host machine. And in this case we are talking to another docker container that is running the Gruyere application on port 8008 exposed on that host machine. If you are using Windows, you would replace this with the host name docker.for.win.localhost. You might have also noticed that I'm using some pipes here and I've got this table layout and I added some extra spacing and padding there. None of the spaces really matter, you could do that, I just did this for visualization. But the way it's laid out here with the name and value is important. So you always have to have the first row start out with name value and then you can put whatever values in below. Now our given step is all set up. Let's write our when step. I'm typing when I launch an arachni attach with and then I'm using some triple quotes here. Gauntlet uses these triple quotes to separate out what commands it's going to run. Even though this is several lines long, it is all one step. Let's fill in between the triple quotes right now. For the actual arachni execution, I'm typing arachni and then I'm adding some flags here. I'm saying xss checks, scope page limit of one, and then I'm passing in url. This runs arachni and the basic xss check and it only tests one page. Notice we are using the less than and greater than brackets to reference our url variable, which we set in the profile. Doing this is not required, but using this style helps you reuse these tests without hunting down hard-coded values. I could have easily just put in the value up above in the actual attack. Okay, this all looks good; the last thing we need to add is what we expect the result to be. For this, we will use a then step. I'm adding then the output should contain zero issues were detected. When arachni exits without any problem, it emits this message of zero issues were detected. We're just telling Gauntlet to look for this. Okay, let's run it and see if it goes. I'm typing gauntlet-docker and then I'm passing in the xss attack. Oh no, this failed. Now, don't get too worried; I was actually expecting this. This error says that it timed out because it took longer than three seconds to run. Well, we can fix this by marking this test as a slow test. I'm typing the @ sign and slow at the very top of the attack and saving it. By adding the slow tag to the top of the attack file, we're telling Gauntlet to let each scenario run for 30 seconds. Let's save it and run it again. Okay, now we see no errors and it runs okay. This got us running the xss payload in arachni and writing a check against the login page. We can extend this even further.