AI Powered Web Application Protection with Fortinet
Fortinet’s approach to securing AI workloads involves a layered defense strategy. Their presentation at Cloud Field Day 24 demonstrated SQL injection (SQLi), Server-Side Request Forgery (SSRF), and model manipulation attacks against an AI-powered application using the Model Context Protocol (MCP), showcasing how Fortinet solutions protect at each stage of the attack kill chain. The demonstration highlighted the vulnerabilities introduced by AI agents and the importance of securing this new attack surface.
The presented environment, deployed in AWS as microservices, features a vulnerable e-commerce application (“Juice Shop”) augmented with an AI chatbot. Traffic between VPCs is routed through a security services VPC, where FortiWeb (web application firewall) and FortiGate provide inspection. The attack flow involves a user interacting with the chatbot, which then communicates with a large language model (OpenAI) via MCP. This interaction exposes vulnerabilities, as demonstrated by an attacker successfully injecting SQL code through the chatbot interface, bypassing traditional web application firewall protections.
Fortinet demonstrated how FortiWeb’s machine learning capabilities can detect and mitigate these attacks. By learning normal application traffic and building a model of expected API behavior, FortiWeb can identify anomalous requests, such as SQL injection attempts. The system then evaluates these alerts, leveraging its threat intelligence database to determine appropriate actions, including blocking malicious requests. Furthermore, FortiWeb’s AI assistant provides detailed analysis of attacks, including remediation recommendations, and generates API documentation to keep up with rapidly evolving pre-built APIs.
Presented by Derrick Gooch, Consulting System Engineer, Fortinet, Srija Alam, Cloud Security Architect, Fortinet, and Julian Petersohn, Principal Systems Engineer, Fortinet. Recorded live at Cloud Field Day in Emeryville on October 21, 2025. Watch the entire presentation at https://techfieldday.com/event/cfd24/ or visit https://www.fortinet.com/ for more information.
Transcript
Uh, my name is Derek Guc. I'm, I work on Aiden's team. I'm a consulting cloud architect at Fortinet.
So help our customers understand how to integrate our solutions with their cloud applications. Um, so, uh, what we wanted to talk about, again, some of the feedback we got last time was we didn't really do a very good job of explaining how the traffic was flowing and how we were inserting security services into that traffic. And so I wanted to kind of run through the lab environment today and the application that we've built, um, and, and just kind of walk through what's happening.
So this is the, the overall environment. This is a very high level view. Uh, on the right, you can see we've got an e-commerce server, uh, and that's, uh, we use juice shop.
We use it quite a bit because it's kind of a, a really vulnerable sort of, if, if I had an application like this in my network, it'd be a worst case scenario, right? It's very easy to hack. Um, and it is designed that way.
Um, so, but what we've added to that is, as Aiden mentioned, we've, we've added an AI agent because this is a, a chat bot. Essentially, our customers are, are doing this to help their customers navigate through their products, maybe even do some, some e-commerce, um, uh, purchasing through, through the app. And so, uh, the AI agent is gonna speak to the MCP server as well as, um, the, the large language model.
And then, you know, we, and I wanna walk through how that interaction sort of happens, because I think that helps to understand, um, when we start talking about how the security is applied. com into, uh, you know, into their browser. And then they're gonna go and be presented with, um, uh, just a very simple gui.
And in that GUI they're gonna type a question, do you, do you have any apple juice? And so that, that agent actually knows already about some tools that it has because of the MCP clients that are, that, that it has installed. So I know about tools X, Y, Z, um, from my M-P-C-M-C-P server.
So it's gonna take that information plus the prompt that was pre-configured. And I've simplified this prompt, right? Uh, you're a helpful assistant, uh, who will assist customers with purchasing products from our e-commerce site.
Now, quite often when you look at AI agents, the prompts are much, much more complicated than that. Um, but this one, you know, sort of simplified. So the, the important thing to remember here is the agent doesn't really know anything other than I've got these tools, and this is what the customer's asking.
So it's gonna send that information, uh, to our AI cloud service, in this case, our large language model, which is OpenAI. So OpenAI is gonna take that information and it's gonna chew on it, and it's gonna say, okay, there's a tool I'm gonna do. Uh, I'm gonna call this make a tool, call search products, and I wanna look for Apple juice.
That traffic, the AI agent then makes, uh, uses an MCP client to make a JSON RPC call, uh, to our MCP server, which then in turn translates that into a standard restful. API call pulls the information from our e-commerce app, and then provides that back to the large language model via the agent, the large language model, then choose on all that information. It says, in fact, yes, we do have apple juice.
A thousand milliliters is available for a dollar 99. Do you want me to add it to your cart? And this is pretty standard fair.
And, and this is exactly how the interaction would continue to move if, if the, the customer decided they did want to in fact add apple juice. And, um, we're gonna see, Julian is gonna walk through this process, uh, today during his attacks, and you're familiar with this one, but I, I wanted to kind of do an overlay of that, that similar traffic flow onto the actual environment. So we've got this deployed in AWS as a a series of microservices.
And so we did that for the purposes of segmentation. And also, um, you know, we we're, we we're using the transit gateway, as you can kind of see in the diagram. That's the thing in the center if you're not familiar with AWS icon iconography.
Um, so, uh, all traffic that trans that moves between our, um, VPCs our traffic or our, uh, application VPCs, if you will, uh, is sent to the security services VP C. And whether it's, uh, proxy in, in the case of for web, or whether it's, um, you know, uh, some other kind of traffic that, you know, internal segmentation via for gate, uh, that traffic is, is inspected into security services VPC. com, they're actually, um, that is associated with an ip, a public IP address, which is on Florida Web.
So that's our web application firewall, as Aiden mentioned, web application, API firewall. And I'm not gonna get into great detail about the protections we have in place 'cause Reja is much better at that than I am. So she's gonna talk in, in pretty good detail about how we are defending against these attacks.
But when the attacker is logged into the gui, they're logging in through for web, for web is also Char serving as a reverse proxy for the traffic between our, uh, AI agent and our MCP server. And so, and the same thing goes for web is also proxying the traffic between the MCP server and our application BPC or our, our, uh, e-commerce server. And so this gives us an opportunity at all of those steps to insert, um, you know, layer seven oasp protections for that traffic.
We also have traffic going out from the AI agent to the Florida FortiGate, and, and again, I'm sorry, not to the FortiGate, to the large language model. And we have all outbound traffic in this environment going out through a FortiGate. And we do that for a couple of reasons.
Uh, we are able to use, uh, we are able to insert, um, layer seven security services, uh, by, by sending that traffic through FortiGate, and we're able to do, um, intent-based dynamic policy. So we can take, we learn, uh, metadata information about the various devices, and then we can create a dynamic security policy based on what we need that device to be able to do. And so that's kind of a large part, Uh, for the outbound.
So, and again, Aiden mentioned four to C nap. Uh, in this case, we're gonna be looking at some anomalous traffic. We're gonna see, you know, somebody's logging in from a different location, um, and a among other things.
Uh, but that track, that information is gonna be shared with for desso as, as well, you can see for analyzer. So, um, for GATE and for Web, are sending logs to for Analyzer, which is parsing 'em into events and then sharing that with, for Desar and ultimately for Desso is what we'll use to do, um, an automated mitigation. And so that being said, um, one thing I was thinking about your question, and I think the, the big thing about, you know, what's so different about this, uh, protecting this traffic is, I wouldn't say it's super different.
Um, the, it is just that the, if you think about it, the agent is another, another, a new attack surface. And that's the thing that we're gonna sort of gonna sort of see. And, and of course with that new attack surface, there are some new challenges Asen Aiden mentioned.
All right, demo time. Woo hoo. So demo time.
Hey, I'm Julian Peterson, I'm your bad guy today. And, um, maybe some of you may know I tried to break into three chest juice shop already multiple times. Uh, luckily for her, I never really made it that far.
Uh, but I'm happy that I still got my juice at the end and, uh, well, today is my new attempt to exactly do that. Again. Let's break into the juice shop.
And for that I already prepared. And maybe just to demonstrate you how Juice Shop can look like, uh, we fortified it a little bit, uh, just because for fun, but Sweeter has a really good juice shop here. I also have my own, but it's not that cool.
And my challenge was always, she's a competitor. So my idea initially was, I think it was now two years back to buy all her juice, sell it on my platform because she's out of stock. I can now increase the price.
It's pretty tricky thing, but it was the initial idea and I didn't really succeed on that. And the idea for today is, you have heard it already, I don't know about it. Officially, there is a chat bot nowadays and what I've learned and think we also learned that for many years ago with chat bots, they make our life pretty easy and allow us to buy like cheap cars, like for $1.
You can get your Chevy today, or, uh, maybe you can get even free, uh, flight tickets. And my idea is, hey, it seems like that there's a big gap in security on when such chatbots are added because it's like, you can do whatever. And well, here we are, we have a little chat bot.
And the the neat thing here is it's like we can start with, Hey, what can you do for me? Right? Uh, I don't know.
It's like, let, let's be surprised. What, what can we do with the chatbot, actually, uh, fair to say, first of all, I hope really the demo got up with us today. Uh, it's, uh, we tried it five times and had five different results.
So LMS are pretty interesting, but we got a response, at least for that answer. It's like, pretty interesting. So we can search for products, we can log in.
Sounds interesting. We can look for reviews. Okay?
We can do advanced requests to an API, it gets even better. And we can do share helpful usage snippets and tips. Okay, fine.
But we can log in. Okay, which information do you need from me to log in, To log me in? So, because I think that's now an interesting question.
How far, what can we do with that? 'cause when we look such a chat bot is quite often like, it's, it's an assistant, right? It should help us.
And what do we need? An email and a password if enabled. And I think that's a really good point.
Two F eight, I really would recommend that. I'm not sure if I would share it with a chatbot, but that's up to you. So the good thing here is, well, let's task our friendly assistant to log us in.
Or maybe our username is one equals one, no one else, right? Let's see, why, why could that work? So an interesting part here, last year it didn't succeed because the webpage itself is protected by a fire web application firewall.
So we do input sanitization, but the chat bot, where is it located in the whole construct? Usually it's sits side by side maybe, or maybe the tool server in that case to the juice shop. So there is no segmentation in between, there's no new boundary in between either the application is patched and protected against gene SQL injection or maybe not.
Like we can see here, thankful enough, I'm not the admin of the shop and well, riha, what should I say? It worked again, but what happened? I mean, we discussed it two years ago, you should have figured it out, right?
Yep. Hi. Hi everyone.
I'm Riha la Julian. Yes, of course. So welcome back my friend.
Um, I just wanna go back and share my screen and let's see what I've got for you. One second. I was hoping you're catching me this time directly at the beginning.
Alright? Yep. So Derek and I were super busy with our juice shop, right?
So, um, let's get dig into the 40 web, right? This is the 40 web, which is our web application and API protection firewall. And, um, if I go into the login, uh, log access and then the attack log, Julie and I already see you here, you see it.
That's your, that's your, um, request or the traffic and it's in the attack log, meaning we do see you. The reason why we didn't block you is because you are in the policy is in the monitor mode. So just to explain what the monitor mode is, right?
Uh, we do have multiple policies on the graph. These are reverse proxying and also applying protection profiles. Uh, like Derek mentioned, everything, all of the MCP server, the agent and the e-commerce server are interacting and all of the traffic flows through the for, that's why we see a policy for each year.
And when I go into the policy, right, it's doing, like I said, like I mentioned, reverse proxy, but also applying that protection profile here. And the web protection profile is there already. But what happened, why did, uh, Julian succeed is because the monitor mode is turned on.
So the monitor mode is, uh, just so that the administrators can take a look at the attack log, um, and then, you know, can see, uh, what is coming in at the applications, but it's not actively blocking. That's why you are allowed Julian, congratulations. And the web protection profile, um, the one which we already have and what the web protection profile is nothing, but there are multiple protection policies that we can do with 40 web.
And if you can see that on my screen on the left side, we have several of these mitigations that we can apply and the protection profile will combine everything together. And if I open this, uh, protection profile that was already there, um, there are multiple things that we have applied already. One is the, uh, signatures here, um, and, you know, not quite, but you know, file security, few of them, but we can always enable them, right?
The other thing I also wanna show is, um, on my other policy, which is that internal, not this is the external facing, uh, policy, but the internal one also got some machine learning running. So again, there is a protection profile here, but if I go into API protection, we do have this machine learning running. And if I go into the API protection, we do see it's running for three, uh, two of this, uh, applications or policies, right?
And guide, uh, dig deeper into this, um, do see some information about the machine learning models running. So what happened here is that the, the attack was blocked in first space. Um, but again, it's monitor mode.
So we didn't see a block, but if I go back into the log access and attack, let's dig deep into this machine learning attack, right? That was generated. So what we see here is Julian did use the rest API call, uh, or the attack that he generated, uh, was targeted at this URL and the message says that there is some violation.
And we could see that raw body says this is the email and the password that he has used SQL injection payload. Um, and how did it build, how did it, how did it start working, right? So I'm just gonna go back to my slides to explain how the machine learning, uh, API discoveries work.
So what we do is, um, the AI powered discovery or machine learning, um, starts by learning normal application traffic here. Um, it or the 40 web will learn the how the user interacts, what kind of context the user is using, and also what data, um, it's, um, the data flows look like, looks like. And then it builds a machine learning model there.
And once the machine learning model is built, uh, and then there is this kind of, um, you know, risky fishy traffic that comes in, we are not just flagging those alerts, but what we do is evaluating those alerts. So, um, instead of creating this alert fatigue by raising an alert for each and every threat, we are evaluating and comparing, um, these threats with our backend 40 guard database. Um, and then we are, uh, taking the decision either to block based on the severity level, uh, and the vectorized values of this payload.
And immediately we can, uh, we are remediating by applying this block, uh, you know, alert and deny or blocking these, uh, these requests. Um, and, um, you know, taking the necessary actions. Not only that, now we have Derek, we have an, um, 40 AI assistant on our 40 web.
So just makes our job easy, uh, to see what kind of alerts or what kind of, um, attacks are coming in. So, um, going back here again, if I analyze this with the AI assistant here, um, it's, it's explaining us what has happened in the attack log. So it's taking a little bit of time here by analyzing this, but we should be able to see that, um, and explains it's a SQL injection attack.
It also explains that it's a, um, um, you know, there is some violation in the model API and also gives us some recre recommendations, how to fix it. So yeah, see a lot of information. Julian, I just even updated everything, uh, now that you're here.
So yeah, giving us the SQL injection payload, that there is this login, API with malformed input, um, and, uh, giving us recommendations of how, uh, that, how I need to block this request and also investigate the source ip. I can do several other ways, not only just this machine learning based API learning, but we can also block it with IP re, uh, global IP blockers, um, IP reputation, and also tighten other, uh, rate limiting and points, et cetera. So pretty cool of how it provides recommendations here.
So let's again go back into one last thing of how the machine learning based API protection is working, right? We do see the, uh, endpoint is rest user login, and it did say, uh, the expected, it's not the valid email address and, uh, it's blocking it. That's our first step, which is the schema based protection, but it's also flagging the OS API top 10, um, uh, group, right?
So I go into machine learning based API protection here, uh, and go into this model, uh, in the pack list here we do see that model is running for the REST user login, and it's also tagging those data categories because it in involves email and password. It says personal info, uh, useful for data loss prevention. That's also a feature on formula.
But if I go into here, uh, into this view, right, we do see it did build this, uh, machine learning discovery so it learned as the traffic comes in and build this model. And not only that, very cool is this API view, right? It's building us this oas uh, oh, sorry, the swagger for us, um, and the teams can download this, uh, exported out and for web is literally documenting this for us.
So why does machine learning based API discovery, why is it important? Right? Um, unlike traditional, um, restful APIs, what happens is in, uh, machine, in model LLMs and MCP kind of, uh, traffic, right?
They change continuously. One single update can change authentication, uh, change, you know, because they're, we are trying to access them for inference embedded, uh, tuning, et cetera. So it changes.
And it's very hard to document these, uh, APIs, for example, by the, uh, by, for the, for the developers. And not only that, the security administrators like, like us, we cannot stay on top of it, uh, to see, uh, what kind of APIs are documented and, um, are they available, are they, um, are we protecting them, et cetera. So we do need this intelligent map to discover these APIs.
And the other thing is that, um, we, there are also APIs called shadow APIs where they are part of the code because the developers might be using, you know, for some of the coding pieces or they are hidden, um, and they're not actively being, uh, documented, but they just, that just adds some additional attack picture, right? So in LLMs and um, MCP protocol, everything we are interacting is with, with APIs. So definitely needs some discovery in there to, uh, for these to be learned.
The traffic needs to be assessed and build on the goal, um, so that, you know, uh, we can, we can secure them. And microservices, most of the LMS are, they're everything behind them. In the behind the scenes is microservices, APIs.
So again, we do need something that is very fastly building this discovery for us and then applying this protection. Um, and sometimes there are also temporary APIs, which are, which leave phrases in the cache, which leave phrases in the logs, et cetera. And the machine learning discovery will come to rescue.
So overall, in summary, uh, 40 web can help this kind of, um, fast rebuild or fast paced, uh, agents or LLM based APIs, uh, to discover them. And because what we can't see, we can't secure. So the machine learning API discovery will come through.
And Julian, um, so after this, right after the speech, I just wanna make sure, I'm gonna put Q block, um, into the monitor from monitor mode to block mode. And let's try it again. You think that it will work?
Let's see. Um, we are gonna, I'm gonna give me a second here. I'm gonna also apply the block mode to my, both of my policies.
There you go. Monitor mode is turned off, uh, looking great and yeah, try it again. I'm gonna stop share.
Let's give me another try. So back in the chat, let's see. Just take the same attack.
Let's see if our username is still available or it's already taken. Um, let's give it some seconds to think about it and, well, it's a bit messy, I would say, because it's from the backend inject the through the MCP, but you can see it here. The URL request has been blocked.