Executive: "is rails secure?"

Yesterday, I was doing a dog-and-pony for the head of the company that
I work for.

He asked, “Is this (a rails application) secure?”

I said, “It’s as secure as anything else on the web is,” and proceeded
to talk about how the data was protected, how we weren’t saving
anything that’s worth protecting, and so on.

I’d like to have a better answer, for when we are storing things that
are worth protecting.

What are some talking points about Rails security? Is there a good
place to start my education on this? How safe is the data from
somebody who really, really wants to get at it? (It seems to me like
maybe Rails isn’t the stress point here – we’re using mysql as a
database, and hosting on Fedora.)

Thanks!

On Wed, 2006-06-21 at 11:41 -0500, David H. wrote:

are worth protecting.

What are some talking points about Rails security? Is there a good
place to start my education on this? How safe is the data from
somebody who really, really wants to get at it? (It seems to me like
maybe Rails isn’t the stress point here – we’re using mysql as a
database, and hosting on Fedora.)


AWDWR covers the main aspects of security as far as rails goes…the
main thing is to use the methodology covered in the book to protect
against sql injection.

As far as security in general, the security of a server/system is only
as good as the knowledge of the system administrator so he is charged
with keeping the system up to date, employing proper firewall/filtering
techniques, securing the system (users/passwords) and finally securing
the sql server itself.

In short, the security implications of using rails are not much
different than php.

Craig

“It’s as secure as anything else on the web is,”
I’d like to have a better answer,

  • I think, you already gave the best answer.

David H. wrote:

Yesterday, I was doing a dog-and-pony for the head of the company that
I work for.

He asked, “Is this (a rails application) secure?”

I said, “It’s as secure as anything else on the web is,” and proceeded
to talk about how the data was protected, how we weren’t saving
anything that’s worth protecting, and so on.

I’d like to have a better answer, for when we are storing things that
are worth protecting.

Well, first of all, asking if an application is secure and a framework
is secure are two totally seperate questions, which are you trying to
answer? If it’s an application, audit the application. If it’s Rails
in general…

A) Rails provides the essential tools for quality code and security: a
DRY methodology and powerful testing capabilities. DRY means less
chance for a typo, and increased testability, and increased testability
means the ability not to just say “We’re secure!” but to actually run
code that shows you exactly how secure you are. Tools like rcov can
even show you what you are testing and what you arn’t.

B) The Rails platform of choice these days is Mongrel with a proxying
load balancer. I’m not HTTP expert, but Zed has been adimate about the
security of Mongrel’s HTTP parser. Also, Mongrels are completely
seperate processes, so crashing or getting exploit code to run in one
does not mean the rest are directly affected.

What are some talking points about Rails security? Is there a good
place to start my education on this? How safe is the data from
somebody who really, really wants to get at it? (It seems to me like
maybe Rails isn’t the stress point here – we’re using mysql as a
database, and hosting on Fedora.)

Exactly, there are alot of holes which are much larger than a decently
written Rails application, even without tests.

Good luck!


Matthew B. :: [email protected]
Resume & Portfolio @ http://madhatted.com

On 6/21/06, David H. [email protected] wrote:

are worth protecting.

What are some talking points about Rails security? Is there a good
place to start my education on this? How safe is the data from
somebody who really, really wants to get at it? (It seems to me like
maybe Rails isn’t the stress point here – we’re using mysql as a
database, and hosting on Fedora.)

As others have said, it’s not so much about rails as about your
particular application (and other things also). A good place to learn
about some of the basics of web application security is owasp.org.
You might also take a look at the following link on Visa’s website,
specifically the security standard and security audit procedures.
The PCI program covers more than just application security, but it’s a
pretty good program with specific things you can do to improve your
security.

A)
B)
C) if you’re using rails and ruby effectively, your app could possibly
be quite simple. at least on a loc-per-part basis. which should make
tracking down security or other issues much easier than say, inside
WindowsXP, or a sprawling PHP app… plus theres a number of
authentication/roles/acl plugin if you want to go all granular on
things…

Oops forgot the url…

http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_tools_faq.html?it=c|%2Fbusiness%2Faccepting_visa%2Fops_risk_management%2Fcisp.html|View%20all%20CISP%20downloads

On 6/21/06, Matthew B. [email protected] wrote:

A) Rails provides the essential tools for quality code and security: a
DRY methodology and powerful testing capabilities. DRY means less
chance for a typo, and increased testability, and increased testability
means the ability not to just say “We’re secure!” but to actually run
code that shows you exactly how secure you are.

“Program testing can be used to show the presence of bugs, but never
to show their absence!” – Edsger Dijkstra

Test code can only prove that a piece of software is secure against a
specific attack, it can never prove that it is secure against all
possible attacks. Test code can never say how secure you are, and
thinking so will only give you a false sense of security.

That’s not to say test code isn’t useful for testing security,
however. It’s very helpful to have a test for every reported
bug/security issue, to make sure the bug/security issue doesn’t
reoccur if the code is modified. It’s also useful for checking for
common types of security issues (SQL injection and the like). But it
is limited to testing specific attacks, not overall security.

Rails is not a very mature and so could contain more security flaws
than more mature frameworks.

For instance, I believe the current verion of the ‘sanitize’ helper in
v1.1 is insecure and could allow XSS attacks if you rely on it to
protect you site.

-Scott

On 6/22/06, Dave V. [email protected] wrote:

Scott Fortmann-Roe wrote:

For instance, I believe the current verion of the ‘sanitize’ helper in
v1.1 is insecure and could allow XSS attacks if you rely on it to
protect you site.

Care to elaborate?

From my gmail archives:

Jonathan Baudanza [email protected] to rails May 10

I’ve noticed that it is possible to pass javascript unaltered through
the sanitize function using CSS. For example:

sanitize( “body{background-image:url(‘javascript:window.alert(1)’)
}” )

IE will execute the javascript. Firefox will not. I haven’t tried it
with any other browsers.

This isn’t really a bug, since the documentation for sanitize doesn’t
claim to clean up CSS. The docs should perhaps contain a disclaimer
that sanitize alone is not sufficient for removing javascript and
preventing XSS attacks.

Scott Fortmann-Roe wrote:

For instance, I believe the current verion of the ‘sanitize’ helper in
v1.1 is insecure and could allow XSS attacks if you rely on it to
protect you site.

Care to elaborate?

If I remember correctly, it won’t escape the following:
test

Note the space before ‘javascript’. The command will execute in at
least firefox 1.5, maybe other browsers.

Filed a bug report, and it was closed as a duplicate.

-Scott