4 ms·

> Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings? Yes, and they do. And there's no "lesser extent"; if

by phillmv 13y ago

> Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings? Yes, and they do. And there's no "lesser extent"; if I can't set up a fresh node app with the correct defaults for all of this stuff - if it's not safe out of the box, and I don't have to go out of my way to pick crappy settings - then it's just as vulnerable. People made a lot of fun out of the Rails vulns that hit last year but they were the visible growing pains of having to mature a framework. It's not about the individual bits, it's about the ecosystem at large.

jerf 13y ago
My dream someday is to write a secure-by-default web framework. I've been collecting a list of things it needs to do. It's not surprising that few-to-no frameworks get it even remotely right... there's a lot more to it than meets the eye. CSRF, for instance, is hard to get right. There's a lot of "CSRF" implementations out there, where the scare quotes are part of how I'm naming them. There's headers to avoid clickjacking, which you really ought to default to the strongest protection level and make the user explicitly loosen if they need it. There's "Content Security Policy" headers that ought to be configured. And there's a pervasive problem where the security model for resource access is just laughable... it's up to you to hopefully authenticate a user correctly, and hopefully, you authorize them (hopefully, your framework realizes those are two distinct concepts! but I gotta tell you, the odds are against you), and hopefully, resources don't default to being universally available, and hopefully, that code is all correct.... there's stuff you really ought to do to the querystring to prevent enumeration attacks that would be interesting, there's the whole matter of whether your template permits, encourages, or begs you to shoot your entire site full of cross-site scripting attacks unless you laboriously explain to the template system each and every time "no, I don't want an XSS here... no, I don't want an XSS here... no, I don't want an XSS here" (even after 15+ years of experience here, I still can not reliably work in a templating system like this, something always slips through)... session management is a great deal harder than it looks... framework users should probably actually not be given access to the user's cookie in any direct form because that's begging for problems (darned near anything you can do to a cookie is insecure), to say nothing of how they ought to default to no HTTP and Secure... it's a nightmare out there.
- shadowfiend 13y ago
  Though we don't hit every one of your points, the Lift framework (http://liftweb.net/ http://liftweb.net/) hits a lot of them, and aims to be secure by default as much as possible. XSS is difficult by default because everything lives in a reified XML tree more or less until it goes down the pipe. SiteMap, which is the way that you do routing, disables access to anything that isn't explicitly declared in the site map. CSRF is based on randomized ids for each field and form, tied to this session, this page, and a specific callback function on the server. Content-Security-Policy isn't configured by default at the moment, though that's a good idea to add. X-Frame-Options is set by default. A bit more at http://seventhings.liftweb.net/security http://seventhings.liftweb.net/security .
  - elwell 13y ago
    It took me about 5 minutes to realize Lift is for Scala. It doesn't say that anywhere on the website that I could tell.
    - shadowfiend 13y ago
      Yeah… The site needs work. So does some of the intro documentation (there are a few good books on it, but I mean on-site intro documentation). We're working on these things, and hope to have something awesome to show in the next few months.
- stcredzero 13y ago
  My dream someday is to write a secure-by-default web framework. Devil's Advocacy: How about a front-facing Web Server/WebApp Firewall/language hosting environment? Build something language neutral that can be trivially set up with no more than 3 command-line options and the name of the language/web-framework and you've got the secure defaults out of the box?
  - jerf 13y ago
    You could get some mileage that way for some of the more trivial stuff, but stuff like user authorization (not authentication, authorization) tends to call for deeper integration into what is probably a framework. (Creating a you-call-me library would probably make it too easy to accidentally bypass the security, vs. an I-call-you framework that is guaranteed to go through the secure code path before and after your code.) Still, if there was a standard for middleware in general you probably could at least get all the headers right and provide some sort of safe, general CSRF, session, and authentication (not authorization) framework that way. Unfortunately, the easiest places to stick a generalized middleware, which is probably an nginx module, also tend to lack any sort of backend storage, which is a problem. Whether or not you could sell anyone on the benefits of that would be an interesting question. Getting any sort of XSS protection would involve essentially putting a full Web Application Firewall in front, for instance, which would be infeasible with any reasonable effort, and I'm not sure anyone's going to look twice at a "web security platform" that does little to nothing (effective) against XSS.

