-
Already a member?
- Login
WindyCityRails has partnered with Pathable to create an online community for attendees. Pathable enables attendees to communicate with each other before, during, and after the conference. Pathable works on the iPhone and it's written in Rails.
Badges and Profiles
The information you enter in your profile will be used to create your badge and find other attendees like you. Please make sure you've selected a category (designer, developer, entrepreneur, etc.) when completing your profile.
Schedule
View the latest schedule here on Pathable or download a PDF version.
Photos
Share your WindyCityRails photos with others on our Flickr Group.
Twitter
For the latest WindyCityRails and ChicagoRuby.org updates, follow ChicagoRuby on Twitter.
After Party Details
We'll be meeting at 5pm @ Zapatista at 1307 S. Wabash. Zapatista is a short walk from the Roosevelt CTA station. Just walk east on Roosevelt to Wabash, and then a block and a half south.
Sep 20, 8:00 AM- 4:00 PM
Illinois Institute of Technology McCormick Tribune Campus Center
33rd and State
Chicago, IL 60616
You must have an invitation to join the WindyCityRails community.
Who is attending?
.NET
BDD
Centro
Chicago
ChicagoRuby.org
Chirb
Cjug
Consultant
Dad
Designkitchen
IBM
Java
Linux
Lollapalooza
MinneBar
NFJS
Obtiva
Rails
RailsConf
RailsConf 2008
Ruby
RubyConf
SEO
TDD
Web2.0
WisdomGroup
agile
agile software development
apple
beer
business
cycling
design
designer
developer
entrepreneur
entrepreneurship
iphone
javascript
mac
merb
mobile
music
open source
photography
programming
social networks
sports
startups
testing
[All] slides from elastic server presentation
Yan P. Hi guys, I forgot to put up the link to my slides after the WCR talk on virtualization and cloud. If you're interested, they're at slideshare: http://www.... |
Oct 14 |
[All] Announcing follow cost - a Sinatra ap...
Luke F. Hi everybody, follow cost is a site that will tell you how annoying it will be to follow someone on Twitter. http://followcost.com The idea for this site ... |
Oct 13 |
[photography, social media] live
James T. Is this live or podcasted anywhere? |
Sep 20 |
[All] WindyCityRails After Party?
(15) David W. +2 |
Sep 17 |
[All] Couch?
Joe F. I'm coming in for the event from Cleveland. Would anyone be willing to lend a couch for the cause? I'd appreciate it! Thanks! Joe |
Sep 7 |
Attendee feeds| Dave G. | dgiunta posted a photo: | Oct 4 |
| Micah M. | I’m pleased to announce inception of the Software Craftsmanship Group. http://groups.softwarecraftsmanship.org The first meeting is October 13th at 7pm in 8th Light’s office. Hope to see you there. | Oct 2 |
| Zeljko D. | I’ve been aware of asp.net mvc for some time now. I avoided it for few reasons, first it was not complete, but that wouldn’t stop me before. Secondly, it was C# exclusively, I prefer to take .Net in VB variant and I figured if Microsoft would take it so far to make it just C#, [...] | Sep 30 |
| Todd W. | Those who know me well are likely aware that I like to sing. While I’ve got a good ear for relative pitch and I can sort of carry a bearable tune, I’m no singer. So I try to keep my singing to a minimum, even when among friends. And though singing is just another one [...] | Sep 28 |
| Trevor T. | I'm an avid Railscasts watcher, and I was quite happy with one of the recent episodes called Populating a Database. The episode shows you how to load a database with lots of records for demos, design, and/or acceptance testing in an efficient way, but it doesn't cover making sure you're creating valid stuff. I love [...] | Sep 27 |
| Renzo B. | reborg posted a photo: | Sep 27 |
| Dave K. | Sep 26 | |
| Christopher J. | cpher posted a photo: Sent from my Verizon Wireless BlackBerry | Sep 26 |
| Dave G. | Sep 25 | |
| David C. | Sep 24 | |
| Aaron B. | Saturday’s Windy City Rails event was great! There were some great talks and good conversation. I would like to thank Chicago Ruby along with the conference organizers who made all of this possible. You can download slides for my sleight of hand and my security talk in the previous links. | Sep 23 |
| Luke F. | lukefrancl posted a photo: From Safe Baby Handling Tips, resized and cleaned up for use as an avatar. | Sep 22 |
| Barry H. | hess_barry posted a photo: | Sep 22 |
| David C. | Aslak Hellesøy’s Cucumber library will be replacing RSpec’s Story Runner after the RSpec 1.1.5 release (coming soon). Cucumber is a bottom up re-write of the Story Runner, and features a grammar parser using Treetop. When I first started working on support for plain text stories, I chose to roll my own parsing rather than writing a grammar for a number of reasons, but it turns out that we get some great benefits from it. Cucumber supports multiple spoken languages: So now you can say: Funcionalidade: Adição Para evitar erros bobos Como um péssimo matemático Eu quero saber como somar dois números Cenário: Adicionar dois números Dado que eu digitei 50 na calculadora E que eu digitei 70 na calculadora Quando eu aperto o botão de soma Então o resultado na calculadora deve ser 120 Que legal! (How cool is that?) There are already several languages supported, and adding new ones is fairly trivial, so we’ll likely support adding your own languages after some time. Improved backtraces Cucumber includes line numbers from the plain text Feature files, making it much, much easier to understand failures. (NOTE: we’re calling them Features now instead of Stories – look for another post on that subject soon) Simpler configuration Cucumber eliminates steps_for and using_steps_for. Simply define steps using the Given, When and Then methods: #features/steps/accounts.rb Given /I have \$(\d ) in my (.*) account/ do |dollars, account_type| ... end Now require the files with the step definitions you need: cucumber -r features/steps/accounts.rb features/transfer_money ... and you’re off. For most cases you don’t even need that granularity, you can just say … cucumber features ... and cucumber will require any .rb files it finds in the features directory before running the feature files. Fewer surprises When RSpec’s Story Runner finds more than one step definition that can handle a step, the first one it finds wins. This can lead to some painful debugging sessions. When Cucumber finds more than one step definition that can handle a step, you get an error telling you which step definitions are competing, including their location (file and line number), so you can easily see and resolve the conflict. What this means for you if you’re already using Story Runner Cucumber is only a few months old and is nearly feature compatible with RSpec’s Story Runner and already adds a lot of powerful new features. Aslak has converted many, many stories to cucumber features, and is posting about his experiences and refining the process as he goes. By the time we release cucumber as the official scenario runner, the migration path will be well documented and inexpensive. As for a time frame, that’s difficult to say. We’ve been promising the 1.1.5 release for some time and for one reason or another it keeps getting pushed back. We’ll likely wait for the rails 2.2 release and make sure that it is compatible. Rumor has it that is coming soon, but it was coming soon several weeks ago as well, so we’ll have to wait and see. In the mean time, we are freezing development on Story Runner so that we can focus on Cucumber development. Before we officially release cucumber as part of rspec, we’ll create a separate project up on github for just the story runner (likely named rspec-stories) so the code will be available for teams that want to continue to use and/or maintain it. I’ll follow up here and on the rspec-users mailing list (which is mirrored by the rspec google group) as things progress. | Sep 22 |
| Luke F. | Rails provides many great security features. It’s design can also create significant security holes. In the case of ActiveRecord’s mass assignment vulnerability, the security issues are more servere and widespread than many of us recognize. Nearly every open source Rails application I’ve seen is vulnerable, and most closed source ones as well. There’s some great solutions for protecting your application from attack, but first, the problem: The Problem By default ActiveRecord allows visitors access to any writer method, that is, any method ending with an equal sign. This comes courtesy of the ActiveRecord::Base#attributes= method, which is used internally by the main methods that handle creating and updating records, including new(), create(), and update_attributes(). The way most applications are designed means that whatever data a visitor sends to the server will likely find its way through the attributes=() method, and if not protected, ActiveRecord will happily update the records based on what was sent. In less technical terms: ActiveRecord is insecure by default. As an example, let’s look at a request against vulnerable code: 1 2 3 # The request $ curl -X PUT -d "order[price_in_cents]=0" example.com/orders/225 app/models/order.rb 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 class Order < ActiveRecord::Base # Table name: orders # id :integer(11) not null, primary key # price_in_cents :integer(11) # user_id :integer(11) # state :string(255) has_many :line_items acts_as_state_machine :initial => :pending state :pending state :paid def name ... end def shipped_on=(shipping_date) ... end end app/controllers/orders_controller.rb 1 2 3 4 5 6 7 8 9 class OrdersController < ApplicationController ... def update @order.update_attributes(params[:order]) end end Pop quiz: which Order instance methods are exposed to the world? Attributes generated from its table: price_in_cents=, user_id=, state= Attributes generated by association macros: line_item_ids= Other defined writer methods: shipped_on= Ruby’s dynamic nature and ActiveRecord’s changing API make this excercise more of a guess than anything else. Does Rails 2.1 dynamicly generate different writer methods? Will Rails 2.2? How about the plugins and libraries the application relies on? Theoritically, this isn’t a problem since ActiveRecord provides a solution out of the box: “Sensitive attributes can be protected from this form of mass-assignment by using the attr_protected macro. Or you can alternatively specify which attributes can be accessed with the attr_accessible macro” The Reality Naturally, profesional developers experienced with the framework use attr_accessible/attr_protected and don’t suffer from these problems. As a quick poll, here’s a few of the more popular open source code bases: Insoshi is second only to Rails as a top forked project on github. It’s a social networking app developed by a seed funded startup whose team includes the author of a very well-reviewed book on developing social applications in Rails. Mephisto, the Rails-based blogging application, which Railspikes runs on. Anonymous App is a large Rails project with seasoned developers. I’m withholding its details since it has security issues that are still being addressed. Rubyflow, the codebase of Peter Cooper’s very useful Ruby news aggregation site. Spree is a rapidly-maturing ecommerce project and powers RailsEnvy’s new screencast store. Good projects. Professional developers. Every project except Mephisto is vulnerable. Any forum thread in Insoshi will raise exceptions and be unusable after the user_id is changed to a non-existent user. A similiar approach worked on Anonymous and Rubyflow. Since these projects lacked any strategy for handling this kind of problem, it’s highly probable that much more damaging attacks exist. One example: Spree’s public exposure of the 'state' attribute allowed me to make my order appear as though it was paid for when I hadn’t even entered my payment information. While these projects vary in terms of risk, in each case the cost of solving this issue is cheap when compared to the cost of cleaning up after an attack. I’m singling out these applications because they’re popular and open source, but every project I’ve developed has experienced the same security issues. The only thing that seems to change is how much data is vulnerable and how important it is. It’s a difficult problem to manage. Retrofitting security on existing code is a very unpleasant experience. It’s easy to forget when developing new applications. Educating other developers on the problem has proved unreliable. As an aside, I’m impressed by the response of the developers on these projects. Insoshi, Rubyflow, and Spree addressed the issue almost instantly after being informed. It was a reminder to me of how lucky I am to be involved in such a passionate, professional community. Michael Hartl of Insoshi went so far as to write a mass assignment auditing plugin and offers some great advice on how he ended up tackling the problem. A solution Don’t use attr_protected. I haven’t seen a compelling use case for it. It’s functionality is confusing. It should probably be removed from ActiveRecord. Do use attr_accessible. Its white list approach forces an explicit decision on the mass assignablity of attributes. A rule of thumb: if an attribute shouldn’t be in a user submitable form, it shouldn’t be accessible. Review and audit. Even with attr_accessible, a developer can still shoot themselves in the foot without code audits and reviews. Even if the application is secure today, holes will eventually be introduced into the code. In addition to peer review, automated auditing tools are a great, inexpensive way to find such security problems. Make it automatic. Disable mass assignment by default, requiring attr_accessible to be specified for each attribute. I’ve taken this approach on maybe 5 projects now. Here’s how to do it: config/initializers/disable_mass_assignment.rb 1 2 ActiveRecord::Base.send(:attr_accessible, nil) It’s worked quite well, with the exception of two cases where I had to retrofit it on larger applications. That was a nightmare. I’ve been tinkering with a plugin that aims to reduce some of the problems caused by attr_accessible, and make retrofitting a more pleasant experience. It’s not production ready, but I think there’s some small improvements in it worth stealing. The downside: it’s pretty much a guarantee that you’ll run into confusing bugs during development. This is a major problem for developers new to the framework, and is annoying for the more experienced. ActiveRecord used to raise exceptions in development when mass assignment was attempted with an inaccessible attribute. This was great, but there were a few complaints, and conflicts with ActiveResource, so the change was pulled. A better solution? An alternative approach worth exploring is the route taken by Merb, which decided this is the controller’s problem, and has a plugin providing params_accessible functionality. There’s a similar plugin for Rails . This approach may be especially appreciated by developers who want to add some level of protection to an existing application, since less code needs to change. I’ve hesitated to use this on applications that use ActiveRecord, which has a bad habit of making methods part of the public api when they should be privately scoped (those ending in _id, _ids, _count, most enumerables, etc) Because of this, attr_accessible serves double duty by discouraging public use of writer methods that should be private. Not really the best excuse, and I’d like to give the params_protected approach a try on my next Rails project. Regardless of the solution, the cost of designing applications to handle potential mass assignment abuse from the beginning is so much cheaper than attempting to retroactively address the issue. Rails should step up and encourage such design decisions. Whether it’s something as extreme as disabling mass assignment from the start, or an unobtrusive change like adding a commented out attr_accessible line in generated models, the risk shouldn’t be ignored. Security Tools There’s a few other related tools that look promising for developing securer code: Tarantula: A fuzzing plugin that spiders your application looking for problems. Via Stuart Halloway’s post on Revelance’s blog: “It crawls your rails app, fuzzing inputs and analyzing what comes back. We have pointed Tarantula at about 20 Rails applications, both commercial and open source, and have never failed to uncover flaws.” Aaron Bedrak’s Rails Security Audit PDF on Peepcode devotes significant space to getting this up and running. It also covers a few of the common mistakes developers can make when using a framework like Rails, and that alone may make it a worthwhile read. ratproxy: Happened upon this on Google’s excellent security blog . From their announcement post: “[ratproxy] is designed to transparently analyze legitimate, browser-driven interactions with a tested web property and automatically pinpoint, annotate, and prioritize potential flaws or areas of concern.” Audit Mass Assignment: Scans ActiveRecord models looking for potential mass assignment mistakes. Find Mass Assignment: Searches controller actions for likely mass assignment, and then find the corresponding models that don’t have attr_accessible defined. References Railscasts: Hackers Love Mass Assignment Quark Ruby: Rails Security Guide Eric Chapweske: attr_inaccessible plugin Merb’s param protection plugin Christopher J. Bottaro’s params protected for Rails Peepcode: Rails Security Audit PDF Relevance: Tarantul... | Sep 22 |
Sponsors
Lost Invitation
- This site powered by Pathable
- Terms of Service : Privacy : Support : Contact