Implementing Dynamic Application Security Testing (DAST) Tools into the SDLC

December 1, 2023

One of the questions that always came up at the end of my API talk was around Dynamic Application Security Testing (DAST) for APIs. I mention DAST in the talk but never really went more in-depth due to time constraints. The questions usually revolved around vendors. In this post I want to talk about how DAST works, I’ll mention vendors from my experience, and finally I’ll go over implementing DAST in the Software Development Lifecycle (SDLC).

HOW IT WORKS

DAST tests an application when it’s stood up and running, usually in a test environment. The test itself looks for the low hanging fruit because it’s running automated tests with no context or awareness of the business function of the application. It will run the same test against a finance system as well as an operational system. This tool is not a replacement for manual testing.

The tool will simulate what an attacker might do to an application. It will check for injection vulnerabilities and weaknesses within connections and protocols to the application. Again low hanging fruit so it will struggle with more involved techniques and misses simple things like URL enumeration and other abuse cases. Overall this tool is a great starting point for applications as it’ll capture a lot of the low hanging fruit but it won’t go much more in-depth than that.

Vendors

OWASP has a list of Vulnerability Scanning Tools AKA DAST available. The main ones I usually recommend are Tenable, Rapid7, and Invicti because I have familiarity with them. I always recommend evaluating multiple vendors before deciding on one. If you’re needing a DAST because of compliance reasons, I’d suggest Tenable or Rapid7 depending on which vulnerability management suite you already own.

If you’re wanting something for more than just compliance look at Invicti because that’s their only focus. This allows them to focus solely on the DAST technology. A Tenable or Rapid7 is looking at providing other security solutions not just DAST. From a low-cost perspective OWASP ZAP or BurpSuite are two free options that can be run manually or setup to automatically run in a CI/CD pipeline. The cost here is a resources time for learning and setting up the open-source tool.

IMPLEMENTATION

DAST is the easiest application security tool to setup in an SDLC. You need a URL, some login credentials, and a timeframe to scan. I recommend scanning as close to production as possible. Scanning in production is never a good thing because it’s throwing a lot of malicious types of attacks at an application. This can cause issues such as taking down the application or putting a junk data into your production environment databases. Scans can be setup to not be as aggressive but then it ends up missing vulnerabilities.

Scanning in a User Acceptance Testing (UAT) allows scans to run at the most aggressive level and not impact production. That is as long as the database isn’t shared with production. The only catch here is finding a time to run the scan so it doesn’t impact user testing. Scans can be setup to run in the afterhours.

The frequency of scanning should be based on how often code is released to UAT. If development is on two-week sprint then it’s reasonable to setup scans to run every two weeks. Some industries only require scanning applications once a month and that’s fine as well because as the vulnerabilities are addressed the need for DAST becomes less important.

Boom! Done!

Not so fast my friend!

Now that we’re scanning we need someone to look at and tune the results. This person should ideally be someone with application security experience because they’ll need to understand how the application woks or willing to dive in and learn. DAST has false positives. Not as many as a Static Application Security Testing (SAST) tool but it will have some. If results are taken from a DAST tool and sent to developers without any sort of vetting it will either tick off the development team or not get addressed. Often times both scenarios are the response.

If an application security person or someone willing to learn isn’t available then setting up a meeting with the development team to share findings and ask questions will go over a lot better. Developers are good people and love talking about their code (baby) and they’ll want to make sure it’s protected from the bad guys on the outside. This meeting will need to be a regular one for any new applications loaded into the DAST. As the vulnerabilities get tuned or addressed the meeting can be less frequent. As trust is built the meeting can become an email unless there’s some misunderstanding or a more complicated vulnerability needs to be addressed.

Summary

DAST is easy to setup but it’s the last tool to be kicked off. As more security tooling get’s implemented and the program matures the importance of DAST becomes less. It’s still a great starting point for any application security program. Always evaluate multiple DAST vendors. If it makes sense to go with a DAST that is already part of a suite of other tools then go with that.

The strategy for implementing DAST is the same for web applications as it is for APIs. You won’t see as many results for APIs because their use is more restrictive than a website. The main concern with APIs is authentication and authorization issues. DAST will be able to call out weak protocols but it will not be able to identify if a person has the access they need. Remember to work with the development team on getting DAST setup because their help will be needed for addressing vulnerabilities.

If you’re looking for an API vendor focused on testing, I’d recommend 42Crunch.

Drop a comment below if there are any questions or other topics you’d like me to cover. If you’re interested in services I have sponsorship, consulting, and speaking engagements available. Reach out via the contact form.

