1

A Fortify scan said I have hidden fields. I don't specify a hidden attribute on my fields BUT I do use a MaskedEditExtender. When the Response comes back on the page with the MaskedEditExtender, the field has the hidden attribute on it.

<ajaxToolkit:MaskedEditValidator ID="MaskedEditValidator2" runat="server"
    ControlExtender="MaskedEditExtender2"
    ControlToValidate="txt_EndDate"
    IsValidEmpty="true"                                
    InvalidValueMessage="Date is invalid"                                
    Display="Dynamic"
    MaximumValue="01/01/2030"                                 
    MinimumValue="01/01/2000" 
    Font-Size="X-Small"/>

This is what's returned in the Response. You can see it has the hidden attribute on it, and Fortify complains about that:

<input name="ctl00$ContentPlaceHolder1$txt_EndDate" type="text"
id="ctl00_ContentPlaceHolder1_txt_EndDate" class="DateTextBox" AutoComplete="off" style="width:90px;" />
<input type="hidden"
name="ctl00$ContentPlaceHolder1$MaskedEditExtender2_ClientState"
id="ctl00_ContentPlaceHolder1_MaskedEditExtender2_ClientState" />

…

Also, the __VIEWSTATEGENERATOR and __EVENTVALIDATION fields are getting set to hidden in the response. Can these be unhidden as well?

Robert Q
  • 49
  • 5
  • whats the problem with hidden fields? The .net framework you are using will create ones that it needs – zgood Sep 25 '19 at 15:57

2 Answers2

0

A Fortify scan said I have hidden fields

so because fortify complains we need to remove them all ? of course not -
hidden input fields are needed for many reasons in many cases

even this page that you look now have hidden input fields... all are good. I am not say to ignore the message, but check that this input fields are from you and not from any attacker.

related answers
Clarification on __VIEWSTATE __EVENTVALIDATION __EVENTTARGET , __EVENTARGUMENT needed
CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed
Can malicious users modify viewstate?

Aristos
  • 66,005
  • 16
  • 114
  • 150
  • In our organization, ALL vulnerabilities reported by Fortify have to be addressed or reviewed and classified as false positive. So, I have to find out how to eliminate the hidden fields or document how they are false positive. I haven't found any information on how to do either, so that's why I'm asking for help on this forum. – Robert Q Sep 25 '19 at 17:55
  • @robertq this is what happens when no programmers set the rules. Hidden fields are safe and needed to add more secure validation on page. You can not avoid them unless you totally change everything on asp.net – Aristos Sep 26 '19 at 03:18
  • @Aristos, I don't agree at all. I believe this is a an issue with ASP.Net WebForms. Newer software frameworks avoid this issue alltogether. There are many vulnerabilities to consider when using hidden fields. It's been a long time, but I believe you can use `Visible="false"` in an `` – Jay Jordan May 15 '20 at 17:57
  • @JayJordan If you add the visible = false, the value of that field is added on the ViewState - so is still there 'hidden'. – Aristos May 16 '20 at 20:09
  • @JayJordan I just see a random amazon page - there are more than 30 hidden vales there... you need that values to do stuff with the code behind code... there are no vulnerabilities because of a hidden value - can easy be no hidden anyway and still not see it – Aristos May 16 '20 at 20:12
  • 1
    @Aristos, yes. It applies primarily to ASP.Net WebForms. – Jay Jordan May 20 '20 at 13:13
  • @JayJordan I have to disagree. I'm having the same issue as robertq. The app is java using jsp and non-developers won't listen and think having hidden fields is an issue – Alao Dec 28 '21 at 21:38
0

The hidden fields must be validated, fortify may still see this as a vulnerability but that is where suppression comes in.

Lacie
  • 1