Josh-CO Dev

Solving the worlds problems one line of code at a time.


1 Comment

Automating a WebInspect Scan using PowerShell and the WebInspect API

I have been struggling with the WebInspect API for quite some time now. It seems that I could always call the get methods just fine, but some of the post methods had some weird syntax that I could never figure out. After a lot of trial and error, I finally figured out how to use PowerShell to start a scan with the WebInspect API. I am posting this here hoping it will help out others. It seems that Google does not turn up anything on the API other than some HP help files which really do not help.

$wiapiScan = "http://vmwebinspect01:8083/webinspect/scanner" #set this to the location of your webinspect API instance

$body = @{
    settingsName="Default"    #the settings name to use for this scan
    
    overrides= 
    @{
        ScanName="Testing"    #The name to give the scan
        StartUrl="http://scrubbed"   #the url to scan
        CrawlAuditMode="CrawlOnly"   #crawl, audit, or both.
        StartOption="Url"    #refer to the API documentation for the other options
    } | convertto-json
} 

$response = Invoke-webrequest -Method Post -Body $body -Uri $wiapiScan #put it all together

Be sure that $wiapiScan is set to point to your WebInspect instance. Remember that the API has to be configured and started wherever you are hosting WebInspect. In my case, I am using a dedicated VM.


Leave a comment

Dr. Gary McGraw Software Security Keynote

Bug Parades, Zombies, and the BSIMM: A decade of software security!

I had the privilege of attending the HP Protect conference in Washington D.C. this year. I found it to be a great experience and I’ll see if I can’t get a write up of it going sometime in the near future. One thing that I did want to share was an excellent video from the software security keynote by Dr. Gary McGraw of Cigital. Very informative and entertaining.


Leave a comment

SAST – Static Application Security Testing

The other day we talked about DAST and how useful it is to organizations and the fact that only 60% of organizations have any DAST solutions in place. We also talked about how DAST is generally the first piece that is implemented when working with application security. Now, let’s talk about the second piece: static application security testing, or SAST.

SAST is generally the second step in application security. As we mentioned before, DAST will allow you to point a tool to a website, web service, or web application and crawl out the site and scan for security vulnerabilities. This will uncover things such as sql injection, XSRF, and XSS, amongst many other vulnerabilities. So what exactly is SAST then? SAST lets you analyze static code that is not already out on a production web server. Basically, you feed the tool your raw source code, the SAST tool will run the code through a built in compiler, and it will then analyze the code for vulnerabilities.

One big advantage this gives you is that you can scan code that is not only for the web, you can also scan code from various programming languages; such as C#, Java, C++, C, PHP, Python, PHP, and many others. The HP Fortify solution can scan something like 22 different languages. Another advantage is that you can scan code earlier in the SDLC. I have a CSSLP study guide on my desk that quotes IBM as stating that software vulnerabilties are 300 times faster and easier to fix early in the SDLC than they are in the testing or production phase. This makes it really easy to see why static application testing is so important. It makes the changes easier and faster to make, thus saving the organization time and money.

There is a lot of overlap in what the tools are scanning, so if you already have DAST in place, you are not going to get 100% efficiency out of a DAST tool. It mostly enables you to catch the mistakes earlier. There are also some things that each tool catches that the other tool doesn’t. Think of it much like a compiled programming languages. When you test your application you could get compile-time or run-time errors. Some errors are caught by compiler and some can only be caught by running the application logic. DAST and SAST tools work much the same way, one is testing your actual source code and the other is running the application and finding errors by actually running it and simulating a user.

Based on the numbers from Gartner, at least half of organizations are running DAST but an overwhelmingly minority are running SAST. In my organization, we are not doing any sort of application security at all, which is where my job comes into place. The plan is to actually start by implementing both at the same time, scan all of our apps, and eventually get a process in place so that app scanning is a part of the SDLC and happens automatically. Some of the major players, such as HP’s Fortify, actually have IDE plugins where the developers can run static code analysis in their dev environment and get immediate feedback from the tool. As far as major players are concerned, it’s really the same as DAST: HP Fortify, IBM AppScan, and VeraCode.

I think this is all pretty cool stuff, but I still have a lot to learn. I’m hoping to have a solution purchased in the upcoming weeks. If you have any comments, thoughts, or suggestions, feel free to drop them below. I’d be interested in hearing what you have to say.

This image from Gartner should give you an idea of the major players, though it is old and the game has changed extensively. Ounce was picked up by IBM and Fortify is now part of HP.