1366 0 true 2008-09-04T14:47:43+01:00 1366 2008-10-13T00:00:00+01:00 20253 7 update-security-guide 6 16213 2009-10-04T22:55:00+01:00 20241 mrflip Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 The security guide needs to be updated with rails 2.0 stuff, like the new cookies session manager, http basic authentication, cross domain request forgery protection, etc. The security guide needs to be updated with rails 2.0 stuff, like the new cookies session manager, http basic authentication, cross domain request forgery protection, etc. <div><p>The security guide needs to be updated with rails 2.0 stuff, like the new cookies session manager, http basic authentication, cross domain request forgery protection, etc.</p></div> 1366 0 The security guide needs to be updated with rails 2.0 stuff, like the new cookies session manager, http basic authentication, cross domain request forgery protection, etc. <div><p>The security guide needs to be updated with rails 2.0 stuff, like the new cookies session manager, http basic authentication, cross domain request forgery protection, etc.</p></div> false 2008-09-04T14:47:45+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-04T14:47:45+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 I would like to work on this. <div><p>I would like to work on this.</p></div> false 2008-09-05T09:47:29+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-05T09:47:34+01:00 26786 Arjun Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 I've got a guide ready and I could convert it. <div><p>I've got a guide ready and I could convert it.</p></div> false 2008-09-06T14:23:04+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-06T14:23:08+01:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 Arjun : Given Heiko's knowledge in this area he's probably the best bet. But if you have any other ideas for guides, please PM me at Github. Thanks. <div><p>Arjun : Given Heiko's knowledge in this area he's probably the best bet. But if you have any other ideas for guides, please PM me at Github.</p> <p>Thanks.</p></div> false 2008-09-10T15:05:26+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-10T15:05:32+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 Suggestions/nitpicks: - The transition from the initial bullet points into Sessions is pretty abrupt. I'd like to see this start with an A-level head like "Overview of Rails Security". Could discuss the general concept of web app security, the notion of multiple attack vectors, the necessity to keep up to date and to audit your application, the fact that no framework can make up for boneheaded devs doing stupid things. - Session id section: I don't think there's much point to recommending future changes when we're documenting current versions. If you're going to mention MD5 collisions, should mention the effects: "This would allow a user to..." - Not sure the general session guidelines are really germane in a security guide. - I think you should take the important action items for the developer, pull them out of the general text, and highlight them as tips - for example, the fact that your session secret should not be a dictionary word should be highlighted as a tip. This will make life easier for readers who are new to security and just want to know "what should I do?" - Reading the section on replay attacks for CookieStore sessions leaves me not sure how to prevent these attacks. You may need a code sample. - Overall, I think you could use another level of organization. Maybe group things under two headings "protecting your application" and "protecting your users" - Not sure the section on good passwords belongs in a Rails-specific guide. - Nit: in the privilege escalation section, I would say that client-side validation is useless _against a determined attacker_. It certainly raises the bar at least a tiny bit, doesn't it? (I know folks who are defeated by javascript "solutions" that block downloading images via right-click). - Would like to see a section - perhaps at the end - "How to Keep up to date". Recognizing that the security landscape shifts, and that missing a new vulnerability can be catastrophic, we ought to point people at resources for keeping up with issues. Like rorsecurity.info :) <div><p>Suggestions/nitpicks:</p> <ul> <li>The transition from the initial bullet points into Sessions is pretty abrupt. I'd like to see this start with an A-level head like "Overview of Rails Security". Could discuss the general concept of web app security, the notion of multiple attack vectors, the necessity to keep up to date and to audit your application, the fact that no framework can make up for boneheaded devs doing stupid things.</li> <li>Session id section: I don't think there's much point to recommending future changes when we're documenting current versions. If you're going to mention MD5 collisions, should mention the effects: "This would allow a user to..."</li> <li>Not sure the general session guidelines are really germane in a security guide.</li> <li>I think you should take the important action items for the developer, pull them out of the general text, and highlight them as tips - for example, the fact that your session secret should not be a dictionary word should be highlighted as a tip. This will make life easier for readers who are new to security and just want to know "what should I do?"</li> <li>Reading the section on replay attacks for CookieStore sessions leaves me not sure how to prevent these attacks. You may need a code sample.</li> <li>Overall, I think you could use another level of organization. Maybe group things under two headings "protecting your application" and "protecting your users"</li> <li>Not sure the section on good passwords belongs in a Rails-specific guide.</li> <li>Nit: in the privilege escalation section, I would say that client-side validation is useless <em>against a determined attacker</em>. It certainly raises the bar at least a tiny bit, doesn't it? (I know folks who are defeated by javascript "solutions" that block downloading images via right-click).</li> <li>Would like to see a section - perhaps at the end - "How to Keep up to date". Recognizing that the security landscape shifts, and that missing a new vulnerability can be catastrophic, we ought to point people at resources for keeping up with issues. Like rorsecurity.info :)</li> </ul></div> false 2008-09-15T13:44:57+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-15T13:45:03+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 "How to Keep up to date" can also ask people to subscribe to http://groups.google.com/group/rubyonrails-security <div><p>"How to Keep up to date" can also ask people to subscribe to <a href="http://groups.google.com/group/rubyonrails-security">http://groups.google.com/group/r...</a></p></div> false 2008-09-15T13:47:35+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-15T13:47:40+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 - I added an introduction - general session guidelines: Definitely needed because you should not store secrets in a client-side session storage (CookieStore) - I highlighted the important countermeasures - Good passwords: I think it's important, you need good passwords for the database and the web server. And you could tell you web app users. - rewrote the end of the privilege escalation section - added some resources of how to keep up to date:) <div><ul> <li>I added an introduction</li> <li>general session guidelines: Definitely needed because you should not store secrets in a client-side session storage (CookieStore)</li> <li>I highlighted the important countermeasures</li> <li>Good passwords: I think it's important, you need good passwords for the database and the web server. And you could tell you web app users.</li> <li>rewrote the end of the privilege escalation section</li> <li>added some resources of how to keep up to date:)</li> </ul></div> false 2008-09-17T16:05:05+01:00 1366 --- {} 7 update-security-guide 0 16213 new 2008-09-17T16:05:09+01:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 1366 0 false 2008-09-30T00:09:32+01:00 1366 --- :milestone: 20253 7 update-security-guide 0 16213 new 2008-09-30T00:09:34+01:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 I ready to work <div><p>I ready to work</p></div> false 2008-09-30T01:23:18+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-09-30T01:23:21+01:00 31566 srinivasaenergy (at gmail) Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Typo in section 2.5. "Mot real-live applications choose ActiveRecordStore (or one of its derivatives) over file storage due to performance and maintenance reasons." Mot -> Most <div><p>Typo in section 2.5.</p> <p>"Mot real-live applications choose ActiveRecordStore (or one of its derivatives) over file storage due to performance and maintenance reasons."</p> <p>Mot -&gt; Most</p></div> false 2008-10-10T18:14:22+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-10T18:14:28+01:00 17465 Mike Boone Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 I read section 7.6 about regular expressions. I was not aware of needing to use \A and \z instead of ^ and $. I'm fixing my code now! Anyway, I think the section could be a little clearer: "...match the string's end and beginning by $ and ^, instead of \z and \A." IMO it would be better to say: "...match the string's beginning and end by ^ and $, instead of \A and \z." The bad filename "file.txt%0A<script>alert('hello')</script>" does not include a %0D as the subsequent text implies. Also, it might help to explain when/how Rails converts %0A into the linefeed inside the string. If you just enter the above string in irb, the /^[\w\.\-\+]+$/ regexp works. If you enter "file.txt\n<script>alert('hello')</script>" in irb, the problem reveals itself. Any links to other articles that cover this topic? Thanks. <div><p>I read section 7.6 about regular expressions. I was not aware of needing to use \A and \z instead of ^ and $. I'm fixing my code now!</p> <p>Anyway, I think the section could be a little clearer:</p> <p>"...match the string's end and beginning by $ and ^, instead of \z and \A." IMO it would be better to say: "...match the string's beginning and end by ^ and $, instead of \A and \z."</p> <p>The bad filename "file.txt%0A" does not include a %0D as the subsequent text implies. Also, it might help to explain when/how Rails converts %0A into the linefeed inside the string. If you just enter the above string in irb, the /^[\w.-+]+$/ regexp works. If you enter "file.txt\n" in irb, the problem reveals itself.</p> <p>Any links to other articles that cover this topic?</p> <p>Thanks.</p></div> false 2008-10-10T20:48:10+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-10T20:48:15+01:00 17465 Mike Boone Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Thanks, updated in repository. I doubt there are other articles that cover this Ruby reg.expr. difference, it's fairly unknown, I've seen this error even in popular books. <div><p>Thanks, updated in repository. I doubt there are other articles that cover this Ruby reg.expr. difference, it's fairly unknown, I've seen this error even in popular books.</p></div> false 2008-10-11T15:00:13+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-11T15:00:16+01:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Heiko - I did a light edit pass on this one (it didn't need a heavy one). Is it worth adding a small section to cover http://weblog.rubyonrails.com/2008/10/19/response-splitting-risk ? <div><p>Heiko - I did a light edit pass on this one (it didn't need a heavy one).</p> <p>Is it worth adding a small section to cover <a href="http://weblog.rubyonrails.com/2008/10/19/response-splitting-risk">http://weblog.rubyonrails.com/20...</a> ?</p></div> false 2008-10-20T02:33:52+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-20T02:33:56+01:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 I wrote a blog post about it at http://www.rorsecurity.info/journal/2008/10/20/header-injection-and-response-splitting.html So I updated the guide, too. <div><p>I wrote a blog post about it at <a href="http://www.rorsecurity.info/journal/2008/10/20/header-injection-and-response-splitting.html"> http://www.rorsecurity.info/jour...</a></p> <p>So I updated the guide, too.</p></div> false 2008-10-24T17:45:07+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-24T17:45:14+01:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Heiko, all - this guide is a very nice read, i really like it. It is also a bit lengthy though. I'm not sure if a more checklist-style overview would make sense, but it might help to organize the whole thing in such a way that each attack vector starts with a brief overview of maybe: * how does this work? * what countermeasures work (_particularly in rails_)? ... and only after that go into the details. E.g. for SQL injection: * when you interpolate data right into your SQL queries the user can craft malicious SQL and ruin your database * use A, B or C, but pay special attention to D <div><p>Heiko, all - this guide is a very nice read, i really like it.</p> <p>It is also a bit lengthy though. I'm not sure if a more checklist-style overview would make sense, but it might help to organize the whole thing in such a way that each attack vector starts with a brief overview of maybe:</p> <ul> <li>how does this work?</li> <li>what countermeasures work (<em>particularly in rails</em>)?</li> </ul> <p>... and only after that go into the details. E.g. for SQL injection:</p> <ul> <li>when you interpolate data right into your SQL queries the user can craft malicious SQL and ruin your database</li> <li>use A, B or C, but pay special attention to D</li> </ul></div> false 2008-10-26T15:17:09+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-26T15:17:11+00:00 7400 Sven Fuchs Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Sven, thanks. In fact it might be seem to be lengthy, because it is still one page - it will be several pages in the end. In order to make it more easy to scan I included an introduction at the beginning of each chapter, so that you know what it is all about. And I made it a two-in-one document: By scanning the highlighted parts you can easily find all countermeasures for Rails. Indeed it is not a plug'n'play easy-going guide, because I want people to understand why they have to do this or that. 40 pages are not that bad if you compare it to PHP security books:) Anyway, if you'd like to add something specific, or highlight more, you can go to http://www.rorsecurity.info, download the book in pdf, add your comments there and send it to me. <div><p>Sven, thanks.</p> <p>In fact it might be seem to be lengthy, because it is still one page - it will be several pages in the end.</p> <p>In order to make it more easy to scan I included an introduction at the beginning of each chapter, so that you know what it is all about. And I made it a two-in-one document: By scanning the highlighted parts you can easily find all countermeasures for Rails.</p> <p>Indeed it is not a plug'n'play easy-going guide, because I want people to understand why they have to do this or that. 40 pages are not that bad if you compare it to PHP security books:)</p> <p>Anyway, if you'd like to add something specific, or highlight more, you can go to <a href="http://www.rorsecurity.info">http://www.rorsecurity.info</a>, download the book in pdf, add your comments there and send it to me.</p></div> false 2008-10-26T21:45:06+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 new 2008-10-26T21:45:08+00:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Heiko, we're going to mark this one as accepted. Can you add your bio to the authors page, please? <div><p>Heiko, we're going to mark this one as accepted. Can you add your bio to the authors page, please?</p></div> true 2008-11-01T18:11:10+00:00 1366 --- :state: new 20253 7 update-security-guide 0 16213 resolved 2008-11-01T18:11:12+00:00 7211 Mike Gunderloy Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 And also lemme know your email address please :) <div><p>And also lemme know your email address please :)</p></div> true 2008-11-01T18:41:39+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 resolved 2008-11-01T18:41:42+00:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 true 2008-11-02T15:00:07+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 resolved 2008-11-02T15:00:08+00:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Huh? Ok, again: Good news. I've added my bio. Here's my e-mail 42 {et} rorsecurity.info :) <div><p>Huh? Ok, again: Good news. I've added my bio. Here's my e-mail 42 {et} rorsecurity.info :)</p></div> true 2008-11-02T15:02:38+00:00 1366 --- :tag: 20253 7 update-security-guide 0 16213 resolved actionview 2008-11-02T15:02:39+00:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 ... <div><p>...</p></div> true 2008-11-02T15:04:03+00:00 1366 --- :tag: actionview 20253 7 update-security-guide 0 16213 resolved 2008-11-02T15:04:05+00:00 5071 Heiko Webers Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 true 2009-01-06T20:55:09+00:00 1366 --- :title: okey oyna 20253 7 update-security-guide 0 16213 resolved okey oyna 2009-01-06T20:55:13+00:00 1366 Pratik Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 How about SSL security? I'm not sure how to setup a secure SSL connection between browser and Rails application with mongrel and thin. <div><p>How about SSL security?</p> <p>I'm not sure how to setup a secure SSL connection between browser and Rails application with mongrel and thin.</p></div> true 2009-02-13T10:41:15+00:00 1366 --- :state: resolved 20253 7 update-security-guide 0 16213 okey oyna 2009-02-13T10:41:19+00:00 47323 OmniBus Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 There are several spots in 'security' where Textile gets in the way of formatting 'verbatim' stuff, especially where 'regular expressions' in code snippets are concerned. I've found no way to make Textile acknowledge _two_ plus signs with _different_ meaning in regexes, resulting in <notextile><tt>...</tt></notextile> appearing in the HTML output. Is there some form of escape for this? <div><p>There are several spots in 'security' where Textile gets in the way of formatting 'verbatim' stuff, especially where 'regular expressions' in code snippets are concerned. I've found no way to make Textile acknowledge <em>two</em> plus signs with <em>different</em> meaning in regexes, resulting in <tt>...</tt> appearing in the HTML output. Is there some form of escape for this?</p></div> true 2009-02-19T08:51:57+00:00 1366 --- :tag: okey oyna 20253 7 update-security-guide 0 16213 rendering 2009-02-19T08:52:01+00:00 47997 Andreas Scherer Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 As there seems to be no way to change my recent comment, I try to explain that '...' should have read <code><notextile><tt> ... </tt></notextile></code>. (Hope this comes out as intended, because there also seems to be no 'preview' button in this editing system.) <div><p>As there seems to be no way to change my recent comment, I try to explain that '...' should have read <code><tt>...</tt></code> . (Hope this comes out as intended, because there also seems to be no 'preview' button in this editing system.)</p></div> true 2009-02-19T09:14:16+00:00 1366 --- :tag: rendering 20253 7 update-security-guide 0 16213 2009-02-19T09:14:21+00:00 47997 Andreas Scherer Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Nope, here goes a second re-try: &lt;notextile&gt;&lt;tt&gt;...&lt;/tt&gt;&lt;/notextile&gt; <div><p>Nope, here goes a second re-try: &lt;notextile&gt;&lt;tt&gt;...&lt;/tt&gt;&lt;/notextile&gt;</p></div> true 2009-02-19T09:15:29+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 2009-02-19T09:15:34+00:00 47997 Andreas Scherer Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Thanks ascherer, we implemented a temporary workaround http://github.com/lifo/docrails/commit/0d145d9b37a224955f2bbd346376988358966dde <div><p>Thanks ascherer, we implemented a temporary workaround <a href="http://github.com/lifo/docrails/commit/0d145d9b37a224955f2bbd346376988358966dde"> http://github.com/lifo/docrails/...</a></p></div> true 2009-02-28T16:12:43+00:00 1366 --- {} 20253 7 update-security-guide 0 16213 2009-02-28T16:12:49+00:00 11378 Xavier Noria Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 - The Session Expiry section assumes that the user is using a database session store. Most people use the cookie session store, so the described technique is not applicable. Instead, the guide should recommend the reader to store a 'created_at' attribute in the session. The developer should, in a before_filter, check whether 'created_at' is a timestamp that's too old. If it is then the app should expire the session with reset_session. - The User Management section should describe how one should securely store passwords in the database. Not everybody uses or can use restful_authentication. The guide should recommend using bcrypt for storing passwords. - The Session Storage section should tell the reader how to switch to the ActiveRecord store, or refer to the relevant guide, for convenience. <div><ul> <li>The Session Expiry section assumes that the user is using a database session store. Most people use the cookie session store, so the described technique is not applicable. Instead, the guide should recommend the reader to store a 'created_at' attribute in the session. The developer should, in a before_filter, check whether 'created_at' is a timestamp that's too old. If it is then the app should expire the session with reset_session.</li> <li>The User Management section should describe how one should securely store passwords in the database. Not everybody uses or can use restful_authentication. The guide should recommend using bcrypt for storing passwords.</li> <li>The Session Storage section should tell the reader how to switch to the ActiveRecord store, or refer to the relevant guide, for convenience.</li> </ul></div> true 2009-07-22T13:22:32+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 2009-07-22T13:22:37+01:00 10679 Hongli Lai Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1 1366 0 Apologies if this is somewhere in the guide and I've missed it. --------- Failing to filter fields from serialized objects is an easy security problem to miss. For example, if you set up your users using default RESTful routes, then /users/:id.xml will show all fields by default, including (if they exist) the persistence-token, crypted password, salt, email address and openid. You can disable the formatted routes, or you can sanitize these fields by overriding to_xml, to_json, etc to always use the :only => [...whitelisted fields...] flag. The plugin at http://github.com/mrflip/attr_visible that helps set defaults for the serialization methods. ---------- Also be thoughtful about fields that should be writeable on create but not on update: for example, username, or an "I agree to these terms" flag. Remember, even if they're not present in the form they can be submitted as params. Your best bet is to remove them from attr_accessible and set them directly in the create action. <div><p>Apologies if this is somewhere in the guide and I've missed it.</p> <hr> <p>Failing to filter fields from serialized objects is an easy security problem to miss.</p> <p>For example, if you set up your users using default RESTful routes, then<br> /users/:id.xml will show all fields by default, including (if they exist) the persistence-token, crypted password, salt, email address and openid.</p> <p>You can disable the formatted routes, or you can sanitize these fields by overriding to_xml, to_json, etc to always use the<br></p> <pre> <code> :only =&gt; [...whitelisted fields...]</code> </pre> <p>flag.</p> <p>The plugin at <a href= "http://github.com/mrflip/attr_visible">http://github.com/mrflip/attr_visible</a> that helps set defaults for the serialization methods.</p> <hr> <p>Also be thoughtful about fields that should be writeable on create but not on update: for example, username, or an "I agree to these terms" flag. Remember, even if they're not present in the form they can be submitted as params. Your best bet is to remove them from attr_accessible and set them directly in the create action.</p></div> true 2009-10-04T22:27:48+01:00 1366 --- {} 20253 7 update-security-guide 0 16213 2009-10-04T22:55:00+01:00 20241 mrflip Pratik Pratik http://rails.lighthouseapp.com/projects/16213/tickets/7 Guides batch 1