This blog post first appear on Exploring Information Security.

Application Security resources for beginners

October 29, 2018

This is a continuation of my resource series of posts. Application security is the field I found a lot of interest in. This despite coming from the operations side of IT not development. Using the resources below I was able to get a job in application security.

Websites:

I first realized I had an interest in appsec after reading a Troy Hunt post. Not only were things explained well, but I was also paying attention to every word in his blog posts. He has since branched out to more breach related content as the creator and maintainer of Have I Been Pwned. Still he has a lot of good appsec content. He has several courses on Pluralsight for beginners plus. He also does a weekly podcast that’s worth checking out.

The Open Web Application Security Project (OWASP) is the go to resource for AppSec. It’s a massive non-profit organization that has tons of projects, knowledge bases, cheat sheets, and more. There might even be a local OWASP chapter. There’s annual conferences to attend (I’ve never been). It’s the resource I recommend for people starting out.

Podcasts:

DevelopSec
Application Security Podcast

James Jardine puts on the DevelopSec podcast. The podcast is targeted at developers. It’s also consumable by security people. This podcast doesn’t release on a regular schedule. The Application Security podcast is also targeted at developers. It releases in seasons.

Training:

The first bit of AppSec training I got was the SANS SEC542 Web Application Penetration Testing and Ethical Hacking. It’s a lot of AppSec information, concluding with a Capture The Flag (CTF) exercise. I’d try to get your organization to pay for this as it’s several thousand dollars.

The Practical Web Application Penetration Testing course is a Tim Tomes course. He’s a former SANS instructor who puts on this training several times throughout the year in public and for organizations. It’s a great affordable course that Tim tries to keep up to date with relevant information.

The blog post first appear on Exploring Information Security

Pragma and Cache-Control

June 26, 2017

I’d like to start posting more on my website. One of the ideas I had for doing that is to write about some of the more obscure things in application security. My career has been almost entirely on the job training. This comes with the challenge of trying to understand explanations that sometimes don’t state obvious ideas and concepts. I’d like to cover some of those obscure topics and really dig into them. In the process I’d like to try and answer them in a way that my younger self can understand. I’m hoping this will provide others with a simpler explanation while helping me to better understand the concept.

To kick it off, I’d like to cover pragma and cache-control. The reason why is because I see this regularly in reports from ZAP, “Incomplete or No Cache-control and Pragma HTTP Header Set.” It’s a low or information finding and it usually shows up in a lot of places. I did some research to better understand the finding several weeks ago.

What is pragma and cache-control?

Both are header settings for the browser. Before we get to far, I guess I should explain what are HTTP header settings. These are settings that the application will communicate to the browser to determine how they interact together. In the case of pragma and Cache-control the application is telling the browser not to cache any content or don’t keep any content pulled down in the browser after leaving the site. The reason is so that sensitive information doesn’t get stored in the browser for a malicious actor to take advantage of if the person’s computer is compromised. For a more in depth explanation on HTTP headers check out this article, HTTP Headers for Dummies.

Pragma is an older header setting for HTTP/1.0. Cache-Control is the newer header setting for HTTP/1.1. What that means is that pragma is used to control cache for older browsers. If older browsers are being supported by the website or application then setting that is important to ensure sensitive information isn’t being stored. If older browsers are not support then just cache-control is used. In some cases you may have both. The Mozilla Developer Network has a pretty good explanation. There’s also a good explanation and discussion on Stack Overflow if that’s your thing.

How and where to set pragma and cache-control?

Where the header settings will depend on the application and what is being sent as content to the browser. The only setting for pragma is no-cache. Cache-control has more directives to set for flexibility. Max-age and revalidation are two directives that can be set. The browser will have to stick to those settings. The recommendation I’ve seen is to set pragma with no-cache and cache-control with no-cache, no-store, must-revalidate, and private.

These settings are set in either code or on the server. How implementation is done depends on the language and technology used by the application. Google is a good place to look for how to set these settings based on those factors.

Simple as that.

Hopefully, this clears up some confusion for people. Writing this down has helped me understand it a little better. I hope to do more of these types of articles in the future. I would love feedback on this post. Also feel free to drop a comment if I missed something in the explanation.

References:

This blog post first appeared on Exploring Information Security.

Converge and BSides Detroit talks and slides

May 21, 2017

I had a great time at Converge and BSides Detroit.

This was my third attempt at going and I'm happy I finally got the opportunity to do so. The last two years I've had to cancel my plans due to life reasons. I did two talks this year. One at Converge and one at BSides. Both are linked below along with the slides for both talks.

