Forum Discussion

Joseph_Webb_169's avatar
Joseph_Webb_169
Icon for Nimbostratus rankNimbostratus
Sep 06, 2017

How do I mark a non-standard parameter/field in ASM as sensitive or obfuscate it?

Just deployed an ASM in line with a bunch of virtual servers, but I am seeing a bunch of traffic flows that look like XML, but don't really conform to the open and closing tag format.

I need to figure out a way to get the ASM to target those HTML fields so I can mark them as sensitive so they will be obfuscated in the event logs.

So as an example:

POST /ofxserver/ofxsrvr.dll HTTP/1.1
Content-Type: application/x-ofx
User-Agent: MFM-Android/4.4.46 Nexus 5X OS 7.1.2
Content-Language: en-US
Content-Length: 738
Host: www.host.com
Connection: Keep-Alive
Accept-Encoding: gzip
X-Forwarded-For: xxxxxxxxxxxx

OFXHEADER:100
DATA:OFXSGML
VERSION:103
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE


...
username
password
...

The USERPASS item shows in cleartext during the HTTPS stream, and as a consequence shows in the event logs. We want to hide the content of the USERPASS section, but I have yet to find a decent way to mark that field as a sensitive parameter or the like.

I have attempted to import the XSD files for OFX, to see if the templates can teach the ASM how to parse the XML (but again it doesn't look like any XML I have ever seen).

If anyone could provide some insight into how I can target these fields so I can make sure they are obfuscated in the event logs would be very helpful!

1 Reply

  • This data format isn't XML but rather OFX (Open Financial Exchange), a financial data exchange standard originally based on SGML.

     

    OFX client systems are not typically web browsers, hence features like javascript aren't available. This would preclude the use of many ASM features.

     

    Further, ASM brute force protection is restricted to specific content types (text/html, text/xml, application/sgml, application/xml, application/html, application/xhtml, application/x-asp, or application/x-aspx) but OFX data has a content type of "application/x-ofx" and therefor wouldn't be included.

     

    Protection for OFX services is probably better provided by a combination of IP Intelligence (to exclude known bad-actor sources) and custom iRules to examine OFX requests for specific strings used for brute-force OFX attacks or to collect data to identify bad-actors for blocking.

     

    You should probably make contact with your F5 Account team to see about resources that can help you develop a suitable solution.