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?

user77070
  • 31
  • 1
  • 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 '15 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 '15 at 02:18

2 Answers2

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.

Community
  • 1
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • 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 '15 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. – Steve Dodier-Lazaro May 22 '15 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 '15 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.

abhinav singh
  • 283
  • 1
  • 4