How to kick start an application security program - Converge Detroit

I've given this talk at three other BSides prior to Converge. I feel like this is my best presentation of the talk so far. I will be giving it again at ShowMeCon in June.

Slides

The AppSec Starter Kit - BSides Detroit

This was my first time giving this talk. I thought it went well for it's first attempt. It still needs polish. It will probably be a while before I give this talk again at a security conference. I made this talk to present at developer conferences. It hasn't been picked up, yet. I'm hopeful it will for some talks later this year.

Slides

This blog post first appeared on Exploring Information Security.

Leveraging the security mindset of others

November 21, 2016

I am over six months into my new role as a senior software security engineer. My role has me embedded with the development team. I go to meetings and interact with the team on a day-to-day basis. My desk is in there area. I go to lunch and conferences with them. As I’ve gotten more familiar with the environment and team, my task list has started to grow.

One of my co-workers noticed this and while leaving a meeting the other day asked if security had plans to hire another security person. I responded that I thought they might in the future, but that I wasn’t counting on it. It took two years to fill my role. With the current “talent shortage” it may take another two years to fill a similar role.

My strategy for getting security into the software development life cycle is to leverage the skills and knowledge of the developers. They are really smart people, so I put a focus on improving the security mindset of the developers. In meetings, I let them to talk through security issues and find their own solution. Just me being there the developers know that security needs to be taken seriously. For the most part they choose the right path.

I also recognize when security issues are identified and addressed by the development team without my involvement. The development team is already doing a lot of good things from a security perspective. By recognizing that in a meeting or one-on-one I am amplifying and encouraging that type of behavior. Using that strategy, I’ve started to see improvements in the development team in regards to security. The other person I was discussing this with agreed. They were seeing more focus being made on security.

Do we need more people in security? I don't know. What I do know is that the security industry is having a tough time finding the right people. Maybe we need a different strategy. I think that strategy should include leveraging the security mindset of others. I've had some encouraging results so far. It will be interesting evaluate the strategy a year from now.

This post first appeared on Exploring Information Security.

Security and SDLC: Getting started and working with others

January 28, 2016

Getting security into the software development life cycle (SDLC) seems easy. Just write good code and wallah security is in an application. That would be nice, but unfortunately, it doesn’t work like that.

The very first step to implementing security in the SDLC is to have support from leadership. I was lucky enough to have that when I was tasked with this responsibility. Before a new application went live, management asked if security had reviewed the application. Simple. Sweet. It made my job a lot easier. I didn’t have to constantly track down applications or bang the developers over the head. They were coming to me. Which was important in improving the process as the security assessment program matured.

The next step is to get familiar with the tools. OWASP ZAP and Burp Suite are two low-cost tools that can help with performing a security assessment. ZAP is free and Burp Suite costs $350 for the professional version. I’ve covered ZAP in a previous post. Both tools have plenty of resources available to start diving into.

I highly recommend training. I took SANS 542 and it helped tremendously. I learned a lot about the methodology and vulnerabilities associated with application security. If you happen to be in the southeast you may be able to catch a Tim Tomes training course. Troy Hunt’s stuff on Pluralsight is also a really good resource.

Security should be implemented at all stages of the SDLC. Which means a security person should be involved in the early stages, as well as the late stages. The should be at planning meetings making recommendations. They should also be tracking and checking in on progress. Towards the end is where the actual security assessment occurs using tools like ZAP or Burp, but the work doesn’t end there. Confirming findings and generating a report starts the next phase. Finally, Remediation is an important step and requires working closely with the development team.

Working with developers and system administrators

Working with other departments is vital in implementing strong security. For simplicity sake I’m going only going to mention developers. However, don't forget the system administrators. Developers build the applications and the sysadmins are the ones that maintain it. Some findings will require the help of sysadmins configuring the servers that run these applications. Do not overlook them.

There are two big no-nos in working with other departments. Not confirming findings and not providing guidance on findings that need to be resolved.

Confirming findings is very important. Each false positive that a developer finds is credibility the security team loses. Developers have enough on their plate, with applications to build and ambitious deadlines to meet. They don’t need to spends hours on a problem only to find out that the security team made a mistake. Scanners do make mistakes. Make sure each findings are confirmed and can be explained. This goes along with the second part.

Work with the developers to resolve the findings. Vulnerabilities in code will need the security team's help in remediation. Developers are really smart. In my situation, a lot of the time, the developers knew how to fix the issue. But other times, I had to help them research a solution. New vulnerabilities are being discovered daily and it's the security team's responsibility to be on top of them.