by phillmv 13y ago

jerf 13y ago

My dream someday is to write a secure-by-default web framework. I've been collecting a list of things it needs to do. It's not surprising that few-to-no frameworks get it even remotely right... there's a lot more to it than meets the eye. CSRF, for instance, is hard to get right. There's a lot of "CSRF" implementations out there, where the scare quotes are part of how I'm naming them. There's headers to avoid clickjacking, which you really ought to default to the strongest protection level and make the user explicitly loosen if they need it. There's "Content Security Policy" headers that ought to be configured. And there's a pervasive problem where the security model for resource access is just laughable... it's up to you to hopefully authenticate a user correctly, and hopefully, you authorize them (hopefully, your framework realizes those are two distinct concepts! but I gotta tell you, the odds are against you), and hopefully, resources don't default to being universally available, and hopefully, that code is all correct.... there's stuff you really ought to do to the querystring to prevent enumeration attacks that would be interesting, there's the whole matter of whether your template permits, encourages, or begs you to shoot your entire site full of cross-site scripting attacks unless you laboriously explain to the template system each and every time "no, I don't want an XSS here... no, I don't want an XSS here... no, I don't want an XSS here" (even after 15+ years of experience here, I still can not reliably work in a templating system like this, something always slips through)... session management is a great deal harder than it looks... framework users should probably actually not be given access to the user's cookie in any direct form because that's begging for problems (darned near anything you can do to a cookie is insecure), to say nothing of how they ought to default to no HTTP and Secure... it's a nightmare out there.

shadowfiend 13y ago
Though we don't hit every one of your points, the Lift framework (http://liftweb.net/ http://liftweb.net/) hits a lot of them, and aims to be secure by default as much as possible. XSS is difficult by default because everything lives in a reified XML tree more or less until it goes down the pipe. SiteMap, which is the way that you do routing, disables access to anything that isn't explicitly declared in the site map. CSRF is based on randomized ids for each field and form, tied to this session, this page, and a specific callback function on the server. Content-Security-Policy isn't configured by default at the moment, though that's a good idea to add. X-Frame-Options is set by default. A bit more at http://seventhings.liftweb.net/security http://seventhings.liftweb.net/security .
- elwell 13y ago
  It took me about 5 minutes to realize Lift is for Scala. It doesn't say that anywhere on the website that I could tell.
  - shadowfiend 13y ago
    Yeah… The site needs work. So does some of the intro documentation (there are a few good books on it, but I mean on-site intro documentation). We're working on these things, and hope to have something awesome to show in the next few months.
stcredzero 13y ago
My dream someday is to write a secure-by-default web framework. Devil's Advocacy: How about a front-facing Web Server/WebApp Firewall/language hosting environment? Build something language neutral that can be trivially set up with no more than 3 command-line options and the name of the language/web-framework and you've got the secure defaults out of the box?
- jerf 13y ago
  You could get some mileage that way for some of the more trivial stuff, but stuff like user authorization (not authentication, authorization) tends to call for deeper integration into what is probably a framework. (Creating a you-call-me library would probably make it too easy to accidentally bypass the security, vs. an I-call-you framework that is guaranteed to go through the secure code path before and after your code.) Still, if there was a standard for middleware in general you probably could at least get all the headers right and provide some sort of safe, general CSRF, session, and authentication (not authorization) framework that way. Unfortunately, the easiest places to stick a generalized middleware, which is probably an nginx module, also tend to lack any sort of backend storage, which is a problem. Whether or not you could sell anyone on the benefits of that would be an interesting question. Getting any sort of XSS protection would involve essentially putting a full Web Application Firewall in front, for instance, which would be infeasible with any reasonable effort, and I'm not sure anyone's going to look twice at a "web security platform" that does little to nothing (effective) against XSS.