How to Security Test Your APIs

Micro Focus Expert
Micro Focus Expert
4 0 1,513

Micro Focus Fortify is proud to be the exclusive sponsor of the TestGuild Security podcast hosted by Joe Colantonio. This weekly podcast, dropping every Thursday, aims to be a 30 minutes or less, interview-style series speaking with some of the top Security Testing experts in the field.

How to Security Test Your APIs.jpgThe latest episode of the TestGuild Security Podcast titled, “How to Security Test Your APIs,” features Troy Hunt. Troy Hunt is a Microsoft Regional Director and MVP for Developer Security, an ASPInsider, and a full-time author for Pluralsight—a leader in online training for technology and creative professionals. 

While I highly suggest you carve out 30 minutes to give this podcast a listen, until then, here are 3 key takeaways I found intriguing during the interview! 

 1. Why Security Test Your APIs

“I think that one of the most significant things that will be new to a lot of testers, certainly testers that are more functionality centric, and certainly something that's new to a lot of developers, is that all of the communication that your device is having with these HTTP based APIs can be observed, can be intercepted, and can be manipulated. That to me is sort of the light bulb moment for most people. They say, so every time this app which I've built, own and trust is talking to these services that I also built and own, someone is able to sit there in the middle and see what's going on?

“Another thing is that apps tend to gobble up a lot of nasty security implementations. So, for example, on SSL, if you go to a website in your browser and the certificate is invalid, there's bells and whistles and bright lights that go off everywhere. But in your mobile apps, you see nothing. And as it turns out, a lot of mobile apps are either not using SSL correctly or at all or they're using things like invalid certificates.

“So, they basically got very, very poor implementations. So that's one. I guess the other thing that's really significant here is that we do have a bit of a gold rush still of Internet connected things, whether they be apps on mobile or whether they be the physical things in this continued Internet of Things world that we're entering. And what tends to happen when we have this gold rush of people trying to rush stuff to market is shortcuts get taken around things like security. So, I guess a combination of this and a little bit more abstraction between the consumer and the actual services that are being hit. And the rate at which these things are going out makes it a little bit of a perfect storm for vulnerabilities in our APIs critical.”

2. Your Data is Under Attack

“There's a device called a WiFi Pineapple that acts as an access point that you can connect to like any WiFi connection and dump every packet that goes through it. And we can then inspect that. So, the message there for something like the bathroom scales, or you can get a connected fork these days, all of these things are connected. For all of these things we can look at what are the services that it’s talking to, what is the data it's sending and also how the services responding. All of that can be observed and all of that can be probed.

“Interesting. So, in listening, for those that might be new to this or haven't seen the costs, might say big deal. Of course, all the data is encrypted. So, who cares if people could see my communication going on? What would you say to that?

“So, we've got to separate the issues. One of them is confidentiality insofar as can a man in the middle, let's say the NSA, because it's still kind of topical, see my data.

“They'll say the NSA is looking at what my body weight is. So, we're not too worried about that. At least I'm not too worried about that. I don't really care if the government wants to see my weight.

“What's more interesting though, is if I'm an attacker and I have the bathroom scales, a set of scales, and I actually look at the traffic patterns and I look at the services that it's calling in, the data that it's sending, could I possibly then exploit those services?

“So once I've discovered them, for example, the service which brings back data, can I change my user I.D. to someone else's user I.D. and get their data? Can I actually subvert the authorization protocols that are in there and pull back information I'm not meant to get access to? So that's the sort of thing that we're more worried about.”

3. Left is Cheaper

“But one of the things that we know from building software is that the further down the life cycle of development a change is made, the more it costs. So, for example, if we can change the way we want the thing to operate in the requirements phase, it's much cheaper than in the design phase, which is much cheaper than in the development phase, which is a lot cheaper than the test phase. The earlier we can make these decisions and solve these problems, the better.

“For me, that boils down to a couple of different things. And one of them is having well-trained developers that actually understand the Security paradigms. Because those are the guys that we most want to influence, because if we can get those guys right, when we do security scans right at the end of the project, we're going to find a whole lot less stuff. And it's going to be a whole lot cheaper to fix.

“I do like the idea of having dedicated security professionals who may not be developers and frankly, many times may not even be on the same planet as them, but they come at things from a very different angle with a different view, and they usually find things that the developer won't. So, I think it's good that they are in the process as well.

“Now then becomes a question of are we working in some sort of iterative Agile fashion where we can do that multiple times throughout the project? That's always a good thing. Or at the very least, let's make sure we do that at the end. And of course, the life cycle of an app doesn't just end when we release it either. So, is there any sort of continuous monitoring? The number of times I've seen someone push a change where they just change the error configuration to debug something and then six months later, it's still spitting out internal implementation data is too many. An ongoing continuous analysis is also a good idea.”

Hear the full interview, where Troy Hunt discusses many topics such as API security and many other security insights and perspectives. 

 

About Micro Focus Fortify

Fortify offers an end-to-end application security solution that secures and protects code throughout the entire development lifecycle of any type of software—from development to testing, release to production and every iteration in between. Fortify static, dynamic, interactive, and runtime security testing technologies are available on premise or on demand, offering organizations the flexibility needed to build an end-to-end software security assurance program.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.