One of the benefits of helping developers resolve issues is that it gives us an opportunity to build a better relationship with them.

Building a relationship allows for an easier transition to security. As I mentioned earlier, developers are under a lot of pressure to get things up and out. Security can come in and add more pressure or it can allow them to make better applications. Enabling them to do their best is our goal. A relationship with the developers will make that transition much smoother.

How to build a better relationship

Ask the questions. People love talking about what they do, especially, if they’re passionate about it. Ask questions and show an interest in their work. Coming from a non-development background meant I had a lot to learn. Which gave me plenty of opportunities to ask questions. By making an effort to understand their work, I gained credibility as a problem solver. I showed that I wanted to understand their work.

Help solve the problems. ZAP reports have a reference and solutions section. Go through those. Get on Google. Review YouTube videos. Read blog posts. Do whatever is needed to understand the fixes for code. Then dive into the code with the developers to understand the fix. Provide the developers with as many resources as possible to get the job done and then learn from them.

Teach them the tools. This goes back to implementing security at all stages of the SDLC. The earlier issues are caught, the less it will cost to resolve. This is where leadership support comes into play. With leadership ensuring that the SDLC ran through the security team it helped create the story below.

Storytime

After running several security assessments for new applications, the developers wanted to know more about the tool I was using. If they’re going to have to run an application by me, they want to understand the tool I'm using. Each time I found something meant time we had to go back and remediate and then re-scan. So, I started showing them how to run ZAP. I did one-on-ones with developers and held training sessions on the use of the tool. Something amazing happened as a result of that.

One day, we started receiving reports that a scam email was being sent to customers via our service. The thought was that as people signed up for a new account, they would receive a scam email. Not something we wanted to take lightly. While I investigated the message of the scam, I asked one of the developers to go create an account. The idea was to see if the scam email did in fact come after account creation. So he did.

He returned to me and told me that there was no scam email after account creation. He then handed me the ZAP report. Wait. A ZAP report? Mind blown. I hadn’t even asked him to use ZAP while checking for the scam email. I had intended to do that myself, but he went ahead and did it.

That likely doesn't happen if leadership isn't committed to security.

*By the way, ZAP wasn’t built by someone in security. It was built by Simon Bennetts, a developer. This tool was built by a developer, for developers. Security people just thought it was a neat tool.

Conclusion

Leadership support is important to the successful implementation of security into the SDLC. Tools are a wonderful way to get started with finding vulnerabilities. They are by no means perfect. As the program matures more manual and in-depth testing is needed. Training can help with that. Also, stay on top of the latest application security news. There's something new every day.

Security needs to be implemented at all stages. Which means attending developer planning meetings. Tracking project status. More importantly, understanding the business needs in application development. Interviewing and meeting with project managers and developers individually.

Finally, work with the developers and sysadmins to resolve issues. Be there as a resource and a student to their craft. Ask questions. Solve problems. Teach them the tools. It will go a long way in enabling them to be better.

This post first appeared on Exploring Information Security.

Blue Team Starter Kit - ZAP for application security

November 30, 2015

I remember hearing about ZAP on my ride into work, listening to Security Weekly. After a little researched I discovered that it was a tool supported by the Open Web Application Security Project. OWASP is an open source non-profit organization focused on providing better application security to organizations. The best part about the tool is that it is free!

What is ZAP?

ZAP stands for Zed Attack Proxy. Named such by Simon Bennetts who told me that he really wanted to name the tool ZAP (OWASP. Bugs. Get it?). Simon is not a security person by trade. He’s a developer and built the tool to help developers write better code. It just so happened that security people found the tool and started using it.

Setting up ZAP as a proxy allows for a tester to run through an application and find vulnerabilities. It uses the methods in OWASP’s Top 10 as part of its scan. I’ll get into the methodology of using the tool later. This automates and streamlines a lot of testing. Beware, the scanner is not perfect (no scanner is). Confirming vulnerabilities found by the tool is a very important part of the process. One false positive with developers and we lose credibility.

After testing is complete ZAP has an export report feature. The report can be exported in either an HTML or an XML format. The HTML is great for working with developers and researching and confirming each finding. With the XML format, a tool like ThreadFix or Dradis can be used to help track vulnerabilities.

The tool also has advanced features for further digging into the application. This is great as a tester gets more comfortable and better with the tool he has an opportunity to dig deeper into an application.

The alternative

The alternative to ZAP is Burp Suite. It does a lot of the same things that ZAP does with some minor differences. Burp has two versions: A community version (free); and a premium version (paid). The premium version costs $300 a year. For those looking to make a career in application security, getting familiar with Burp is a must. Learning both is a plus. Each tool has it's strengths and weaknesses.

