3

I came across this textarea on the website of a Medical Center. Clients enter sensitive medical data here.

What users see:

HTML:

<textarea name="message">&lt;?php echo $_POST['message']?&gt;</textarea>

Could it be malicious/exploitable? What's the worst case scenario here?

2
  • If the data being transmitted by that field is not sanitised, or can set up by a parameter added to the url there is a possibility of it being exploitable.
    – sir_k
    May 22, 2015 at 13:58
  • This question is not answerable with just client data. Without the php code behind it is simply impossible to say what this would do. (migrated from awnser as that was the wrong place)
    – LvB
    May 24, 2015 at 2:18

2 Answers 2

2

There is no danger in this specific part of the form. It seems that the developers have accidentally escaped the opening and closing PHP brackets, causing PHP code to be displayed as is. Now, this specific form instance doesn't allow us to do anything since it's just text being displayed...

But it teaches us something very important about this site: user input is not properly sanitised.

This means any malicious third-party can create a request that contains arbitrary client-side scripts. This third-party can then convince a user of visiting their own website, and from that website generate a POST request to this vulnerable medical site. Then, the client-side script can be executed by the client you're targeting, within that user's session. If the user is connected to the site and able to perform any privileged operation (such as making a payment, or interacting with the content of the site), you may be able to have them perform this action unwillingly.

Such attacks are called Cross-Site Scripting (XSS) attacks, and are very commonplace unfortunately. See this question on our site and OWASP's own XSS checklist for help with XSS mitigation.

3
  • You van not conclude there is no danger. It might be that what you say is true. but it is also possible this is the result of a breach. there is simply no way to know without further details from the server. You do have a completely valid point about sanitation and user input.
    – LvB
    May 22, 2015 at 14:48
  • Why would an attacker that controls your server decide to introduce a(n otherwise not unlikely) typo on a Web form rather than introduce custom scripts or simply reap off your databases? Of course my judgement here is an heuristic (I haven't audited the server :-) ) but I can't find a realistic explanation for malicious intent here. May 22, 2015 at 14:50
  • I have seen this error as a result of break-in attempts by automated scripts. I can not conclude that is what happened here anymore than you. but I can tell you to be cautious when you see this type of error. It could be more than you think.
    – LvB
    May 22, 2015 at 14:54
0

As far as the standalone code is concerned, it is not harmful but if it is a part of a larger code, then it might be used to exploit web app based attacks.

You must log in to answer this question.

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