I need to submit forms from a couple of remote sites to the central rails application that processes and stores data. You can think about it as of widget form (something similar to what Wufoo service provides).
These outside sites are going to be pure HTML (what means no server-side scripting - only JS/jQuery at browser side). I am aware that straight way to get it would be to put the form inside of an iframe element but I'd be glad to avoid this.
What would be a good and safe pattern to build such interaction?
I wrote simply HTML form sending data to create action in proper controller and submit form with AJAX/jQuery. It almost works, however I got
WARNING: Can't verify CSRF token authenticity
warning so, I'm sure, this approach would not be useful in production.
May someone who is experienced provide me some advice? Thank You.
Related
I'm trying to submit input to the form, and parse the results in a RoR app. I've tried using mechanize, but it has some trouble with the way the page dynamically updates the results. It doesn't help that most fields are hidden.
Is there anyway to get mechanize to do what I'm looking for, or are there any alternatives to mechanize which I can use?
So whenever I want to do something like this, I go with the gem selenium-webdriver. It spawns a real browser (supports all major brands) and lets you control it with ruby code. You can do almost everything a real user could do. In addition, you have access to the (rendered) dom, so javascript generated content is not a problem.
Performance is much slower than with pure library clients, so its not a good fit for use in a web request cycle.
http://rubygems.org/gems/selenium-webdriver
What's the quickest / easiest starting point for a simple Rails application that has a main page, and an email "contact us" page, with captcha support? Is there a popular base Rails app that I could download that would already have this functionality as a starting point?
(e.g. for just a basic informational type web site, but with the abily for the user to send support requests back to support, but via a web page with captcha)
thanks
IMHO you shouldn't use Rails, nor any other Framework for a task like that. For a simple contact form you could put a standalone php page plus some static html pages on your server and you're done.
If you doesn't know Rails yet (or any other web framework written in any language) it would be a pain to setup a such structure only to display a contact form. Is like to take a gun to kill a fly.
BTW to come to your question, I don't know any project which do what you're asking for, maybe you want to try to do that by yourself, it's pretty simple, what you need is ActionMailer and a captcha plugin
Just my two cents.
Basically I'm wondering if it's possible to have a form on a site outside of mail Rails app to POST to a form in my Rails app. For example (not what I'm going to be doing) a contact form on a Wordpress site, when submitted would POST the values to my Rails app. What would my steps be to make that possible? Or any references that are already out there?
OR if it's possible to load a form from my Rails to an outside site using Ajax or something. Eh that's probably a long shot but don't know what would be more secure and slim on code.
Thanks so much!
If you do it with AJAX you may have to handle XSS issues. Maybe you need to write an easy API for your application that could be consumed from that other application. That's not difficult from Rails and you can get help from some good controller abstractions like inherited_resources.
At some point that external application will send a form to itself using AJAX and will handle it and send it to your rails application using JSON or XML... or whatever format you want.
Yes, you can do it. Be aware that you'll have issues with the form authenticity token, so it might be easier to turn the token off.
I'm currently in the process of writing my first Rails app. I'm writing a simple blog app that will allow users to comment on posts. I'm pretty new to Rails, so I'm looking for a bit of guidance on how to address security concerns with user input.
On the front end, I am using TinyMCE to accept user input. It is my understanding that TinyMCE will strip out any suspicious tags (e.g. <script>) from user input before posting to server. It seems that this could be bypassed by disabling javascript on the page, allowing a user to have free reign in the text area. TinyMCE recommends using javascript to create the TextArea. Therefore if the user disables javascript, there will be no text area. Is this the standard solution? It seems like a bit of a hack.
On the back end, what is the best way to strip out malicious code? Would I want to put some sort of validation in the create and update methods inside my comments controller? Is there some functionality built into Rails that can assist with this?
When displaying the information back out to the user, I'm assuming that I don't want to escape the HTML markup (with <%= h *text*%>), because that's how its stored in the back end. Is this bad practice?
I'm generally a big fan of cleaning out the data prior popping that stuff into the database. This is a debatable practice, but I usually lean toward this.
I use a modified version of the old white_list plugin to not strip out the html, but to convert anything I do want into a safer format.
<tag>
becomes
<tag>
This way I'm not really altering the content of the submission.
There are some plugins that specifically handle sanitization using a white/black list model.
http://github.com/rgrove/sanitize/ # Have not used, but looks very interesting
http://github.com/imanel/white_list_model # Used, not bad
There is also act_as_sanitized, but I have no real info on that.
And of course using the h().
Your suspicions are justified, but the creation of a text area in javascript won't make you any less vulnerable. A user could always use something like curl to force a form submission without ever visiting your site through a web browser.
You should assume that a user can post malicious scripts into the comments, and escape it on the frontend. Using <%= h(...) %> is one way to do it, or you can use the sanitize method in the same way. It will strip any scripts and escape all other html except for a few common tags that aren't harmful. Documentation for sanitize.
In addition to nowk's suggestions there is also the xss_terminate plugin. I have been using it in some of my applications. I found it to be easy to use, it needs almost no configuration, and has been working like a charm.
This is probably a stupid question but I'll go ahead and humble myself.
The Ruby code in my controllers and models are interpreted so that a HTML result is sent to the browser. Ok, I get that part.
But is there any way for a mailicious user to somehow take a peek at the Ruby code in the controllers and models by bypassing the process that converts or interprets that code before it is sent to the browser?
The reason I'm concerned is I am planning on doing some order processing in my app and if a malicious user was able to do that, they might be able to figure out how to do all kinds of unpleasant things.
Side tip: make sure you use html_escape or h to escape user data and prevent someone from injecting code into your site. For example, use
<%= h(person.name) %> so that someone can't put javascript in the name field and have it run when people view that page.
Nope. Try and navigate to the file yourself in the browser, you won't be able to see it. Your biggest worry should be someone trying to fake out GETs and POSTs because they know how REST works.
Assuming you have things set up correctly, then the web server in front of Rails is pointed to the /public directory. So anything in that directory may be open to direct attack. However, the web server intercepts the HTTP call based on certain criteria and redirects it to Rails for processing.
The architecture of Rails makes it impossible for model and controller code to be exposed to the public. There is a possibility that view code is viewable, but ONLY if you seriously mess up the code (I think). I have never managed to expose code to the client by accident, and I have never deliberately attempted to do so.