Tech catching an eye- IAST
By Pankaj Rane - Sep 4, 2018
IAST is Interactive Application Security Testing. It’s also been known variously as hybrid security testing, gray-box, and glass-box. It is somewhat a little bit newer into the environment. It’s been around for a few years or start to seize and bigger players come into the game offering this up and it's starting to become a little bit more mainstream and I think it's pretty interesting for devsecops.
This technique blends the inside-out approach of SAST (Static Application Security Testing) with the outside-in approach of DAST (Dynamic Application Security Testing) to give you deep code-level visibility of a running application while it’s in a real running state. This helps reduce false positives but still has the thoroughness limitations of black-box techniques in that it’s only as good as the test suite is run in terms of coverage.
Now I've got the request and response tied to the code and this is something that we've had an issue with when you look at just dynamic or static by themselves because if I just do static analysis I can look and I can see the code but I don't really know how it's going to fully interact.
Yes I can follow the trace and I can follow the data flow as it enters the system and flows through our code to hit the database or come back out to the browser but I don't really know how that's going to react when we put different inputs in there I can make some guesses at it but we're not running the system so maybe we're using regular expressions to test stuff and you know we just miss read a regular expression that happens so there's a lot of things that can go wrong there that we can't see.
The good thing about static analysis is we get a really good view into the code versus when we look at dynamic analysis we're just sending a request on looking at responses. we don't necessarily know what happens in the back as we're making the best guess. when things happen we can certainly say yes that's vulnerable but we don't have really good insight into that. then when it comes to remediate the flaws it can be a little bit difficult to explain.
You assume that okay I sent this request and now I'm seeing this response over here on this other page, now for a developer to have to go through and find where that is what line of code tend to be a daunting task you may go to the wrong spot so with IAST we get that request response but we also get the source code and the lines of code to go with that so we know right where the problem is so it's a huge benefit to what we've been doing with. Just one or the other and the way we do this is performed using instrumentation so you basically have to install an agent onto web server.
That agent will then instrument your application so basically allows it to monitor what the application is doing during runtime so that's how we're getting access into the request and response the actual source code goes through because it's inside your code it has the ability to see where that data is flowing right so I can see when I put input into the application. I can watch it through the source code and then determine hey did that go through any type of output encoding before we actually just sent it back down to the browser and if it didn't we know that we have an XSS issue that's how this works.
Performance Now there is a bit of drawback to it and you will see some sort of performance hit in the environment that you're running IAST because it's instrumenting the code is watching everything there's going to be a little bit of a hit there, now depending on your system setup that hit changes. Experts don’t recommend it for the production environment but it works fine for QA or some of these other environments but it's something you need to understand if you're looking at implementing these you know it's just one of those things that we have to get is a trade-off to get this out there.
Another issue is that if you want to test a certain piece of code that's going to get tested it monitors how my application is working similar to dynamic testing. I have to be able to hit the code now with dynamic scanners, we have spiders that go through and they find or attempt to find all the links and scan through. Oh! here are all the pages. here are all the form fields … let me try to attack all these that's not how IAST works right it's not spying your app like that it's actually going through and saying okay as you use it as function gets called we'll go ahead and review these and we'll look for security vulnerabilities so that's kind of good in a bad.
Good news is that it's going to help you understand the coverage that you're getting so if you're doing QA testing and you're running this then you could get a better idea of how much the app is actually hitting I mean source code are we touching when we're going through all the tests.
It helps to identify the code that we're not using but its out there so that's the benefit but at the same time if you're not covering that code during a typical test then you might have pieces of code that are being tested and those could slip through the cracks and you may have still vulnerabilities out there because you're not testing that code so just some things you want to think about as you consider looking at IAST for your application.
Is IAST going to replace manual testing?
No, it’s not going to replace all the testing that needs to be done, there is still need to have some manual testing. We need people to be able to go through and manually use the app and look for business logic flaws. In IAST you don't have to think about setting up credentials, there's no system doesn't need credentials because you're going to log in right as you use the application.
It's not a spider app so you don't have to provide credentials into it to go in and spider the app so don't have to worry about managing credentials as long as somebody on that environment has the ability log in and see it then they can go in or and it covers everybody on that environment so that's a good thing that was covered there so we don't need credentials.
I don't need to consistently think about how often am I uploading my source code for static analysis right because it's just in the environment every time I deploy to that environment it'll start looking at the new code now one thing I've seen from IAST is that it doesn't automatically close vulnerability as if they disappear so am I'm using the app it finds something it reports it but then it's kind of a free-floating item its not really checked later to say oh I found this before let me check to see if it's still there that's not really how it works.
It’s up to you to actually go in and manage those and say okay we found an XSS in between we fix that let me go close it and then what you're doing is basically waiting to see okay when I go retest this does it reopen or does it stay close so that's something to get used to a little bit because in a lot of other environments both dynamic and static analysis if I go in and modify the code and I've removed the vulnerability there's a good chance that vulnerability will drop off my report automatically. It doesn't work like that in IAST.
Checkmarx and Veracode have started offering IAST solutions lately.