Within a C# / ASP.NET MVC web app, I would like to display HTML emails received from untrusted sources. Does anyone know if there are known best practices (or even tools) to do in a "safe" way. As far I understand, most webmails perform extensive preprocessing (disabling image links, removing scripts etc).
Is there anything simple to be done better than just displaying the email as text only?
Joannes,
The easiest thing to do would be to use the Web Protection Library's whitelisting service to filter out potentially malicious HTML: http://wpl.codeplex.com/
As for implementing more sophisticated client behavior, such as blocking images from unknown sources unless the user authorizes it, you might want to try implementing something along these lines:
Don't pass full <img src="{URI}" /> tags back to the client - instead push an image with a unique ID attribute and have it src to a default "cannot display image" icon instead.
Add a button or some other UI control where a user can give their explicit consent to display images for this method.
Build an action method on your email viewing controller which returns a JsonResult with a dictionary that contains the ID of the image along with its src value.
Write a JavaScript method that will call the action method and swap the appropriate src values back into place upon recieving the JsonResult from your action method.
Hope this helps!
Related
so i am working in a .tpl file meaning i am open to js, html and php answers. what i want to do is whenever a person refreshes the page, experience a change in the url or exits the browser, my site would take an action based on this change of state. so basically, when they leave that specific page of mines in any way, i would call a function. the reason i want this is because i am saving this editable image on my site. but whenever they leave the page, i want the image the created to be autosaved.
this task splits into client-side and server-side parts. At client side you should bind to interesting browser events, triggering some background http requests to some service URLs of your website, this is probably JS. At the server side, you should provide corresponding reaction to these requests, which is probably PHP.
As long as these service URLs are to be called intermittently by various visitors, be sure to keep an eye on what request came from which client's window. PHP sessions should help you.
I'd propose to work this separately, first to get saving machinery working -- just bind everything to explicit big buttons at the page (page close, url change, etc), then replace each button with the binding to exact JS event. Keep in mind differencies among browsers.
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.
I don't want the users to directly access images and media by writing the url to the controller in the browser.
I'm using a Autorhizationfilter to check if the user is logged in and should have access to see the image or media, but is there a way to see if the user is requesting the controller directly via the browser or if the request is embedded in the .cshtml or js-files.
There are no way to get a safe protection for this. Referer easily be be faked when using HttpWebRequest or similar methods. Referer would work if you just want to protect your images from regular users that doesn't use anything other than a browser.
Another method would be to generate a id for the images which can only be used one time. Instead of writing <img src="/path/to/image.png" /> you write <img src="/controller/image/sdlkjdsjlksdlk" /> where sdlkjdsjlksdlk is a ID that you map to your image in a session variable. Use ImageResult to return the image from your controller and delete the ID when the image have been returned.
You might be able to check the referrer in Request.UrlReferrer
This would not be very reliable, though.
You might can do this by looking at the StackTrace at run-time through your code, but that's a costly operation and that assumes that the execution paths for both requests are divergent enough to make a determination.
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.