Forum: Ruby on Rails security question : making urls safe

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
itsastickup (Guest)
on 2009-03-25 01:05
(Received via mailing list)
Hi folks,

Is there an issue with urls and security? How should I be encoding
them? More than just h()?

thanks
Greg D. (Guest)
on 2009-03-25 01:23
(Received via mailing list)
On Tue, Mar 24, 2009 at 6:04 PM, itsastickup 
<removed_email_address@domain.invalid>
wrote:
> Is there an issue with urls and security? How should I be encoding
> them? More than just h()?

http://guides.rubyonrails.org/security.html


--
Greg D.
http://destiney.com/
itsastickup (Guest)
on 2009-03-25 01:52
(Received via mailing list)
I've read hundreds of these guides: they tell you to encode but
usually not how in differing circmstances. The rails docs aren't well
cross referenced, so they are out also.

That's why I am asking in a newsgroup.

Do you know the answer?
Robert W. (Guest)
on 2009-03-25 02:48
itsastickup wrote:
> Is there an issue with urls and security? How should I be encoding
> them? More than just h()?

Firstly h() doesn't encode URLs. Secondly URL encoding is not about
security. URL encoding is used to convert characters in a URL to those
of the limited set of characters that are valid for URLs.

See: http://www.w3schools.com/TAGS/ref_urlencode.asp

The Rails security guide posted by Greg contains the information you
need to know to secure your Rails application. If you're querying about
the security of the transmission of data between the client user agent
(browser) and the web server, this is provided by the SSL/TLS protocol.
SSL/TLS is common to all web sites and applications that need to protect
the transmission of data across the internet, whether they be Rails or
static web pages. SSL/TLS is also used to protect against so called
"man-in-the-middle" attacks. SSL/TLS (as far as we know) makes it
impossible for one web server to "spoof" a legitimate server. The fake
site should never be able to acquire a valid certificate for a different
domain.

Beyond that, there are also be security concerns in the client web
browsers themselves. But, that's not really your concern as an
application developer. That is unless you're the one trying to hack into
client machines though security vulnerabilities in client browsers, but
I trust that you're not.
itsastickup (Guest)
on 2009-03-25 12:06
(Received via mailing list)
Ok, thanks for that.

Here's an example of what I  mean:

I want to let the user click a user provided url. That url could be
composed of javascript. I am asusming h() won't help for this
situation. Is my only option whitelisting?

If whitelisting is it then I would prefer not to trust myself to the
(rather fragile) url Regex's out there. How do I know they won't leak?
These security guides often don't tell how, just that you must. And
there is no standardised library that I know of.


On 25 Mar, 00:48, Robert W. <removed_email_address@domain.invalid>
Robert W. (Guest)
on 2009-03-25 13:58
itsastickup wrote:
> Ok, thanks for that.
>
> Here's an example of what I  mean:
>
> I want to let the user click a user provided url. That url could be
> composed of javascript. I am asusming h() won't help for this
> situation. Is my only option whitelisting?
>
> If whitelisting is it then I would prefer not to trust myself to the
> (rather fragile) url Regex's out there. How do I know they won't leak?
> These security guides often don't tell how, just that you must. And
> there is no standardised library that I know of.

Thanks for this further explanation. What you are describing is a little
different than what I understood from the OP. Basic rule of thumb is
"Never trust ANY user input!" This is especially true if you are
accepting URL's from users.

In this case since you are taking a URL as an input parameter from the
user then you certainly should sanitize that input using html_escape
(i.e. h) method when outputting the value. It might even be safer in
this case to sanitize the input value before saving it to the database
or other persistent storage. This should ensure that any attempt to
inject JavaScript, or other unsafe user input, get treated as literal
text.
This topic is locked and can not be replied to.