4 ms·

I appreciate the two links with how to handling security issues in web application. As many have pointed out, they do not teach this stuff in University and ac

by chegra 16y ago

I appreciate the two links with how to handling security issues in web application. As many have pointed out, they do not teach this stuff in University and acquiring such knowledge you tend to have to be very proactive about your development if you do not have industry experience. So thanks a lot for sending these nuggets our way. You stated that the team is manifestly out of their depth in terms of web security, how do you suggest that they proceed given their month deadline? Can they pay a security expert to resolve these issue or no one wants to come within a mile of this?

patio11 16y ago
So one of the painful lessons I picked up in industry is this: an impossible deadline plus a great desire to change is still an impossible deadline. Scheduling is not my bag, and I'm far less well acquainted with Diaspora than you are, but if I was four man months from release at the day job with the state of the project where I think it is I would be sending out emails saying "We will not hit this. It is impossible. We need to cut scope or push back release." to my superiors. I don't know if you can get a security expert to fix this for you. You can certainly wave a big enough check around to get somebody to look over your code, but that won't magically improve code you haven't written yet. Also, it is highly likely that Diaspora is architecturally insecure -- that, beyond the "Oops, didn't check the input" code-level whoopsies that your federation strategy as written (and apparently as not documented outside of the sourcecode) just cannot be made to work right.
- chegra 16y ago
  Thanks for the reply. I agree with the impossible deadline bit. Can you give an example of what you would consider a architecturally insecure web application?
  - patio11 16y ago
    Pretend someone described email over HTTP as a hit new webapp. Email over HTTP is architecturally insecure. Architecturally, there is no way to tell that people are who they say they are. Architecturally, the message is readable by every server between the endpoints. There is no notion of trust baked into email, so you're going to pour gazillions down the drain to retrofit anti-spam mechanics over the insecure architecture. In terms of micro-architecture, take a look at Wordpress. I love Wordpress, don't get me wrong, but it almost can't be made secured due to some design decisions that can't be reversed, such as "Wordpress templates contain executable code with direct unfiltered access to the database."
- batasrki 16y ago
  That's what I feel. Not only do they have an impossible deadline to hit right now, but the deadline they did hit was probably impossible as well. They may have spent most of the summer architecting this thing and figuring out things like "seeds". When it came down to putting code on screen, as it were, they had minimal time to do so. All of these security issues feel like the release was rushed and that they might have been better off releasing it silently, without a way to deploy public nodes, and having a blog post explaining the situation.

by chegra 16y ago

patio11 16y ago

So one of the painful lessons I picked up in industry is this: an impossible deadline plus a great desire to change is still an impossible deadline. Scheduling is not my bag, and I'm far less well acquainted with Diaspora than you are, but if I was four man months from release at the day job with the state of the project where I think it is I would be sending out emails saying "We will not hit this. It is impossible. We need to cut scope or push back release." to my superiors. I don't know if you can get a security expert to fix this for you. You can certainly wave a big enough check around to get somebody to look over your code, but that won't magically improve code you haven't written yet. Also, it is highly likely that Diaspora is architecturally insecure -- that, beyond the "Oops, didn't check the input" code-level whoopsies that your federation strategy as written (and apparently as not documented outside of the sourcecode) just cannot be made to work right.

chegra 16y ago
Thanks for the reply. I agree with the impossible deadline bit. Can you give an example of what you would consider a architecturally insecure web application?
- patio11 16y ago
  Pretend someone described email over HTTP as a hit new webapp. Email over HTTP is architecturally insecure. Architecturally, there is no way to tell that people are who they say they are. Architecturally, the message is readable by every server between the endpoints. There is no notion of trust baked into email, so you're going to pour gazillions down the drain to retrofit anti-spam mechanics over the insecure architecture. In terms of micro-architecture, take a look at Wordpress. I love Wordpress, don't get me wrong, but it almost can't be made secured due to some design decisions that can't be reversed, such as "Wordpress templates contain executable code with direct unfiltered access to the database."
batasrki 16y ago
That's what I feel. Not only do they have an impossible deadline to hit right now, but the deadline they did hit was probably impossible as well. They may have spent most of the summer architecting this thing and figuring out things like "seeds". When it came down to putting code on screen, as it were, they had minimal time to do so. All of these security issues feel like the release was rushed and that they might have been better off releasing it silently, without a way to deploy public nodes, and having a blog post explaining the situation.