South Dakota Information Security

Good day, eh. Welcome to Part 3. In this post, we will spend a little time walking through how to perform active scanning with ZAP. I'm gonna level with you, this is probably the easiest part of workin with ZAP, but it is also the most perilous. Web scanners have taken down sites, and if the scope isn't configured properly you could find yourself winning an extended stay at Club Fed (located in beautiful Leavenworth, Kansas). As always, don't scan stuff that isn't yours or that you don't have permission to scan. Got it? Good. Let's move forward. As you may or may not know, OWASP ZAP can perform two different levels of scanning: passive scanning and active scanning. Our tutorial will focus on active scanning, but I think it is worthwhile to have a brief discussion about passive scanning. Passive scanning is the scanning that takes place when ZAP is interacting with a web application through any other process other than an active scan. What this means is that

If you completed part one of this series, you have now successfully intercepted an HTTP request and response with OWASP ZAP. Don't you feel proud and empowered? I knew you would. But guess what? We're not done yet... not by a damn site. Now it's time to learn how to  crawl  a web application with ZAP. Now I know what you're thinking to your self. Your thinking, "Pablo, why do I need to crawl the site? Can't I just do an outright scan? Won't that crawl the site first anyway?" Well, the answer to your question is "yes," you can just scan the site, which usually starts with a crawl. But here is the deal, maybe you don't want to be noticed, especially if you are doing a test where stealth is important. Have you ever worked on a blue team and had your email inbox explode with alerts because some jackhole decided to scan your company's website? If so, then you understand why running a full scan might not be desirable (you may also wa

So you want to use OWASP's Zed Attack Proxy to intercept web requests and responses, but you don't know where to start. ZAP isn't quite as pretty as Burp and there isn't even a proxy tab that you can use to intercept traffic and monkey with the parameters! What is the deal!? OK, OK, OK, just take a chill pill there my friend. Although ZAP is a little different from Burp, I think you will find that it is just as useful, and in some cases perhaps more so. Let's jump in with a little exercise that will help you figure out the basics of this often overlooked gem. Before going any further, I am going to take a moment to warn you about testing web applications without permission; don't do it. Testing a site that is not yours is what a friend of mine has referred to as a "non-extradition country career choice" (thanks Adrien de Beupre). Equador is a lovely country, but you probably don't want to live there. Manually Intercepting HTTP Requests and

Burp Intruder is a powerful tool that allows you to automate both canned and customized attacks against web applications. If you are using Burp Community Edition, Intruder has time constraints on it that limit its usefulness. With that said, even a restricted version of Intruder is useful. If you want the un-throttled version of this tool, however, you will need to pony up some dough and buy the Burp Suite Professional. Burp Intruder has a number of configuration options and it can be used to perform many different types of attacks. In the future, I will try to put out a post that covers some more advanced uses of Intruder. For the purposes of this post, however, we will perform a basic test against or JuiceShop instance that is hosted at Heroku. You can learn more about the Intruder tab at  https://portswigger.net/burp/documentation/desktop/tools/intruder . I highly recommend spending time reviewing this page, as it provides a great deal of information about some of the more advanc

In my fourth post, I will spend a little time talking about the Repeater tab. Repeater is somewhat similar to the proxy tab in that it allows you fiddle with HTTP requests, but it is better because it allows you to change and repeat requests over and over again without the need to flip back and forth between the browser. I have found that I spend a great deal of time in this tab, usually after I have tested something in the Proxy tab. In my experience, Repeater is one of the most useful tabs in the Burp suite. Let's take a look at how to use Repeater when testing our test JuiceShop site. In Burp, go to the Proxy tab and make sure that the intercept option is set to “on." With your browser running through Burp Suite, go to https://sf-owasp-juiceshop.herokuapp.com/#/contact . Fill out the form and submit it. Note the ‘comment’, ‘rating’, and ‘captcha’ parameters in the request. Don’t make any changes to the parameter values yet. Forward the request on to the server and

Welcome to part three of this series. In this post, we will discuss the Proxy tab and how it is used. Using the Proxy tab in Burp, you can manually intercept and alter HTTP requests and responses. This can be useful if you suspect that there may be an issue with a page and you want to tinker with it. Repeater, which we will look at next, can also do this but it is a bit more involved. If you are looking for a quick and dirty way to test a parameter, this is the place to start. Open Burp and enable proxy settings for it in Foxy Proxy.    In the browser, go to https://sf-owasp-juiceshop.herokuapp.com/#/search .    In Burp, go to the Proxy tab and make sure that the intercept option is set to “on.” In the Proxy tab click the “Options” sub-tab.    Scroll down to Intercept Server Responses and check the box labeled “Intercept responses based on the following rules."    In the same section, check all of the options that are listed in the box.    In the browser, click on the pro

This is the second post in Burp tutorial, and in it I will discuss the Target and Spider tabs and their functions. I will also give you a short exercise that will help you understand some of these functions. The Target tab is the default interface when Burp starts and it has two sub-tabs: Site Map and Scope. The Site Map tab displays sites that have been proxied by Burp and it details the identified structure of those sites. This tab is broken into three different panes: the site map window (left side), the connection history window (top right), and the request/response pane (bottom right). The second sub-tab in Target is the Scope tab, and it allows the user to add and remove URLs from the scope. Setting changes made in this interface affect the rest of the application. When working in Burp, one of the first things you should do is set the scope of your test. This will help prevent you from testing applications which you do not have permission to test. Setting the Scope and Filt

Well, here we are. I recently needed a presentation for the December 2018 OWASP Sioux Falls chapter meeting, and I thought to myself, "Self, you should talk about interception proxies, specifically ZAP an Burp." If you aren't familiar with interception proxies, they are tools that are designed to intercept, analyze, and manipulate web requests and responses. These tools allow the user to be a man-in-the-middle between the browser and the web server. These posts are going to be a bit "to-the-point," as they are intended to be give instructional guidance. This is the first post in the series, so pour yourself a nice drink, put on your favorite hacking music, and jump on in. Note: these posts reference an instance of JuiceShop that is set up on the free tier of service at Heroku. The site not maintained and it may or may not be available when you want to test it. If you happen to find that the site is down, you can set up your own JuiceShop instance in Heroku fo