I have a hidden value in my form, but when I tried a security scan using HP WebInspect tool, its getting manipulated and shows vulnerability. I tried validating this hidden field but still this tool can manipulate the value. What to do for this?
First of all, check if you're using the last version of HP WebInspect tool (from this point forward HPWT).
Marking a hidden field of one html form as a vulnerability and manipulate it's value cannot be called a good tool.
Check the settings page of HPWT. In the Scan Settings / Method there are options related with forms. Check the autofill web forms options for the forms, and if it don't works set the checkbox for Prompt for web forms values during scan ...
If you don't want the manipulated data affect your code don't try to use this $("#someId").text();.
Hope it help.
Related
I understand there are many questions and answers surrounding autocomplete and autofill for web browsers. I haven't seen this specific issue raised.
UPDATE: the autofill specifically happens when a partial postback executes inside an update panel
Recently, (chrome versions 70+?), Chrome has begun aggresively autofilling input fields in our webapp when a partial postback is executed. (We use asp.net web forms)
We use the partial postback to dynamically load a user control and add it to the DOM inside an update panel.
Specifically, inputs like the following simple snippet are being populated with an email:
<input type="search" class="newH4" placeholder="Search">
I've tried adding the autocomplete attribute with different values to no avail.
Here is a screenshot of the autofill:
Additionally I have other fields like entering a dollar amount which gets populated with the email as well. Is there a way to prevent this on the latest versions of chrome?
If you have a password field in your form you can add this attribute -
autocomplete="new-password"
<input type="password" placeholder="Password" autocomplete="new-password">
autocomplete="off" should be working, but in lieu of that working and given that it is not a password or email, you could feed it some random string to see if that helps
For example autocomplete="rjftgh"
Note: simply changing the autocomplete attribute to a random string, or even a special one like 'new-password' does NOT work for this issue.
Ultimately I found a solution. It is more of a hack so I'm not too satisfied with it, but it comes from Mike Nelson's answer to the following question: Disabling Chrome Autofill
His solution involves adding input elements with their display property set to 'none' above the inputs that are being autofilled. The idea is that these hidden fields absorb the autofill instead.
I did also learn a bit more about the problem with ASP.NET and Update Panels as well. When the Update Panel triggers a partial postback, it uses an AJAX library. The library contacts the server to complete the update. Whatever AJAX is doing in the background, it is also triggering chrome's autofill logic to reexecute. In other words, whenever I dynamically add a user control, the first input field in that user control's html structure was being autofilled with the user's stored email.
Again, very strange and bad behavior, but the display 'none' input fields did the trick.
If Chrome changes their autofill logic again (they will), I'll update my answer with hopefully a better solution.
We have a required field on a page where the user has to select Gender which is a radio button with options Male and Female.
What we are finding is that there are cases when the entity has no gender stored in the database. There is javascript on the page
that does not allow user to leave the page without selecting a value. I am trying to figure out if there is a way to find out
continue without selecting a value. Would anyone be able to provide some insight as how it can be done ?
If I disable the javascript the page does not even submit. So there is another way that the user is able to skip a required field. Any ideas ?
Thanks in advance.
It's a good idea to have a back-end form validation check, as well as front-end. That way if users disable JavaScript, or find ways to bypass the front-end form validation check, the back-end will also check the form for errors.
Also, you can just set a default for the radio button, by adding the checked="checked" attribute to any of the radio button genders. This way the user will have a gender radio button already selected by default.
You may also add the <noscript></noscript> tags to your page to check if the user has JavaScript enabled. If the user does not have JavaScript enabled, your page can display a message that the user needs to enable Javascript to use your site.
More info here: http://www.w3schools.com/tags/tag_noscript.asp
It could be done using development tools (like the one we get by pressing F12 on Google Chrome) in modern browsers. As the validation is done through javascript, ie client side, a user can manipulate it from the browser.
I want to add multiple custom fields to the lightbox in dhtmlScheduler. I realize that this is a dup of a prior question but that answer is incomplete/incorrect.
My application correctly stores and recalls data from a MySQL database using dhtmlxDataProcessor on the client and dhtmlxConnector via PHP on the server side. I have carefully read, re-read, and parsed documentation on Custom "details" form. I've worked with the code in the 05_custom_editor.html sample.
The problem is that those examples do not work - they silently fail to store the second field, "Details", in the Description section. This is not surprising since nowhere is the field mapped to a database column.
What changes are needed so the "Details" field of the example form stored in the database and recalled with the event?
What changes are needed to support read-only data in the Details field that is populate based on the "Text" field? What I'm thinking of is a name that has an address associated with it.
How to invoke a custom windows with a form from the lightbox to populate the address?
I would prefer to be able to do this by extending the default lightbox, but that is not a requirement.
Any guidance is appreciated.
There are 3 required fields when using dhtmlScheduler. They are the first 3 in your PHP connector:
$scheduler->render_table("my_table","id","start_date,end_date,name,details,....
Your connector may use any column names as long as the order is preserved. But because it's required and used all over the place the dhtmlScheduler must refer to the name of the event. It is called "text".
The lightbox section maps description on to "text". I think that there is no
scheduler.locale.labels.section_description
for the same reason.
1) Update the PHP connector to pull in the required fields.
2) You can use sched.formSection('myfield') to get components from inside the lightbox, then you can add javascript to blur on focus.
3) Normal javascript
You can use one of the custom events alter any form items before you display the lightbox.
My dhtmlScheduler seems very vocal when it fails! What does the console say? Have you stepped through to see where it's failing?
I have stumbled upon the issue when I need to retract html controls I've added client-side using JavaScript after the postback (due to server-side validation - this is not optional).
Please tell me if the way I'm trying to achieve this is cr*p and there's a better way of doing this.
basically, what I'm doing is cloning a textbox control for up to 10 times on the page when the user hits "Add" and storing entered values from each of those texboxes in a hidden field to read from in the code behind. This works fine, however, when the server side validation doesn't pass after postback, all those dynamically added (cloned) texboxes disappear, since ViewState knows nothing about them.
I am considering 2 possible solution, both of which seem hacky:
Rebuild all cloned textboxes on document onload() using stored values in the hidden field
wrap the form in ajax update panel and place the cloned texboxes outside of it, thus, not refreshing this part of the screen on postback
now, is it possible to somehow "update" ViewState to make it aware of all the html controls I've added using client-side script? Any better ideas? I'd like to achieve this with client-side script, therefore not considering cloning textboxes on server-side, sorry.
You cannot modify the ViewState on the client side. If you do, you will invalidate the viewstate and receive an error on the postback.
In your case you might want to consider using javascript and jQuery to render the text boxes on the document ready event with the values stored in your hidden field. I'd recommend taking a look at jQuery templating, particularly if you can store your data as JSON in the hidden field (http://weblogs.asp.net/scottgu/archive/2010/10/04/jquery-templates-data-link-and-globalization-accepted-as-official-jquery-plugins.aspx).
In my asp.net MVC application I am using in place editors to allow users to edit fields without having a standard form view. Unfortunately, since I am using Linq to Sql combined with my data mapping layer I cannot just update one field at a time and instead need to send all fields over at once.
So the solution I came up with was to store all my model fields into hidden fields, and provide span tags that contain the visible data (these span tags become editable due to my jquery plugin). When a user triggers a save of their edits of a field, jquery then takes their value and places it in the hidden form, and sends the whole form to the server to commit via ajax.
When the data goes into the hidden field originally (page load) and into the span tags the data is properly encoded, but upon the user changing the data in the contenteditable span field, I just run
$("#hiddenfield").val($("#spanfield").html();
Am I opening any holes this method? Obviously the server also properly encodes stuff prior to database entry.
Assuming your server is properly detecting and dealing with XSS attempts, there's no way a malicious user could submit an attack for another user. Unless someone wants to hack themselves(?), it seems secure to me.
I find this approach pretty unsavory. I guess the overall soundness of this scheme depends on what fields you're actually populating this way --
For example, if you store fields that are supposed to be set only once (at the time of record creation) and never changed, this will allow a (malicious) user to change the field values mid-stream by editing a hidden field before posting (very easy to do, for example, with Firebug).
There's no difference here than if you were providing visible input fields and having that form submitted. Simply shuffling the data into hidden fields vs. visible ones would not make a difference.