Is Ramaze secure enough to use for an ecommerce app?
Chris
I like the simplicity of Ramaze but because I'm considering creating
an ecommerce app, I am concerned that Ramaze may not provide the same
level of security that Rails has.
Is this a correct assumption or are there steps I can take to ensure
that a Ramaze app has the same level of security as an equivalent
Rails app?
Phrogz
> I like the simplicity of Ramaze but because I'm considering creating
> an ecommerce app, I am concerned that Ramaze may not provide the same
> level of security that Rails has.
> Is this a correct assumption or are there steps I can take to ensure
> that a Ramaze app has the same level of security as an equivalent
> Rails app?
'dev' mode, where a purposefully-created bad URL will show code
snippets around the call stack (giving attackers possible insight into
ways to further break in).
James Britt
>
> I like the simplicity of Ramaze but because I'm considering creating
> an ecommerce app, I am concerned that Ramaze may not provide the same
> level of security that Rails has.
>
How have you determined the security level of Rails?
--
James Britt
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development
Nick Robinson-Wall
>
> I am concerned that Ramaze may not provide the same
> level of security that Rails has.
I would have automatically assumed (with very little experience of
rails, mind you) that Ramaze would be more secure due to Rails' bloat.
That and the fact Ramaze's code is clean, concise and will written... :D
hrnt
Ramaze does not provide that automatically so you need to implement it
yourself.
I can't think of other things, but then again, it's been a long time
since
I last touched Rails :)
Chris
> Chris wrote:
>
> > I like the simplicity of Ramaze but because I'm considering creating
> > an ecommerce app, I am concerned that Ramaze may not provide the same
> > level of security that Rails has.
>
> How have you determined the security level of Rails?
2 ways.
1. By reading the Ruby On Rails Security Guide:
http://guides.rubyonrails.org/security.html
It seems like a pretty good presentation of the security features that
are present in in Rails.
2. Based on the sheer momentum behind Rails, I think it's fairly safe
to assume that any security flaws will be revealed fairly quickly.
Obviously very large numbers of Rails ecommerce applications have been
successfully deployed and very large numbers of developers are poring
over the Rails code base every day. So the chance of a serious
security flaw not coming to light are very slim.
I didn't come here to throw stones at Ramaze, because I don't know
Ramaze well enough to pass judgment on its built-in security. As Nick
Robinson-Wall said in this thread, the small size of the codebase
contributes to the security of Ramaze. I'm sure that's true but the
question is whether that same conciseness also results in security
features being omitted. Since I don't know Ramaze well enough to pass
judgment, I hope someone here can shed some light.
I assume that anyone who has worked with Ramaze in a serious fashion
would have considered this issue, especially anyone who has carried
out ecommerce transactions in a Ramaze app. I'm just hoping to hear
some feedback from such people.
Chris
On Sep 9, 6:56 pm, hrnt <aotu...@gmail.com> wrote:
> I believe Rails nowadays comes with built-in CSRF protection.
> Ramaze does not provide that automatically so you need to implement it
> yourself.
James Britt
> I'm not a security expert, so I have mainly come to this conclusion in
> 2 ways.
>
> 1. By reading the Ruby On Rails Security Guide:
>
> http://guides.rubyonrails.org/security.html
>
> It seems like a pretty good presentation of the security features that
> are present in in Rails.
>
> 2. Based on the sheer momentum behind Rails, I think it's fairly safe
> to assume that any security flaws will be revealed fairly quickly.
> Obviously very large numbers of Rails ecommerce applications have been
> successfully deployed and very large numbers of developers are poring
> over the Rails code base every day. So the chance of a serious
> security flaw not coming to light are very slim.
Makes sense.
>
> I didn't come here to throw stones at Ramaze, because I don't know
> Ramaze well enough to pass judgment on its built-in security. As Nick
> Robinson-Wall said in this thread, the small size of the codebase
> contributes to the security of Ramaze. I'm sure that's true but the
> question is whether that same conciseness also results in security
> features being omitted. Since I don't know Ramaze well enough to pass
> judgment, I hope someone here can shed some light.
Good point. I agree that the smaller code base would (all things being
equal) make it less prone to flaws. But having a lot of people pounding
on the code helps too.
>
> I assume that anyone who has worked with Ramaze in a serious fashion
> would have considered this issue, especially anyone who has carried
> out ecommerce transactions in a Ramaze app. I'm just hoping to hear
> some feedback from such people.
Me too. I've never used Ramaze for E-comm.
Michael Fellinger
>
> On Sep 9, 6:07 pm, James Britt <james.br...@gmail.com> wrote:
>> Chris wrote:
>>
>> > I like the simplicity of Ramaze but because I'm considering creating
>> > an ecommerce app, I am concerned that Ramaze may not provide the same
>> > level of security that Rails has.
>>
>> How have you determined the security level of Rails?
>
> I'm not a security expert, so I have mainly come to this conclusion in
> 2 ways.
>
> 1. By reading the Ruby On Rails Security Guide:
>
> http://guides.rubyonrails.org/security.html
>
> It seems like a pretty good presentation of the security features that
> are present in in Rails.
Thanks for the link, it's very useful.
Many of the issues talked about here are about general good practice,
not rails-specific security features, but there are some things that
may find their way into Ramaze as well. I'll try to make a summary
comment when I'm done reading.
> 2. Based on the sheer momentum behind Rails, I think it's fairly safe
> to assume that any security flaws will be revealed fairly quickly.
> Obviously very large numbers of Rails ecommerce applications have been
> successfully deployed and very large numbers of developers are poring
> over the Rails code base every day. So the chance of a serious
> security flaw not coming to light are very slim.
There have been big security issues in the past in rails land, and I
expect there to be more in future.
What's most interesting to me, they have most bugs in "deep" code, as
I'd call it, that is code that the user doesn't even know about, they
just use the API without ever bothering/daring to look under the hood.
Things like the form forgery protection are less understood and can
only be used in specific environments.
I'm not going to tell you that Ramaze/Innate are more secure, but we
share the same Rack codebase and servers along with just about every
other Ruby web-framework out there.
That means that at leat on this level, we are pretty certain that
there are no huge holes anymore, and we try to integrate as tightly as
possible with it to take advantage of that security.
> I didn't come here to throw stones at Ramaze, because I don't know
> Ramaze well enough to pass judgment on its built-in security. As Nick
> Robinson-Wall said in this thread, the small size of the codebase
> contributes to the security of Ramaze. I'm sure that's true but the
> question is whether that same conciseness also results in security
> features being omitted. Since I don't know Ramaze well enough to pass
> judgment, I hope someone here can shed some light.
The true codebase of Ramaze is in Innate, not even 2k LoC that are
easy to read/understand and fix in case of an issue.
Ramaze builds on top of Innate, but almost all code in Ramaze is
optional and only used if you explicitly want to.
We don't provide "The Form builder" that will protect you from all
evil, or automatic REST style routing, where possible I try to provide
secure defaults, the entire codebase won't create any symbols, for
example, which reduces memory usage significantly and avoids runaway
processes through attacks targeted at this.
Due to Ramaze not providing as many bells and whistles as Rails, it
leaves most of the security considerations to the programmer, who may
either do something very stupid and trust security by obscurity, or
follow good practices and think about the stuff she writes.
If you are concerned about security, there is no other way than
understanding the stack yourself, leaving security to others is either
possible if you reuse/buy a whole app from someone who went through
that trouble, but every modification you make might result in a
security issue. The other way is to write it yourself, using tools
that make it easy and obvious what's going on, shorter code results in
less bugs, avoiding autogenerated code results in deeper understanding
and nudges you into direction of shorter code (writing less yourself
should be a goal of every lazy coder).
As you might notice by now, this is not really a discussion about
security, it's more about understanding.
With Rails you place your security in the hands of a bunch of other
people, that may keep the worst issues out of your codebase, but if
you forget to flip a switch somewhere it's very likely to provide a
huge attack vector without being aware of it, simply because you never
bothered to read and understand what code you are using there.
If you are making an e-commerce application, make sure that you have
few moving parts around your payment process, outsource it to
google-checkout, edigicash, or amazon, whatever gives you what you
need, then read the security guide from Rails and apply the practice
to your own code.
Avoid SQL injection by either not using SQL or using an ORM that makes
it very hard to inject stuff accidentially, like Sequel, Datamapper,
or even ActiveRecord.
Don't trust the input of a user, ever, nowhere, no matter how certain
you are that the user has good intentions. Escape all output that
might have anything to do with user input using the h method or
prepare to be used as a base for attacks.
Make sure that the cache you are using has a memory limit, don't rely
on the default cache of Innate, rather check what options there are
and what suits you best.
There are many things I could tell you, but my time is limited, and
everything has been said many times before in many places all over the
web, from a list apart to ruby-talk.
> I assume that anyone who has worked with Ramaze in a serious fashion
> would have considered this issue, especially anyone who has carried
> out ecommerce transactions in a Ramaze app. I'm just hoping to hear
> some feedback from such people.
--
Michael Fellinger
CTO, The Rubyists, LLC
972-996-5199
Peakhope
run in SAFE mode, with tainted string checking.
When I wrote an SMTP email server in ruby, I set $SAFE = 1 which was a
bit of a pain, but which discovered a few cases that could have become
security holes. Safe level 2 looks even better, so I'll switch to that
at some point.
Setting a SAFE level is not a magic pill that automatically makes an
app secure, but it is a worthwhile step as it forces you to really
think about how you are handling user-input data. I don't have enough
expertise to call it a Best Practice, but it seems like it could be.
I haven't tried running a ramaze app in safe mode (nor a rails app for
that matter). Does it work in either/both framework?
Kevin
Chris
On Sep 10, 4:39 am, Michael Fellinger <m.fellin...@gmail.com> wrote:
> Things like the form forgery protection are less understood and can
> only be used in specific environments.
be used in specific environments. It seems to me to be widely
applicable.
The Rails feature "protect_from_forgery" seems to me to be the
clearest example of a Rails security feature that would be of benefit
to Ramaze (and Sinatra too).
protect_from_forgery :secret =>
"123456789012345678901234567890..."
"This will automatically include a security token, calculated from the
current session and the server-side secret, in all forms and Ajax
requests generated by Rails. It will raise an
ActionController::InvalidAuthenticityToken error, if the security
token doesn’t match what was expected."
I can think of framework-agnostic solutions to most of the other
issues listed in the Security Guide. And coincidentally I just found
that Ryan Bates did a video on this just a few days ago and seems to
summarize the Guide quite succinctly:
http://railscasts.com/episodes/178-seven-security-tips
But forgery protection is the only feature that might need some
coding. I don't know how difficult it would be to write something like
this for a Ramaze app. But perhaps this already exists in a gem
somewhere. As you say, it's good to have your nose close to the code.
But it's also nice not to have to reinvent the wheel, especially when
better minds (than mine) have already figured out a solution to the
problem.
Michael Fellinger
No, they have to interact with the filesystem, even in $SAFE = 1 that
would cause issues.
> Kevin
Chris
> But forgery protection is the only feature that might need some
> coding. I don't know how difficult it would be to write something like
> this for a Ramaze app. But perhaps this already exists in a gem
> somewhere. As you say, it's good to have your nose close to the code.
> But it's also nice not to have to reinvent the wheel, especially when
> better minds (than mine) have already figured out a solution to the
> problem.
from Rails:
http://github.com/baldowl/rack_csrf/tree/master
I'm not sure whether the general approach taken in this gem - of
implementing the proection in Rack - rather than in framework-specific
view helpers is the cleanest way to go but it is certainly transparent
and this gem seems to work with any Rack-based Ruby framework although
the example code that is provided is for Sinatra.
Peakhope
>
> > I haven't tried running a ramaze app in safe mode (nor a rails app for
> > that matter). Does it work in either/both framework?
>
> No, they have to interact with the filesystem, even in $SAFE = 1 that
> would cause issues.
interact with the filesystem in potentially dangerous ways? Or that
the user apps themselves would? Neither one sounds like a correct
statement to me.
Thanks,
Kevin
Michael Fellinger
From $SAFE = 1 on, any fileystem operation with tainted arguments is
not allowed.
That means that the call for File.file? in Racks public file handler
raises, and Innate/Ramaze cannot do any lookup for templates, even if
you'd serve all public files with another webserver in front.
The automatic source reload mechanism of Ramaze/Innate is breaking at
$SAFE = 1, since some $LOAD_PATH elements are tainted, and
require/load is forbidden anyway.
If we start in live mode instead, without the source reloader, we
still break when checking for existence of files in the public
directory, because we do that based on env['PATH_INFO'] which is
tainted for good reasons.
>
> Thanks,
Kevin Smith
> On Mon, Sep 14, 2009 at 5:51 PM, Peakhope <Kev...@qualitycode.com> wrote:
> >
> > Can you elaborate? Are you saying that ramaze and/or rails have to
> > interact with the filesystem in potentially dangerous ways? Or that
> > the user apps themselves would? Neither one sounds like a correct
> > statement to me.
>
> From $SAFE = 1 on, any fileystem operation with tainted arguments is
> not allowed.
> That means that the call for File.file? in Racks public file handler
> raises, and Innate/Ramaze cannot do any lookup for templates, even if
> you'd serve all public files with another webserver in front.
So the "simple" solution is to make sure that the filenames are
untainted first. Which means someone just needs to check to make sure
they are safe, which shouldn't be that hard.
>
> The automatic source reload mechanism of Ramaze/Innate is breaking at
> $SAFE = 1, since some $LOAD_PATH elements are tainted, and
> require/load is forbidden anyway.
> If we start in live mode instead, without the source reloader, we
> still break when checking for existence of files in the public
> directory, because we do that based on env['PATH_INFO'] which is
> tainted for good reasons.
What I have heard so far is: "We would rather run in unsafe mode,
allowing potentially dangerous data to get to the filesystem, rather
than allow/do the checking that would be necessary both to run in safe
mode AND to actually be safe."
I guess my question is: Could an app could take responsibility for
verifying and untainting these strings, and then run in safe mode? If
not, would it be so hard for ramaze/innate/rack to take responsibility
for verifying and untainting any strings that it alone controls that the
app couldn't take care of?
Kevin