Disable CC data for POST requests

Hey Bjoern,

 

 

You may want to double-check the source of the page that is returned. Based on the 'Context' provided in the violation report, it looks like the number might be in a 'hidden' input field.

 

The context in the report certainly seems disparate from the example you posted, so perhaps this is the disconnect. Maybe open the page, view source, and try to find the whole number or the "karteNummer" string in which we can see it in the below sample:

 

 

 

Pattern Context

 

Credit Card Number karteNummer" value="6677880000000004" />

 

 

 

 

It definitely appears that the whole card number is being sent back to the user-agent, probably as a form element. This means it won't appear on the page, but is still an element in the form that the user-agent will transmit back.

 

 

// Ben

I checked it servial time, with differnd tools.

 

 

I saw always the correct, with stars coded data.

 

 

Attached the request, response and log

Hey Bjoern,

 

 

Do you have DataGuard masking the content? If so, and this request is coming through the ASM, then it will definitely be all stars when it returns.

 

This is probably too obvious a question, but do you see the same come back from the server when you connect to the web server directly or when DataGuard is not enabled?

 

 

// Ben

our apps do the masking the the contend

Hey Bjoern,

There certainly appears to be something other than the request, just based on the data above. DataGuard should certainly only trigger on response data, so if you are certain that it is happening on the data in the request, I would say that a case with F5 Support is warranted.

Again, however, judging by the formatting of the data in the "Context" field in which it matched, the data appears to be the response. Observe the formatting:

karteNummer" value="6677880000000004" />

This is HTML format, even though it has been truncated. This is most likely part of a field that looks like this:

If this were part of the request, we would see all of the above encoded and in the format of HTTP POST data:

 
 karteNummer=6677880000000004 
 

Or even if the above string were itself a parameter, we would see the encoding:

 
 karteNummer%21%20value%3d%216677880000000004%21%20%2f%3e 
 

Since the "Context" is the ASM showing you precisely where it found the data that caused the match, this indicates that this is exactly the stream it was parsing when the violation was raised.

The data in the "Context" stream came from somewhere, and the fact that the data in the stream looks like HTML rather than HTTP POST data would indicate that this was, in fact, part of the response.

Were it me, I would probably try to connect direct to the web servers and view the source/responses this way to confirm. Alternatively, tcpdumps from the ASM viewing both the browser and server sides simultaneously should show this, as well (assuming this is all plain-text and not SSL).

If the above testing (especially the captures, that would be the most difinitive demonstration) do show that the responses are masked but the ASM stills seems to "see" credit card numbers in them, this is definitely worthy of a case to the folks in F5 Support.

Cheers!

// Ben

I found the reason!

 

 

1. One of our developer switched a debug option on, so the values in the POST requests was send back to the browser

 

 

2. Why I did not saw it in the response? I searched for the number in the CC number, but DataGuard masked it...

 

 

thanks a lot :-)

 

bjoern