Are these uses of hidden fields insecure?

2
votes

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!

3
securitywebxssfile-inclusion
This question is probably better suited for Security.StackExchange.com – serk
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.
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

3 Answers

2
votes

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.

0
votes

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".

0
votes

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.