How to get started

Download ZAP from the OWASP website and install. Launch the application. The first screen you will see is asking, “Do you want to persist the ZAP Session?” Persisting the session will allow you to close and re-open the ZAP session quickly. You can either:

YES Persist: Save it in the default directory (first option)
YES Persist: Specify the name and location (second option)
Do Not Persist: Or don't bother (third option)

If you intend to save your own sessions then select the third option.

One of the first things available when ZAP opens, is the Quick Start tab. This can be used to perform a very quick, top-level scan. To dig much deeper into an application it will need to be setup as a proxy. To do this go to: Tools -> Options -> Local proxy.

Select your settings (or leave everything default). Then open internet options. Click the Connections tab and click the LAN settings button. Under the Proxy server section check the box for “Use a proxy server for your LAN.” Make sure the Address field says "localhost" (default) and the Port field reads "8080" (default). Click OK and then Apply. ZAP is now intercepting all internet traffic. This includes any browsers or applications using the internet. I recommend running the application assessment from a separate machine or virtual machine. As a proxy it will collect all internet traffic your computer performs. Including browser traffic and any updaters installed.

Now that we’re setup, time to test.

Methodology

Run through the entire application. When I say the entire application, I mean the ENTIRE APPLICATION. Click on every link and button. Fill out every field and submit forms. This is best done in a test environment which developers should have. Coordinate with them for any functions that need handling on their end. Once the application has been explored, it’s time to use ZAP to map the rest of the application.

Before we do that though, it is a good idea to exclude any sites you don’t want to run ZAP on. Right-click any sites you want to exclude. Select Exclude From Proxy and click OK. There is some flexibility here, but for the most part I just exclude the sites from the proxy all together.

To map the application ZAP uses a Spider. Right-click the site, highlight Attack, and select Spider. The spider will run through the application and map it. The more the application was explored by the tester, the more it will find. ZAP also features an Ajax Spider attack for ajax content. This will open a browser, run through the website, and map the ajax content in the application.

After running the spider function, run the forced browse attack. This function will use a text file with common directory names to look for hidden directories. This attack can usually take several hours to run, depending on the size of the list. ZAP supports user created lists.

Active scan is run next. This is where discovery of vulnerabilities of the application occurs. The function will run through techniques in the OWASP Top 10. Clicking on the heartbeat monitor icon will allow you to watch the progress of the scan.

I want to mention one other type of attack that may or may not be used. The Fuzz attack or fuzzer. This is typically used for things like user enumeration (username discover). The attack allows for requests sent to be modified using a text file. This allows for the automation of sending many modified requests to the application. Viewing the responses we can build a list of usernames in automated and quick fashion.

Once the Active Scan completes we have a (hopefully not long) list of vulnerabilities. Export and view a report of the findings by clicking Report -> Generate HTML report. The report includes:

The type of attack
A short description
The vulnerable link
The attack
The solution
References.

Once the vulnerabilities are confirmed or rejected, it’s report writing time.

Conclusion

OWASP ZAP is a great tool for those just starting out in application security. Or those needing to stand up a security assessment program. The instructions above are meant to just get someone started with using ZAP. Both ZAP and Burp Suite provide a lot of granular control of and customization of it's features and functions. But both are very simple to use. Both are well documented (check the more resources section below).

If $300 is within the budget, Burp Suite is the tool of choice by application security professionals. I've tinkered with Burp Suite, but for the most part I've used ZAP. Free is hard to beat, but it also came in handy working with developers. As I was implementing the security assessment program in my organization, I quickly discovered that the developers were interested in the tool. That probably had more to do with managements support of the program. Still, when the developers started asking questions on how I tested, I simply installed the tool on their system. From there I showed them my techniques for performing assessments. Now, I'm easily showing the developers how to run their checks of the application before it even reaches me.

I probably could do the same with Burp Suite, but I have a few more hoops to jump through with the $300 price tag. The community version does a lot of the same things the premium does. It's just throttled. Again, if you're sure application security is where you want to be $300 is not an insurmountable amount of money. If you're still feeling out the field ZAP works is the best bang for your buck.

More resources

OWASP Zed Attack Proxy Tutorial - YouTube
Lanmaster53 - Tim Tomes (he provides training too)
The Web Application Hacker's Handbook 2nd Edition by Dafydd Stuttard
SANS web App Penetration Testing and Ethical Hacking Course

This post first appeared on Exploring Information Security.