4

Is it an issue to send back the same sensitive (PCI, PII) information from the server in the HTML reply that a user previously posted to the server?

On our webpage, the user enters some key info (name/address/card/account number/etc.), which is then posted to our server and we send back a page containing some non-sensitive details (dates, account balance, etc.) along with the key info he/she just provided, so that the user can further change some key values to alter the search.

Example:
POST to the server: ...&cardNumber=1111222233334444&...
Reply from the server: <html> ... <input name="cardNumber" value="1111222233334444" ... /> Here are some details about your card... </html>

The website has recently undergone a security assessment where the reviewer flagged this behavior as a high priority vulnerability, that we should not send back any sensitive info unmasked in the HTML response from the server (value="111122223333444" in the above example). They mentioned MITM attack, where somebody can steal sensitive info from the HTML data.

The developers challenged this saying the MITM can steal data from both ways of traffic, so the MITM could steal the data from the POST message and the server is not sending back more sensitive data than what was sent to the server originally. And they provided some network trace showing some well known websites on the internet also doing this practice.

Who is right: the security reviewer or the developers, and why?

Note the website is accessible only over HTTPS and other security measurements (cache control, page expiration, etc.) also implemented.

Improve this question
2
  • Do you just send back credit card numbers to the client as a response to the request where they were posted? Or do you store them and let the users see their stored credit card numbers as well?
    – Anders
    Commented Oct 25, 2017 at 12:30
  • @Anders In this scenario we just send back the card number that they posted.
    – Tamás Somogyi
    Commented Oct 25, 2017 at 13:43

2 Answers 2

Reset to default
1

Your developers are right. If HTTPS is used from the client to the server processing the request the connection should be just as secure in both directions. If both communications are on the same SSL session the key used for the actual encryption should be expected to be identical.

However it does beg the question of why are you doing this? If the client has just sent the card details why do these need to be sent back in the HTML? Can this not be handled with JavaScript at the client end?

I'm also not fully familiar with the PCI data security standards but this may be in breach of those. I know for receipts there are limits.

The do's and don'ts guide reads -

Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed.

To me sending this in HTML is a way of displaying it. There are also additional risks involving malicious code on the client.

Improve this answer
2
  • Unfortunately this is a legacy code with dozens of more or less complicated pages also with combo boxes, radio buttons, etc. doing auto-postbacks in order to grab some more data from the server. Changing this to javascript/ajax/etc. calls would be a redesign of the logic behind the UI which is quite big work and might impact the users. That's why I'd like to be 100% sure if it is really a vulnerability that needs to be fixed.
    – Tamás Somogyi
    Commented Oct 25, 2017 at 13:59
  • For the reason your security accessors gave no. However if you are breaking PCI DSS you risk being barred by your payment processor (I don't know the rules well enough to know for certain on that). A simple workaround would be to mask to only the allowed display characters (replace with '*' etc on the) server side. If a future value is all numbers then use it. If it contains masked characters check the visible characters match the stored value then either use the stored value or treat it the same as the user entering the wrong number.
    – Hector
    Commented Oct 25, 2017 at 14:39
0

Depends - what the revier said is incorrect if going across TLS. But the issue here (correct me if I'm wrong) is that the web page now has sensitive information embedded in it.

So if an additional flaw is found such as XXS this sensitive information can be extracted from the HTML structure. The user now has a cached copy of their credit card details sitting on their machine - if this is a share machine then they can also be extracted.

Yeah - you should fix this.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .