Jayesh Ahire

speaker
67 appearances 1 recordings 1 series first heard Oct 2024 last heard Oct 2024

Jayesh Ahire’s voice in public audio — every appearance, attributed to the second.

Trend

recordings per month · last 12 months
No recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.

Appearances

newest first · ▶ plays the moment
When we talk about security testing, traditionally, we talk about SaaS, DAS, IaaS to some extent, right? SAS being the static application security testing, DAS being dynamic application security testing. First thing, SAS, when we talk about SAS, it's purely looking at your code and trying to find what is wrong. And when you look at just a code, it doesn't have any context.
It's just lines and lines of code. You're going through it. You're going through some function and seeing... Maybe this is too wide open. Maybe this library is old. Maybe there's some problem with this specific. There's no dynamicity in it. And that's where the DAST comes into picture. But traditionally, DAST has always been more of a black box.
It's somebody sitting outside your system and trying to make an attack.
when that somebody is sitting outside your system they definitely don't understand your application well and that's where the false positives in the dash comes into picture but looking at the api specifically all of these tools like all of the traditional security testing tools operate at the application level the api interactions are pretty different when we talk about api specifically there's a lot to digest which is let's say you have thousand apis and most of these apis are
each other most of these apis are talking to third parties and when all of these interactions are going on the attack surface you have becomes very large and at the same time the amount of knowledge somebody might need to go and exploit the application is not something which you can replicate with it needs way more context it needs way more insight into the business logic of the application
And that's where the API security testing part comes into picture because with API security testing specifically, you're dealing with the APIs first of all. And you're making sure that all of these different interactions you're talking about, all of these dependencies, you're talking about the third parties. So we are replicating the business logic abuse at its truest sense.
Let's say, talking about something around payment gateways. So if you're sending the sensitive information about your user to the payment gateway, and that's excessive data exposure, that can only be caused at the APLF and DAS tools picking up on it or SaaS tools picking is pretty hard by definition.
Then another part is everything is evolving with all the things in place now with LLMs, with chat GPT, with even traditionally the cloud native development practices. Your applications are evolving so quickly that for traditional security testing tools to keep up with the
whole pace is pretty hard learning the context is pretty hard so that's where the contextual security testing on apis comes into picture and that's where i feel the api security testing becomes a better alternative to traditional tools when it comes to dealing with complexity which api brings into the whole conversation at the same time the continuous evolution we are seeing around the development cycles
Certainly. OK, that clarifies that for me. And, you know, how important, right, the testing portion of it is. And I imagine that, you know, when you don't get the testing right, finding a vulnerability after the fact can can lead to a significant problem. Can you share an example of how maybe one of these overlooked vulnerabilities led to a significant security breach?
Without naming the companies, I was in Australia back in 2022 and met CISOs of one of the major telecoms there. One thing, they went to the breach pretty recently at that time, and the breach was more leaking sensitive information, including passport details, phone numbers, addresses, a bunch of other things for millions of their users.
When we went through how it happened, the reason was they had one of these APIs which were publicly available. But that API was supposed to be retired way back. So they developed a newer version which had better security gates in place, which had better standards in place, which had weight limiting in place. They released it. It was still, again, it was accessible to everybody.
But at the same time, the older version, which they were supposed to retire, they didn't. And attacker exploited the exact old version to get all of the information for millions of their users. That was painful to watch.
And that's where the third category, which I mentioned, which is inventory management, comes into picture, where somebody actually exploited an older API, older version of the API, which was accessible even after it was supposed to be retired a long time back. There's also a telecom provider in the US, which also had a very similar incident.
And that was more around the web interfaces, which were in the play. And the APIs, the older APIs, again, which had weak authentication in place, were still publicly accessible, publicly available. Then Facebook went to something pretty similar back in 2018, where access tokens for 50 million user accounts are leaked purely because of the flaw in the business logic workflow.
and the authentication they had on those APIs was weak. Somebody found the vulnerability, exploited, and that resulted into the leak of 50 million user, 50 million access tokens for 50 million user accounts. When we talk about all of these things, you'll see that most of the issues or most of the exploits which happen because of very small issues.
When you look at these things afterwards, you feel like this was a silly mistake. But those small mistakes can result into a huge impact. like reputational impact, monitoring on organizations. Some of these things could have been easily avoided by having the right set of standards in place, having the right set of security testing in place.
But as the processes go, we always learn our lessons when we get impacted and then we start putting right things in place.
That's millions and millions of users. It's easy to see how important this testing is and how important it is to catch these vulnerabilities ahead of time. Now, I'm curious, from your perspective, how can organizations create an effective API testing framework that addresses these types of vulnerabilities?
One of the things which is very prominent and very important when it comes to this is having everything part of your development lifecycle. So if testing is part of your development lifecycle, it saves a lot of pain, it saves a lot of money because...
Showing 21–40 of 67 · page 2 of 4 ← Previous Next →