Timeline for Same sensitive info in HTML reply that was posted before
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2017 at 14:39 | comment | added | Hector | 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. | |
| Oct 25, 2017 at 13:59 | comment | added | Tamás Somogyi | 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. | |
| Oct 25, 2017 at 12:49 | history | answered | Hector | CC BY-SA 3.0 |