Your SlideShare is downloading. ×
Resin on Rails
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Resin on Rails

451

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
451
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Shows of hands: “Who used the Internet in 1995? How about 2005? Who uses Facebook now? You’ve gotta admit, we’ve come a long way. Look at how many things you can do with this Web application.How do you build something this complex without having it crash millions of times a day? Use modularization, as you would to build any other complex software system. Break down the application into modules, and have different people in the development team work on different modules. If you try to break down Facebook’s page into modules…
  • …you’ll see that if “comes apart” quite easily. The modules are disjoint, so developers can work on their own features without stepping on each other’s toes. Very efficient!
  • However, this efficiency has its price. The applications we build are so complex that no programmer’s can understand the entire application in detail. We have security experts, or entire teams devoted to security. But this means that all the other programmers don’t concern themselves with security!
  • Most security issues in cloud applications stem from two issues that we call deputy confusion and language confusion. I’d like to explain these issues, so I can show you what we’re doing to mitigate them.
  • A cloud application stores and processes data on behalf of its users, but uses a single set of credentials to access the database.This means that the database fully trusts every request that It receives from the application. So there is no mechanism to protect against a malicious user that manages to trick the application into sending a dangerous request to the database. We say that the database is a confused deputy, because it processes requests without knowing on whose behalf it’s doing the work.Furthermore, since the database is not aware of the application’s multiple users, the application code is responsible for keeping track of data ownership, as well as of any security requirements. This means that every line in the application code must be written with security in mind, which is really hard and error-prone.Last but not least, we have a similar situation on the browser side: the browser fully trusts all the JavaScript code received from the application, and executes it with the application’s credentials.
  • The confused deputy problem is not relegated to the application’s interfaces with the database and browser. Large applications, such as Facebook, are broken into loosely coupled models. Now each module is prone to deputy confusion, and all it takes is one tiny mistake at the interface between two modules.Did you know Facebook has a feature that shows you someone else’s view of your profile, so you can check your privacy settings? Show of hands: how many of you used this?
  • Here’s what the feature looks like. In this example, I’m making sure that Nickolai, my professor, doesn’t get to see any pictures of me drinking beer. Please look at each module, and think -- which user does it represent? Which modules should use my credentials, and which modules should use Nickolai’s credential?
  • Here’s a my answer. Did you get all of them right?If you couldn’t solve this right away, think of the poor guy that had to code this up! One single mistake means private information leakage, and front-page news coverage!
  • Yup. Exactly. Front page news coverage. Facebook’s engineers messed up when they coded this feature!We could say that Facebook has bad engineers and move on. But, let’s face it, Facebook is quite wealthy, and does attract good coders.So we must accept that programmers make mistakes. We can’t fight this problem by asking application developers to “pay more attention”, we have to give them better tools!
  • That was a rather extreme example. Most applications look like this, not like Facebook, so let’s go back to the interfaces between the cloud application, the browser, and the database. When discussing confused deputies, I said “if a malicious user tricks the application into sending a dangerous query to the database”… how does that happen? Why would an application send a bad query to the server?
  • Requests sent from the cloud application to the database use a language called SQL. I have a couple examples up here. As you can see, SQL is a text-based language. It turns out that the easiest way of creating SQL requests is to take the user’s input, and stick it straight into a template.Look at this login example: a user provides a name and a password, and the application checks them against its database. If the name and password match, the user is allowed in.See how the application takes the user strings, and combines them with a pre-defined query string? Now look on the right – a clever user can take advantage of this and log in without a password!The problem here is that the application combines the name and password strings with the query string, as if they were all SQL strings. If all the strings were pieces of SQL, they could be combined together like this. But the truth is, the name and password strings are free-form text, so they have to be SQL-escaped, which makes them SQL strings, before they can be combined with other SQL strings.
  • This sort of attack is called a SQL injection attack, and it used to be so common that there’s an Web comic dedicated to it!
  • By the way, this isn’t a database layer problem! Web development consists entirely of string-based languages, and the problem I mentioned spans all these languages.For example, the user interfaces that you see in the browser are HTML, combined with CSS and JavaScript. All these are text-based languages, which means they’re prone to the same issue as SQL queries. In fact, if you Google for “cross-site scripting attack”, you’ll find that a lot of companies had this issue.The story doesn’t stop here, for complicated applications! Want to send e-mail? Your application needs to talk to an e-mail server, using SMTP, another text-based language. And so on, so forth.
  • Let’s look at a more complex case of language confusion. This is a user sign-up form. You give it an e-mail address and a password, and it makes an account for you. Let’s take a look at what happens behind the scenes.When you click that “Create Account” button, your browser sends all the data you filled out to the application, as a gob of text. Rails, the application framework that I’m working with, takes this text, and turns it into a dictionary of key-value pairs, for convenient access. You can see the dictionary in the top-right. Then there is some code – actually, there’s very little code – that takes the values in this dictionary, and puts them into a new User object. Then the user is saved to the database. Very nice and simple, right?
  • Well, suppose a bad user guesses that our users have an “admin” field in the database, and makes his browser send *these* values to the application. Can you guess what happens? … Oh, I already gave that away. The code will work exactly like before – it will take the input values, and put them into a new User object. So the attacker is now an administrator in our application. That can’t be a good thing!How do we solve this problem? We can’t go around saying “don’t use this feature”, because then we’d be asking programmers to give up productivity for security, and that’s not going to happen. The real problem here is that the dictionary created from the user’s input looks just like a dictionary produced by the application code, which *should* be completely trusted.
  • I’m sorry for talking about mass-assignment, it’s a bit too much for a morning presentation! But I really wanted to explain it to you, so you can understand this.GitHub is an application that stores source code in the cloud, and helps programmers collaborate. They’re the best at what they do. And yet, less than a month ago, a security researcher uncovered a vulnerability that would have let a malicious user modify anyone else’s code. It turns out that one piece of GitHub was vulnerable to the mass-assignment attack that I’ve described earlier. And one piece is all it takes!
  • So, writing secure Web applications is really really hard. But don’t worry, we’re going to make all the problems go away! So let me tell you *how* we’re going to make the problems go away.
  • Do you know this joke, some guy goes to the doctor and says “hey, doctor, if I twist my leg like this, it hurts”, and the doctor says “then stop twisting your leg like that!”In our case, the advice would be “stop being confused!” So let’s start tracking the information that we need to avoid deputy confusion and encoding confusion! Let’s call this additional information “labels”. The left side of this slide has some labels that might be useful. The first two are labels solve deputy confusion by tracking the data’s owner, and his security requirements. The labels on the bottom solve encoding confusion
  • Let’s see how labels work to prevent the mass-assignment attack that I described earlier. Remember, the problem was that a malicious user guessed the name of a sensitive field in our application, and took advantage of a convenience feature in Rails, which takes any input coming to the application, and saves it to the database.
  • Now here’s what happens when the application uses our plug-in. The Rails framework still creates a dictionary out of the data, but this time the dictionary is labeled to reflect that its content is controlled by a user. That label will not allow Rails to create a User object out of the dictionary data. The user’s will be told an internal error ocurred, and the database will remain unchanged.Does this mean we disabled mass-asignment? Not quite, the application developer can get that convenience back by declaring a security policy for the User model.
  • After our application’s developer puts a security policy in place, the Rails code will filter the dictionary containing user input, and remove any fields that aren’t covered by the security policy. Before the User object is written to the database, a filter checks the security policy, which is shown on the bottom-left.In this example, the name, password, and admin values are all labeled to indicate that they were provided by the new user. The labels are checked against the security policy before the new user is saved to the database. This triggers an error, because the admin value is supplied by the new user, but the security policy says only administrators can set that value.
  • Alright, demo time!
  • Time permitting, let me talk a little bit about how we’re going to code this up.
  • Here’s what we need to do to get the functionality that I just described. First, we need to decide where we’re going to label and filter the data. Next, we need to add magic to the programming language, so the labels are automatically propagated. Last, we need to come up with a language that lets programmers describe the security policies.
  • This is what a Rails application looks like. At the front of the application, there’s Rack, turning HTTP requests into Ruby objects, and Ruby objects into HTTP responses. Then there’s controller code, which is responsible for putting together all the bits and pieces of data needed by the response. The controller achieves this by coordinating across models, which implement the application’s business logic and interface with the database. Last, the controller hands off the data to the view code, which is responsible for formatting it in a nice way that will make the user happy.Let’s see how labels and filters fit in this picture.
  • Here’s a neat trick: abstraction! We look at the entire Rails application as a system, a big black box.
  • Data coming into the system must be labeled. Data that’s about to leave the system must be filtered, to make sure that it meets the security policies specified by the application.
  • And that’s about it! It turns out that Rack needs labeling and filtering, since it interacts with the user, and the model needs labeling and filtering, since it interacts with the database. Security policy descriptions belong in the model, because
  • From a programming standpoint, label propagation is the most difficult part. Propagation is essential to the system, because it lets people write their code without worrying about security. Let’s take a look at a couple of examples.The box with green text on the top-left is my phone number. I only want to show my phone number to my friends, so there’s a privacy label associated with it. The box below is a template for a HTML page that shows my phone number. Now suppose someone goes to the page displaying my phone number, so the Web application has to produce an HTML fragment with my phone number. It will do that by combining the template with my actual phone number, and get the HTML fragment on the right.How do we label that? Show of hands – who thinks it’s private information? Who thinks it’s not private information? Hey, as far as I’m concerned, it has my phone number in it, so it’s private! So, some labels propagate automatically, which is a fancy way of saying that they “stick” with the data they’re labeling, as it is processed by the application.
  • Let’s look at the same process from a different perspective. We still have the same phone number and an HTML template on the left, and the same HTML fragment on the right. But this time, we care about encoding.The phone number is something I typed into the Web application, so it’s unsafe. The template on the bottom is part of the application’s source code, so we know it’s safe HTML. What happens when we combine the two? Show of hands – who thinks the result is safe HTML? Who thinks it’s not? Well, my phone number isn’t safe HTML, it might contain a cross-site scripting attack, and that makes the whole result unsafe.The take-away is that encoding labels should not propagate automatically. If you start out with safe HTML and change it, chances are the result will not be safe HTML anymore.
  • By the way, the right thing to do, in this case, is to HTML-escape the phone number, which produces a string that can be safely included in HTML pages. After HTML escaping, the result is labeled as safe HTML, so the HTML fragment coming from the “plus” operation would also be safe HTML that can be sent to the user.
  • And, just for completeness, here’s how the labels look like when the phone number is HTML-escaped correctly.
  • Transcript

    • 1. Securing Web Applications with Practical Data Flow Assertions Victor Costan (龍望) Prof. Srinivas Devadas Prof. Nickolai Zeldovich
    • 2. Motivation
    • 3. MotivationShortcuts Search Account Profile Publishing Instant Feed Apps Newsfeed Comments Chat Featured Ads
    • 4. MotivationToday’s Web applications are complex• Complex applications -> Modules• Modules -> Separate Teams• Separate Teams -> No unified security modelSecurity is a cross-cutting concern; we need anabstraction for expressing policies andenforcing them across the entire application
    • 5. Outline1. Web applications security issues2. Data flow assertions3. Demo4. Our implementation
    • 6. Web Application Security Issues Deputy Confusion Encoding Confusion
    • 7. Deputy Confusion in Web Apps John’s Browser Cloud Application App John String Logic App Jane Jane’s Browser AppBackend Server E-mail Server Database
    • 8. Deputy Confusion at FacebookTest your privacy settings by displaying yourprofile as it is shown to your friends
    • 9. Deputy Confusion at Facebook
    • 10. Deputy Confusion at Facebook Victor Victor Instant Nickolai’s Profile: Victor Feed: Victor’s Profile: Nickolai Victor Chat: Victor Victor’s Feed: Victor’s Friends: Nickolai Nickolai
    • 11. Deputy Confusion at Facebook“Facebook Chat is now down for maintenance. The feature waspresumably disabled following a report that exposed a Facebook securitybug that allowed users to access and view friends’ live chats, friendrequests and friends in common.The report indicates that access to this personal information wasaccessible via Facebook’s privacy settings, with the Preview My Profilefeature creating the loophole to access the private live chats of friends.With Preview My Profile, users can view how their profile appears to anygiven Facebook friend. The bug apparently let those users see the livechats and friend requests of the friend in question.Unfortunately for the company, this is not the first time users’ personalinformation has been exposed without consent. Earlier this year, user e-mail addresses were exposed in a hiccup following a site update.”
    • 12. Deputy Confusion in Web Apps John’s Browser Cloud Application App John String Logic App Jane Jane’s Browser AppBackend Server E-mail Server Database
    • 13. Encoding Confusion in Web Apps• name: pwnall • name: pwnall• password: • password: awesome awesome ” OR “”=“Correct login query: Password-less login query:SELECT * FROM users SELECT * FROM usersWHERE name=“pwnall” WHERE name=“pwnall”AND ANDpassword=“awesome” password=“awesome” ORLIMIT 1 “”=“” LIMIT 1
    • 14. Encoding Confusion in Web Apps
    • 15. Encoding Confusion in Web Apps Browser Application Server HTML View CSS JavaScript String Model String HTTP Request Controller Form Cookies String Text SQL Backend Server E-mail Server Database
    • 16. Encoding Confusion in Web Apps params[:user] Field Value email costan@mit.edu password mit password2 mitemail password admin @user = User.new(params[:user])costan@mit mit false @user.saveit@mit secret true …
    • 17. Encoding Confusion in Web Apps params[:user] Field Value email costan@mit.edu password mit password2 mit admin trueemail password admin @user = User.new(params[:user])costan@mit mit true @user.saveit@mit secret true …
    • 18. Encoding Confusion at GitHub"The root cause of the vulnerability was a failure to properly check incomingform parameters, a problem known as the mass-assignment vulnerability,"GitHub co-founder Tom Preston-Werner wrote in a blog post on Sunday. "Inparallel to the attack investigation we initiated a full audit of the GitHubcodebase to ensure that no other instances of this vulnerability werepresent.”There is little doubt that the vulnerability was serious. As Homakov himselfnoted on his blog, it gave him access to wipe any post in the Rails project andeven "pull/commit/push in any repository on GitHub". He said "lots of Railsapps" were similarly vulnerable.
    • 19. Data Flow Assertions Labels and Filters
    • 20. Eliminate the Confusion!Add Labels to Data Filter Output DataLabels address deputy confusion • Prevent deputy confusion This text was typed by Victor – Check security policies before Only show this to Victor’s friends making database changes – Check privacy policies beforeLabels address encoding confusion outputting data to the user Unsafe text supplied by users • Prevent encoding confusion Safe to splice in a HTML page – Only output HTML-safe pages Safe to splice in a SQL query – Only issue SQL-safe database queries
    • 21. Encoding Confusion in Web Apps params[:user] Field Value email costan@mit.edu password mit password2 mit admin trueemail password admin @user = User.new(params[:user])costan@mit mit true @user.saveit@mit secret true …
    • 22. Eliminating Encoding Confusion params[:user] Field Value email costan@mit.edu password mit password2 mit admin trueemail password admin @user = User.new(params[:user]) costan@mit not created No security policy Blocked for user dictionariesit@mit secret true …
    • 23. Eliminating Deputy Confusion params[:user] Field Value email costan@mit.edu password mit password2 mit admin true @user = User.new(params[:user])Field Policyemail Users can edit their own @user.savepassword Users can edit their own Security policy: only admins Blockedadmin Admins can edit any can write the admin field
    • 24. DemoWhat brought down GitHub
    • 25. Our ImplementationBringing Data Flow Assertions to Ruby on Rails
    • 26. Data Flow Assertions in Rails• Labeling and Filtering – Inserted automatically in the Rails stack• Label propagation – Hard to do without changing the interpreter• API for security policies – Domain-Specific Language (DSL) for model code
    • 27. Labels and Filters in Rails Database Request Model Controller RackResponse View
    • 28. Labels and Filters in Rails Database RequestResponse
    • 29. Labels and Filters in Rails Database Filter Label queries results Request Label input Security policiesResponse Filter output
    • 30. Labels and Filters in Rails Database Filter Label queries results Request Label input Model Controller Security policies RackResponse View Filter output
    • 31. Label Propagation: Only show this to Victor’s friends Unsafe text supplied by users Safe to splice in a HTML page (646) 434-8887 <dl> <dt>Phone number:</dt> <dd>(646) 434-8887</dd> </dl> <dl> <dt>Phone number:</dt> <dd><%= phone %></dd> </dl>Privacy labels (for deputy confusion) propagate automatically
    • 32. Label Propagation: Only show this to Victor’s friends Unsafe text supplied by users Safe to splice in a HTML page (646) 434-8887 <dl> <dt>Phone number:</dt> <dd>(646) 434-8887</dd> </dl> <dl> <dt>Phone number:</dt> <dd><%= phone %></dd> </dl>Unsafe text labels propagate automaticallyOther encoding labels do not propagate automatically
    • 33. Label Propagation: (646) 434-8887 Only show this to Victor’s friends Unsafe text supplied by users HTML escape Safe to splice in a HTML page (646) 434-8887 <dl> <dt>Phone number:</dt> <dd>(646) 434-8887</dd> </dl> <dl> <dt>Phone number:</dt> <dd><%= phone %></dd> </dl>Unsafe text labels propagate automaticallyOther encoding labels do not propagate automatically
    • 34. Label Propagation: Only show this to Victor’s friends Unsafe text supplied by users Safe to splice in a HTML page (646) 434-8887 <dl> <dt>Phone number:</dt> <dd>(646) 434-8887</dd> </dl> <dl> <dt>Phone number:</dt> <dd><%= phone %></dd> </dl>Operations on labeled data are non-trivial, andmaking them fast is challenging.
    • 35. Label Propagation: (646) 434-8887 Only show this to Victor’s friends Unsafe text supplied by users HTML escape Safe to splice in a HTML page (646) 434-8887 <dl> <dt>Phone number:</dt> <dd>(646) 434-8887</dd> </dl> <dl> <dt>Phone number:</dt> <dd><%= phone %></dd> </dl>Operations on labeled data are non-trivial, andmaking them fast is challenging.
    • 36. Thank you!

    ×