2

I'm enhancing a legacy system (which I didn't help to build) and would like to find out from other people if some things that I've noticed are legitimate security issues or not.

First of all, the application is secured via a login. However, once a user is logged in, throughout the application there are 11 pages in which a hidden field stores the value of a file name as well as the path to download.

Javascript is used to automatically submit the form and the user then downloads and saves the file to his or her computer. I'm thinking that this value could be changed and the user would unknowingly download a malicious file.

Also, there's numerous pages that have the referring page saved in a hidden field so that the user can return to the previous page when a form is saved. If these are legitimate issues, how so? How would they be attacked, if that were possible? What's the level of risk or potential impact? The reason I ask is so that I can put forward the case that the application would need to be fixed, if so. Just saying that "this isn't a best practice" is just not a good enough reason.

Thanks for your feedback!

Niklas B.
  • 92,950
  • 18
  • 194
  • 224
Jason L
  • 21
  • 1
  • 5
  • This question is probably better suited for [Security.StackExchange.com](http://security.stackexchange.com) – serk Feb 21 '12 at 23:33
  • 1
    The first sounds very much like LFI to me (extremely dangerous, possibly someone could download your database access data, for example, or basically any file he wants). Just try what happens if you put stuff like `../../../../../etc/passwd` into that field or something. The second (previous page) doesn't sound risky too me, unless the value can somehow be manipulated through a GET parameter or something, in which case it would be an XSS/HTML injection issue. – Niklas B. Feb 21 '12 at 23:37
  • Excellent point, Niklas. Thanks so much for the feedback, I'll definitely do more investigating on that! Serk, I didn't even realize that there's dedicated sections for various topics. I'll keep that in mind for the future. Thanks. – Jason L Feb 22 '12 at 15:47

3 Answers3

2

Very likely insecure. Hidden form fields are an implementation nicety.

Specifically, you cannot rely on the value of a form field being posted back to the server with the same value that the original HTML rendered it with.

If the server implements countermeasures such as sanitization of inputs, checksums, hashing, encryption, etc., the usage may be somewhat more secure. ASP.NET does this with ViewState, for instance.

That said...

Want to see how insecure it is? Change one of the hidden field's input type attribute from "hidden" to "text" using Chrome or Firefox developer tools, and watch the text field appear (where you can change it and submit whatever value you like).

I'd also highly recommend reading Matt's points on potential risk analysis in his answer.

Chris Shain
  • 50,833
  • 6
  • 93
  • 125
  • It's not totally insecure if the value cannot be manipulated in a malicious way. However, in this case I think that at least the first issue sounds very much like a local file inclusion vulnerability. Why do you say "submit whatever *username* you like"? – Niklas B. Feb 21 '12 at 23:34
  • Username was a typo, corrected. Based on the OP, my suspicion is that these are plaintext values. If they are hashed or encrypted its a different story. – Chris Shain Feb 21 '12 at 23:35
  • No, I meant if the server side implements proper input sanitization. For example it could be secure if the server would only allow paths that point into a valid download directory or something. – Niklas B. Feb 21 '12 at 23:39
  • Chris, thanks so much for the feedback. I like your idea of using the Firebug method of changing the field attributes and then changing the values to submit the form. I'm also going to do as suggested and see if I can change the file inclusion path to test for what Niklas suggests may be possible, including a different file. I'll update you if I learn anything more! Thanks so much for the feedback! – Jason L Feb 22 '12 at 15:54
0

Hidden fields are just a GUI issue - you don't see them on the screen, but they are still there. This makes them just as vunerable as any other (visible) field. THAT is why they aren't considered "best practice".

John3136
  • 28,809
  • 4
  • 51
  • 69
  • 1
    Hidden fields have may legitimate, very "best practice" uses, like carrying session IDs or CSRF tokens. – Niklas B. Feb 21 '12 at 23:33
  • They are not "just a GUI issue". You can edit a hidden form field to alter data sent to the server. – serk Feb 21 '12 at 23:34
  • Point I'm trying to make is that from a security perspective a hidden field is no better or worse than an other field. – John3136 Feb 21 '12 at 23:35
  • @John3136: So if that is your (totally valid) point, could you remove the "best practice" part of the answer? – Niklas B. Feb 21 '12 at 23:40
0

In addition to what Chris Shain has said:

What's the level of risk or potential impact? Depending on the assumptions made by the server-side script the implications could be pretty serious. If the hidden field contained, say, a user_id or username and it was assumed that this information was legitimate then anyone could perform actions on behalf of anyone else, just by altering the form fields as Chris Shain explained.

Matt
  • 9,068
  • 12
  • 64
  • 84
  • What's that with the "username"? He specifically tells us which values these hidden fields hold, and none of them is a "username". – Niklas B. Feb 21 '12 at 23:36
  • 1
    The original developer(s) I'm guessing knew enough not to include user ID or username in the hidden fields. However, there are *numerous* primary keys, e.g., Row IDs, being passed through hidden fields. I don't know whether or not (without more thorough investigation) the permission of the current user is being checked prior to accessing or updating data. However, I'm wondering, given that all of this is behind a login screen, are all of these issues rather moot anyway? – Jason L Feb 22 '12 at 16:00
  • 1
    @JasonLuttrell that depends. If I can get a login (any login), can I then edit those row ID fields and submit forms to get access to potentially sensitive data? – Chris Shain Feb 22 '12 at 16:09