I have completed the source code scan (ASP) using the Fortify source code scanner.
Many hidden fields shows as a vulnerability. Like this one:
<input type="hidden" name="ToSave" value="0" />
How do I fix this issue to receive a passing test?
Thanks in advance
Mahesh
If this is application state and is not modified by the user:
Passing application state thru the browser is always a bad idea and is one of the first things that the hacker will exploit.
If this is application state: use proper ASP session management and save the session state on the server when you send the page to the user, and look up the session state on the server when the request is returned. In ASP.NET with C# you might do something like this:
Session(“ToSave”) = false;
When you send the response to the browser (e.g. send the page). Then, when you get the request back, because you’re using ASPs session management, session will have the state that you set.
If this is not application state but is a hidden field that is calculated by JavaScript in the browser and is used on the server side:
Please look at the design of the application. I do a ton of these code reviews and usually find that the application is doing something in JavaScript that should only be done on the server side. One example would be calculating the score of a test on the form putting that score in a hidden field and accepting that field on the server. Another example would be calculating the ‘next’ page in a flow and putting a marker in a hidden field. If you want to provide something like a score on the browser for user convenience use that's fine but make the official calculation (and decision, if applicable) on the server.
An attacker can easily see these values and create a request that would break your application, or worse, get the attacker something that he or she did not deserve.
In any case hidden fields are cached on the browser just as any pages are cached so it might not be wise to use hidden fields if they contain data you expect the user to not be able to see.
So, bottom line, I would agree that you shouldn't use hidden fields.
Related
ASP.NET MVC and Angular based enterprise web application is hosted for external users access. We encountered a scenario like an user can manipulate the values shown in the disabled fields and submit so using the browser developer tool. e.g. (1) Input field of Vehicle Name, description etc. is disabled in the edit mode, but user can set the read-only field property to editable using dev tool and manipulate the actual value to something else.
similarly, e.g. (2) Customer details are fetched by ID from Cust db and shown on the screen. The customer details are expected to be saved in another db with a few more inputted details, but user edits the read-only customer fields using dev tool and submits.
As a solution, introducing a server side validation between retrieved and sent back values on every submission does not seem to be a right approach.
So, how to protect the read-only or static values from manipulating with browser or other dev tools?
As a solution, introducing a server side validation between retrieved and sent back values on every submission does not seem to be a right approach.
Contrary to what you appear to believe, that is the solution.
You cannot prevent the user from crafting their own HTTP request. You cannot prevent the user from hitting F12 and sending you garbage. It is up to you to validate whether the user is allowed to update the data they send you, and whether they are allowed to read the data they request.
Client-side validation is being nice for your users; server-side validation is an absolute necessity.
helping my friend with his old ASP site and ran into an issue so I wanted to throw this out to see if i can get some help.
The site basically needs to POST data to another page which it's doing fine. The problem is that it's needs to POST the username/password to the receiving page and the site is currently holding that in hidden fields which is obviously no good since you can see it in the source code.
How can you pull the data in on the ASP page without having it hidden in an input field? I know it can get stored as a variable but then I can't POST it and if I put that variable in an input value field it shows up in the source.
Any help would be appreciated.
Thanks!
it needs to POST the username/password to the receiving page
No it doesn't. :)
If the two pages are part of the same site, use the Session object.
If the two pages are on different sites, things are trickier, but the idea is similar. I'm guessing this isn't the case for you, but if it is, look at OAuth. (For example, when you log in here, you use authentication from another site, but stackoverflow never sees your password for that site. Same idea.)
Create a database table that looks like
uniqueidentifier SessionId
varchar Username
varchar Password
Store the SessionId in the cookie with Response.Cookies.
Get the SessionId from the cookie in JavaScript, and send an ajax request to a page that gets the username and password from the database using the SessionId and outputs the values in JSON. Attach the values with javascript to a hidden field. You will still appear to be getting a value from the hidden field on the page that receives the form post, but if a user views the page source it would just say something like <input type="hidden" id="username" name="username" value="DefaultUserNameValue" />. The value will be assigned dynamically using javascript, which is not visible to the User.
I am trying to build a free web application using ruby/rails It should be able to send sms through online forms of various mobile operators. (like this one (in russian)).
So, I need to
wait for the user, who wants to send an sms through my website.
establish connection to operator website. Probably, using Mechanize.
retrieve captcha
show captcha to the user
allow user to enter a message and captcha
submit form on operators website (with message, captcha, phone number)
The connection to the operator website should be alive during all this process (otherwise captcha will change). As far as I understand, I need to create a (sub)process each time sms is sent.
Could you please advise what is the best way of handling this in rails\ruby?
I am still rather new to web-development...
Should I use threads? forks? popen? using PTY? some external gem? How should I communicate with my process?
Assuming there's nothing special about the operator's web site, no, you don't need to keep a connection alive during the whole process. Generally speaking, forms on web pages work like this: You visit the URL, your web browser downloads the page with the form on it. In your case, it will also have an <img> tag or similar to show the CAPTCHA. Once your browser has downloaded the page, the connection is severed. After you fill out the form and click on Submit, your web browser opens a new connection to the server and sends the data, and the server sends its response (whatever page is shown after you click Submit).
All your program has to do is emulate this experience. So: 1) Download the page with the form on it. Scrape the form fields (make sure you don't miss any hidden fields--with a CAPTCHA there will probably be some) and the CAPTCHA. 2) Build a page to show your user that includes the CAPTCHA and a form with all the fields they need to fill out. If there were hidden fields in the original form, make sure you include their values (as hidden fields in your form) as well, because when the user submits your form you'll need them. 3) Then, when the user submits your form, send the data, including the hidden values and what the user entered for the CAPTCHA, to the operator. 4) Finally, check if the operator indicated success, and build a page to tell your user.
If you're doing this in Rails, you'll probably have two methods in your controller: One called e.g. 'show' (steps 1 and 2 above) that will scrape the CAPTCHA and other info from the operator's site and show the user your form view, and one called e.g. 'send' (step 3 and 4 above) that the form will submit to, and which will take their data and send it to the operator's web site, collect the response and tell your user if it was successful or not.
Note: You'll want to read the operators' terms of service before you bother with any of this. I'm fairly certain that this kind of thing will be against their TOSes and if they notice your server sending a lot of requests their way they're going to block you pretty quick.
To answer another question of yours, you can use DRb or background_job (aka BJ) to actually accomplish the sending in the background so that after your user submits the captcha they don't have to wait for the response. Or you could wrap this in ajax and have the DRb/BJ process notify you when the sms sending has happened so you can notify the user of success or any problems.
Typically opening threads in Ruby is something to avoid as there are so many great gems that do what we need. Not to say that you shouldn't use threads, just that for the most part it's probably already been done really well.
A common web problem is where a user clicks the submit button of a form multiple times so the server processes the form more than once. This can also happen when a user hits the back button having submitted a form and so it gets processed again.
What is the best way of stopping this from happening in ASP.NET MVC?
Possibilities as I see it are:
Disable the button after submit - this gets round the multiple clicks but not the navigation
Have the receiving action redirect immediately - browsers seem to leave these redirects out of the history
Place a unique token in the session and on the form - if they match process the form - if not clear the form for a fresh submit
Are there more?
Are there some specific implementations of any of these?
I can see the third option being implemented as an ActionFilter with a HtmlHelper extension in a similar manner to the anti-forgery stuff.
Looking forward to hearing from you MVC'ers out there.
Often people overlook the most conventional way to handle this which is to use nonce keys.
You can use PRG as others have mentioned but the downside with PRG is that it doesn't solve the double-click problem, it requires an extra trip to the server for the redirect, and since the last step is a GET request you don't have direct access to the data that was just posted (though it could be passed as a query param or maintained on the server side).
I like the Javascript solution because it works most of the time.
Nonce keys however, work all the time. The nonce key is a random unique GUID generated by the server (also saved in the database) and embedded in the form. When the user POSTs the form, the nonce key also gets posted. As soon as a POST comes in to the server, the server verifies the nonce key exists in its database. If it does, the server deletes the key from the database and processes the form. Consequently if the user POSTs twice, the second POST won't be processed because the nonce key was deleted after processing the first POST.
The nonce key has an added advantage in that it brings additional security by preventing replay attacks (a man in the middle sniffs your HTTP request and then replays it to the server which treats it as a legitimate).
You should always return a redirect as the HTTP response to a POST. This will prevent the POST from occuring again when the user navigates back and forth with the Forward/Back buttons in the browser.
If you are worried about users double-clicking your submit buttons, just have a small script disable them immediately on submit.
You might want to look at the Post-Redirect-Get (PRG) pattern:
This really isn't MVC specific, but the pattern we follow on our web pages is that actions are performed with AJAX calls, rather than full page POSTs. So navigating to a url never performs an action, just displays the form. The AJAX call won't be in the history
Along with the disabling of buttons, you can add a transparent div over the entire web page so that clicking does nothing. We do this at my work and add a little friendly label saying processing request..
The most elegant solution I found was to use ActionFilters:
Blog post is here
I have made a little app for signing up for an event. User input their data and click "sign me in".
Now sometimes people are double in the database, the exact same data that got inserted 2 times very quickly after each other. This can only mean someone clicked the button twice, which caused two posts to happen.
This is common web problem, as credit card apps and forum apps often say: "Clicking once is enough!".
I guess you could solve it by checking for the exact same data to see if the post is unique, but I wonder if there are other methods.
This ofcourse does not count for ASP.NET webforms, because POST doesn't matter as much.
While JavaScript solutions can disable the submit button after it has been clicked, this will have no effect on those people who have JavaScript disabled. You should always make things work correctly without JavaScript before adding it in, otherwise there's no point as users will still be able to bypass the checks by just disabling JavaScript.
If the page where the form appears is dynamically generated, you can add a hidden field which contains some sort of sequence number, a hash, or anything unique. Then you have some server-side validation that will check if a request with that unique value has already come in. When the user submits the form, the unique value is checked against a list of "used" values. If it exists in the list, it's a dupe request and can be discarded. If it doesn't exist, then add it to the list and process as normal. As long as you make sure the value is unique, this guarantees the same form cannot be submitted twice.
Of course, if the page the form is on is not dynamically generated, then you'll need to do it the hard way on the server-side to check that the same information has not already been submitted.
Most of the answers so far have been client-side. On the server-side, you can generate a hidden field with a GUID when you first produce the form, and then record that GUID as a submitted form when the post is received. Check it before doing any more processing.
Whenever a page is requested from the server , generate a unique requestToken , save it in server side,mark status as NOT Processed and pass it along with the current requested page. Now whenever a page submit happens , get the requestToken from the "POST"ed data and check the status and save the data or take alternate action.
Most of the banking applications use this technique to prevent double "POST"ing.So this is a time proven & reliable way of preventing double submissions.
A user-side solution is to disable the submission button via Javascript after the first click.
It has drawbacks, but I see it often used on e-commerce websites.
But, it won't never replace a real server-side validation.
Client side techniques are useful, but you may want to couple it with some server side techniques.
One way to do this is to include a unique token in the form (e.g. a GUID or similar), so that when you come to process the form you can check to see whether the token has already been used, preventing a double submission.
In your case, if you have a table with event visitors, you might include this token as a column.
A client-only solution won't be enough, as stated in many of the answers here. You need to go with a server-side fail-safe.
An often overlooked reason that disabling the submit button doesn't work is, the user can simply refresh the submit target (and click OK on the "are you sure you want to resubmit the POST data?" dialog). Or even, some browsers may implicitly reload the submitted page when you try to save the page to disk (for example, you're trying to save a hard-copy of an order confirmation).
Almost no one has js disabled.
Think about coding your e-commerce website for the 70 year old woman who double clicks every link and button.
All you want to do is add a javascript to prevent her clicking "Order Now" twice.
Yes - check this at the server side too "be defensive" - but don't code for that case. But for the sake of a better UI do it on the client side too.
Here are some scripts that I found:
//
// prevent double-click on submit
//
jQuery('input[type=submit]').click(function(){
if(jQuery.data(this, 'clicked')){
return false;
}
else{
jQuery.data(this, 'clicked', true);
return true;
}
});
and
// Find ALL <form> tags on your page
$('form').submit(function(){
// On submit disable its submit button
$('input[type=submit]', this).attr('disabled', 'disabled');
});
None of the solutions address a load-balance server.
If you have some load balancer, send a UUID (or any type of unique number) to the server to store and read again will not work well if the server is not aware of other servers, because each request could be processed by a different server in a stateless environment. These servers need to read/write to the same place.
If you have multiple servers you will need to have some shared cache (like a Redis) among the servers to read/write the unique value in the same place (what could be an over-engineering solution, but works).
Client side alteration is a common technique:
Disable submit button
Change the screen to a "please wait" screen
If the form was modal, changing the screen back to their usual process (this has the benefit of making things look really slick)
But it's not perfect. It all relies on JS being available and if that's not the case, without back-end duplication detection, you'll get duplicates still.
So my advice is to develop some sort of detection behind the scenes and then improve your form to stop people with JS being able to double-submit.
You can track the number of times the form's been submitted and compare it to the number of unique visits to the page with the form on it in the session.
Beside the many good techniques already mentioned, another simple server-side method, that has the drawback of requiring a session, is to have a session variable that is switched off on the first submit.