Protecting Your MCP Server From Secret Exposure With F5 BIG-IP Advanced WAF's Data Guard
The Threat of Token Mismanagement in MCP Servers Tokens and credentials serve as the backbone for authentication and authorization in MCP servers, yet their mishandling presents a significant security risk. Developers sometimes store these secrets insecurely, embedding them in configuration files or leaving them easily accessible. The inherent features of MCP—such as long-lived sessions, stateful agents, and persistent context—add complexity to this risk. Tokens can inadvertently be stored, retrieved, or indexed through user prompts, system recalls, or log inspections. This introduces a new vulnerability: contextual secret leakage, where the model or protocol layer unknowingly becomes a repository for sensitive information. Attackers can exploit this vulnerability to extract and misuse these exposed credentials, gaining unauthorized access production systems. Mitigating OWASP MCP01 with F5 BIG-IP Advanced WAF Data Guard Recognizing the gravity of this issue, OWASP has officially categorized Token Mismanagement and Secret Exposure in MCP servers under the MCP01 vulnerability class. This classification highlights the widespread nature of the threat and underscores the urgent need for tools like F5 BIG-IP Advanced WAF’s Data Guard. Although the long term solution is to correct token mismanagement at the backend servers, the F5 BIG-IP Advanced WAF’s Data Guard offers a quick and easy way to mitigate this vulnerability. By sanitizing server responses, Data Guard ensures that sensitive data—such as tokens—is never inadvertently exposed to unprivileged users. In the following video, we will see how token mismanagement can result in system error logs containing sensitive data. Subsequently, we demonstrate how we can utilize BIG-IP Advanced WAF Data Guard to sanitize these responses, thus mitigating OWASP MCP 01: Token Mismanagement & Secret Exposure. For more information on F5 Data Guard, click here. For a list of OWASP MCP Top 10 vulnerabilities, click here
F5 Data Guard - Expose last 4 digits for Custom Pattern
Hi, as from the screenshot below, we are able to choose to expose the last 4 digits for credit card numbers and U.S. Social Security Numbers. How about if we want to expose the last 4 digits for the custom patterns? It doesn't seem to have this option available. Anyone got idea on how to do so? Let's say the phone number or email address are considered as sensitive information and we don't want to mask the entire phone number and email address.F5 AWAF Data Guard
According to the online resources, the data guard features will mask response containing sensitive data or block the response. However, if the application itself displays the sensitive information which might be not from the response, will the sensitive information be masked or blocked?Data Guard exeption patterns configured via tmsh.
Hello Everyone, we have enabled Data Guard in our ASM policy and it works most of the time good ;). From time to time it happen that legit account nr. is validated as credit card nr. and so is blocked. We need than to add this pattern as exception - there is no problem to add this exception via GUI , however I'd like to ask if there is option to add this pattern via tmsh ? Thank you. Y
Data Guard Option not working
Hi All, I have a Rapid Deployment security policy, with learn, alarm and block settings enabled for Data Guard as well. But when i try to access the application, credit card number is not getting masked. Any suggestions what else I might be missing ? Big-IP version: 13.1.1The BIG-IP Application Security Manager Part 8: Data Guard
This is the eighth article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first seven articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Don't get me wrong...I love iRules as much as the next guy. But even the most ardent iRule supporters will tell you that it's better to use built-in functionality vice an iRule whenever possible. Which, by the way, we always love to hear about iRule solutions that could potentially be built into future versions of the BIG-IP products...so, keep the feedback coming! Data Guard As we all know, we need to protect the personal and sensitive information of our users. So back in the day, some super-smart people developed an iRule that scrubs out credit card numbers from HTTP traffic that passes through the BIG-IP (the link to the iRule is here). This is a great iRule, but the good news is that the BIG-IP ASM gives you all the power of this iRule (and more) by simply checking a box in the Data Guard settings. In fact, the ASM gives you the option to scrub more than just credit card numbers. It also allows you to protect social security numbers and other sensitive information based on custom patterns that you can define! In the BIG-IP ASM, you can navigate to Security >> Application Security >> Data Guard and you will see the following screen: Notice that you can simply check the box for Credit Card Numbers and US Social Security Numbers. For credit card numbers, the ASM uses the Luhn Algorithm to verify that a specific sequence of numbers is, in fact, a valid credit card number (just because you have a sequence of 16 numbers doesn't mean you have a credit card number). If you need to protect another specialized number, you can simply build the pattern in the "Custom Patterns" (using regular expression syntax) and enable that as well...you can add as many custom patterns as you want. In addition, you can set Exception Patterns...these are patterns that the ASM will recognize as not being sensitive. The "Mask Data" checkbox is simple but important. When you check this box, the ASM replaces all sensitive data (as defined by any/all of the options you choose) with a string of asterisks (*). Keep in mind that if you don't check this box, the ASM will not insert the asterisks in place of your data...so make sure you check this one! File Content Detection is a really cool feature as well. This gives you the option of selecting one or more of the available file types as sensitive data. For example, if your organization uses a specific file type for sensitive data, then you can move that document type from "Available" to "Members" and the ASM will protect the server from delivering that file type to users. Finally, the Enforcement Mode allows you to either "Ignore URLs in the list" or "Enforce URLs in the list". The default setting is to Ignore URLs. This option allows you specify URLs that will be ignored or protected (respectively) by the Data Guard feature. If you want to protect all URLs in your application, just leave the "Ignore URLs in the list" selected and make sure there are no URLs listed...that way, the ASM doesn't ignore anything. Blocking Settings I feel like I talk about Blocking Settings all the time in these articles, but these settings are important! Navigate to Security >> Application Security >> Blocking >> Settings to list the options for all the blocking settings in your policy. Scroll way down to the bottom of the page to find the "Data Guard: Information leakage detected" and this will give you the option to Learn, Alarm, and/or Block when the ASM triggers on a Data Guard violation. You will probably want to just Learn and Alarm on this setting. If you Block on this setting, then every time a Data Guard violation occurs (as defined by all the stuff you selected in the section above), the ASM will generate a Blocking Page. Instead, if you Learn and Alarm on this setting, the ASM will allow the user to see the page, but it will mask the sensitive data (as long as you select the "Mask Data" option on the Data Guard page). The screenshot below shows all the details: The Test... Now that all the Data Guard settings are in place, I want to see how the ASM performs on a web application. In this example, I went back to my trusty Hack-it-yourself auction site (configuration settings are here if you need them). As you can see from the screenshot below, I went to the "Sell an Item" page and entered a credit card number (looks fake, but it actually passes the Luhn test for valid credit card numbers) and a US Social Security Number. After I entered all the data, I hit "submit" to sell my test item...this is where the ASM should catch the request and notice it contains sensitive data... The Results... As you can see from the screenshot below, the ASM recognized the sensitive data and masked it correctly. I also tested this by changing the blocking settings to "Block" and sure enough, I got the ASM block page when I tried to sell the exact same item. Last thing...I wanted to show a screenshot of the ASM logs. Notice that the ASM simply Alarmed on this violation (no blocking page), but it caught the Credit Card Number as well as the Social Security Number. Pretty cool stuff!! Well, that does it for the Data Guard article. I hope this has helped, and I would encourage you all to go turn on Data Guard...it's simple, yet it's powerful and effective! Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event LoggingConfiguring monitor for DataGuard Oracle
Hi Experts, do you have guide where I can use as a reference in configuring DataGuard Oracle? I used this Deployment Guide but didnt work on me, https://www.f5.com/pdf/deployment-guides/oracle-rac-database-dg.pdf. I am thinking that this is something to do with the connection string that we configured. Connection string configured: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=db01)(PORT=1524))(CONNECT_DATA=(SERVICE_NAME=db.client.org))(SERVER=dedicated))
How "transparent" is transparent mode in ASM?
When setting up Application Security Manager, it's standard to set a security policy to "transparent" for a virtual server, watch what violations it catches, revise as needed and then change from transparent to blocking mode. It turns out transparent mode is not completely transparent and can break an application, even with simple defaults from a rapid deployment security policy. The Data Guard feature will, by default, replace a string of digits with asterisks if it thinks it may be a credit card or social security number. That can break an application if, for instance, that string of digits was in a critical piece of javascript code. It can of course be turned off by unchecking the Mask Data option in Data Guard, or by exempting certain URLs. Until this happened, I thought transparent mode was fairly safe to turn on, so I'd like to know what other features, especially those on by default, could interfere with a virtual server's traffic. ASM will add cookies by default, but I haven't seen that cause a problem yet. I don't know of any others on by default, but think that if the Web Scraping or Brute Force features are enabled, their client side integrity defense would be sending a javascript challenge to the client even in transparent mode. Anything else I'm missing? Any other caveats to applying a transparent mode ASM security policy?
ASM: Data Guard (Credit Card Number) Exception Rules
Hi Folks I'm having grief with Data Guard Credit Card processing. I have a bunch of web pages that use SVG graphics, and Data Guard is incorrectly detecting credit card numbers and masking some of the data used to render the graphic. If the ASM policy is in transparent mode it masks some of the data (with asterisks, and this distorts the rendered graphic), and if the policy is in blocking mode it blocks the page outright. It's definitely the credit card feature because if I disable this in Data Guard everything works normally. The data in question is contained between tags that explicitly starts with " Thanks
