what design approach would you take for security and scalability (and perhaps level of effort) when posting an ASP.NET MVC HTML form that also has a Flash component, as described in the scenario below?
I have a scenario where there's an ASP.NET MVC site, and a page that requires user authentication & authorization to access (using ASP.NET forms authentication). On that page there's an HTML form. The form also has a Flash component. The form has a few text fields, and the Flash component has binary data that needs to get submitted to the server in tandem with the HTML form fields. When the user hits the submit button on the HTML form, the form contents and binary data from the Flash need to get submitted as part of one atomic unit, so to speak.
I know that I can use HTML / Flash JavaScript bridging to post the form either through JavaScript, or through the Flash component. I could even do both, perhaps posting the binary data from the Flash component when the user clicks submit, and then posting the HTML form content following that.
From your experience, what approach would be the path of least resistance to post the form with? Considering the user authentication and authorization part, I imagine that Flash would higher effort than HTML. What about the user authentication aspect? If the page posted from Flash to the server, would Flash also have to authenticate the user, in addition to the standard HTML authentication form?
My Flash binary data should not typically be greater than 300KB, often less...any opinions / insights are greatly appreciated!
EDIT:
I also vaguely remember that with Flash 10.1, ExternalInterface seemed to not work right when transferring binary data to JavaScript, am I mistaken with that, and that you can easily transfer 300KB or more of binary data from Flash to a JavaScript variable that is then posted to the server?
Thanks!
That's one way of doing it:
Make your flash component call a javascript function through ExternalInterface.call().
Make the called javascript function change a hidden field inside the form.
When the form is posted, the hidden field will send the desired value to the server.
I guess this is also the safest way - since the Flash component will not communicate with the server. Everything you need is a standard, non-AJAX form post.
Edit
Sorry, I guess I should have paid more attention... If there is too much data being sent from the flash component, maybe you should post it directly to the server.
Still, you could use ExternalInterface to synchronize the whole process. Make Flash call a server-side method (I would use FluorineFX for that, but your opinion may vary). Then .NET will return an ID, meaning it has received and saved the binary data for future use. Then call ExternalInterface to set that ID to a hidden field. After that, when the HTML is posted to the server, the server-side action method just need to retrieve the binary data using the posted ID...
The problem here is that you will end up with some binary data that will never be associated to any form post... But that's OK I guess, just run some "garbage-collector" script from time to time.
About the authentication issue: FluorineFX does implement .NET authentication, and it is able to retrieve the current logged in user. Of course, there are some issues.
Related
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.
I've noticed on viewing the source of my Rails app that a lot of information is publicly available that shouldn't be - specifically a Google Analytics script that contains my GA account number, and the authenticity tokens for my forms.
Are there any guidelines on hiding this kind of code in the source?
Your Google Analytics ID and the authenticity token both need to be available for the browser to do it's job. They don't need to be hidden. There is no security risk associated with letting a user see them.
If by "view source" you mean the HTML returned from the server, then no. There are services and products that will encode your page and make it difficult to decipher, but it's never impossible as your browser will ultimately have to do it in order to render the page. Most of these page encryptors, as they are sometimes called, will make your site impenetrable to search engines since they won't run your JavaScript before indexing the page.
Have a look at other sites and you'll see it's fairly common practice to leave this sort of stuff open since the time and effort involved in obscuring or hiding it is a waste of time. So long as you're not revealing any sensitive information inadvertently, like your Amazon S3 account keys or the secret used for encrypting your session, which is unlikely to happen by accident, then you'll be fine.
Think about it for a moment, though. Without the browser having access to your Google Analytics account number, how would the Google script know which account to track against?
I don't think it's dangerous to have your authenticity token there. In order to see that authenticity token, a user has to be logged in. It doesn't matter if that user has the authenticity token for that session or not. It should expire when the user logs out.
However, it is possible to hide these things from the source if you want to (although they'll still be available if you have Firebug or a similar utility).
For your GA script, you could consider it a resource. Your application.js (or some other included js file) could make an AJAX call to the controller (the request header has to accept javascript) and your controller could send back a js.erb file that has the script included. This js is now only visible in Firebug if you look at the response to the request to the controller. You will not see it in the source.
For the authenticity token, you can do something similar. I've created a JavaScript form builder in one of my apps. This form builder is a resource which is once again retrieved through an AJAX call and sent down as js.erb. The js.erb file has a FormBuilder constructor. Within that constructor, there is a builder.form() function which does this:
return $('<%= form_for #object do |f| %> <% end %>');
That will return a jQuery object which contains a Rails form with the authenticity token and all the other goodies.
If you want your JS form builder to do more than just spit out a form (e.g. dynamically create properties for the builder object based on the object's attribute names which contain inputs, checkboxes, and collections for the corresponding attributes), talk to me and I can tell you how I did that too :)
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'm making my way into web development and have seen the word postback thrown around. Coming from a non-web based background, what does a new web developer have to know about postbacks? (i.e. what are they and when do they arise?)
Any more information you'd like to share to help a newbie in the web world be aware of postbacks would be most greatly appreciated.
The following is aimed at beginners to ASP.Net...
When does it happen?
A postback originates from the client browser. Usually one of the controls on the page will be manipulated by the user (a button clicked or dropdown changed, etc), and this control will initiate a postback. The state of this control, plus all other controls on the page,(known as the View State) is Posted Back to the web server.
What happens?
Most commonly the postback causes the web server to create an instance of the code behind class of the page that initiated the postback. This page object is then executed within the normal page lifecycle with a slight difference (see below). If you do not redirect the user specifically to another page somewhere during the page lifecycle, the final result of the postback will be the same page displayed to the user again, and then another postback could happen, and so on.
Why does it happen?
The web application is running on the web server. In order to process the user’s response, cause the application state to change, or move to a different page, you need to get some code to execute on the web server. The only way to achieve this is to collect up all the information that the user is currently working on and send it all back to the server.
Some things for a beginner to note are...
The state of the controls on the posting back page are available within the context. This will allow you to manipulate the page controls or redirect to another page based on the information there.
Controls on a web form have events, and therefore event handlers, just like any other controls. The initialisation part of the page lifecycle will execute before the event handler of the control that caused the post back. Therefore the code in the page’s Init and Load event handler will execute before the code in the event handler for the button that the user clicked.
The value of the “Page.IsPostBack” property will be set to “true” when the page is executing after a postback, and “false” otherwise.
Technologies like Ajax and MVC have changed the way postbacks work.
From wikipedia:
A Postback is an action taken by an
interactive webpage, when the entire
page and its contents are sent to the
server for processing some information
and then, the server posts the same
page back to the browser.
Expanding on the definitions given, the most important thing you need to know as a web-developer is that NO STATE IS SAVED between postbacks. There are ways to retain state, such as the Session or Viewstate collections in ASP.NET, but as a rule of thumb write your programs where you can recreate your state on every postback.
This is probably the biggest difference between desktop and web-based application programming, and took me months to learn to the point where I was instinctively writing this way.
Postback happens when a webpage posts its data back to the same script/dll/whatever that generated the page in the first place.
Example in C# (asp.net)
...
if (!IsPostback)
// generate form
else
process submitted data;
Web developement generally involves html pages that hold forms (<form> tags). Forms post to URLs. You can set a given form to post to any url you want to. A postback is when a form posts back to it's own page/url.
The term has special significance for ASP.Net WebForms developers, because it is the primary mechanism driving a lot of the behavior for a page — specifically 'event handling'. ASP.Net WebForms pages have exactly one server form which nearly always posts back to itself, and these postbacks trigger execution on the server of something called the Page Lifecycle.
The term is also used in web application development when interacting with 3rd party web-service APIs
Many APIs require both an interactive and non-interactive integration. Typically the interactive part is done using redirects (site 1 redirects a user to site 2, where they sign in, and are redirected back). The non-interactive part is done using a 'postback', or an HTTP POST from site 2's servers to site 1's servers.
When a script generates an html form and that form's action http POSTs back to the same form.
Postback is essentially when a form is submitted to the same page or script (.php .asp etc) as you are currently on to proccesses the data rather than sending you to a new page.
An example could be a page on a forum (viewpage.php), where you submit a comment and it is submitted to the same page (viewpage.php) and you would then see it with the new content added.
See: http://en.wikipedia.org/wiki/Postback
Postback refers to HTML forms. An HTML form has 2 methods: GET and POST. These methods determine how data is sent from the client via the form, to the server. A Postback is the action of POSTing back to the submitting page. In essence, it forms a complete circuit from the client, to the server, and back again.
A post back is anything that cause the page from the client's web browser to be pushed back to the server.
There's alot of info out there, search google for postbacks.
Most of the time, any ASP control will cause a post back (button/link click) but some don't unless you tell them to (checkbox/combobox)
Yet the question is answered accurately above, but just want to share my knowledge .
Postback is basically a property that we can use while doing some tasks that need us to manage the state of the page, that is either we have fired some event for e.g. a button click or if we have refreshed our page.
When our page loads for the very first time , that is if we have refreshed our page, at that time postback-property is false, and after that it becomes true.
if(!ispostback)
{
// do some task here
}
else
{
//do another task here
}
http://happycodng.blogspot.in/2013/09/concept-of-postback-in.html