Security is not a feature

Editor's Notes

• #2: So this talk actually started because I noticed fewer security talks, both for beginners and advanced users, popping up at conferences. I pitch on average one security talk to every conference so I know it can’t possibly be for that reason However this is the most broad I’ve spoken about and might get a little ranty Why I like security – my very first conference was at php|tek in 2007 where Chris Schiflett spoke on security In fact, he opened up a website and hacked amazon That really opened my eyes to the fact that the things you’re doing can be used in bad ways
• #3: I believe these are some of the reasons you DON’T see as many security talks as you used to Part of it has to do with the PHP community growing up – and forgetting that for every advanced dev there are still 2 jr. devs Part of it is the boredom factor of having the same kinds of talks year after year… and yet people still need that same information every time Part of it is the advent of people selling security, as though the magic bullet fixes all the things Part of it is over reliance on other people’s solutions to security without a good solid look at what they’re peddling
• #4: However, forgetting about security and failing to realize that security can totally screw you over leads not only to huge data breaches, but small ones as well Even php.net was hacked this year And often the attack vector is not what you think – there are literally thousands of ways to be up a creek without a paddle, hundreds of ways that things can totally break
• #5: IN addition to people trying to hack systems for glory and money and anything else, remember there are also governments undermining the worlds And so much of what you did is built by volunteers Best thing you can really do? Learn some C and help out with your stack
• #6: These stats should scare you – the amount of attacks going on right now is unprecented – for example name 3 big attacks from the last year Who remembers how they occurred? Mention – heartbleed (simple bounds check missing), target (guy stole the hvac password who had COMPLETE ACCESS to the system) adobe – the list goes on
• #7: “is our site secure” “ok it’s time to add security” “let’s run that through the analyzer to make it secure” What – like toggle the security flag? you can never protect anything perfectly all the time. So the question should be, "Is our site secure enough?"
• #8: So there are multiple definitions of security – we’re going to take two One defines security as a state – a Boolean one or zero – but as you know the only things that are really 1s and 0s in computing are the bits flowing in the machine So that’s a horrible thing to view as security So the other thing is to view security as a process But like a process, security is never done So there is no “we are secure”
• #9: The minute you allow your brain to see security as Boolean on or off, you fail Your site will be hacked, and you will be an unhappy camper – or your boss will be and you’ll be fired Any time you let someone else “worry about security” you’re also screwed Don’t let people sell you security!! They’re going to waste your money! So if all these things are NOT security – what IS security?
• #10: Evil monkey’s talk – Imagine all your users are evil cats – because I’ve been told evil monkeys is “speciest”
• #32: Wait– these look pretty damn similar don’t’ they? The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code Open Web Application Security Project
• #33: Buffer overflow; cross-site scripting; SQL injection; canonicalization However I’m going to say don’t “filter” naything – that’s a poorly overloaded word and attempting to “sanitize” or “clean” data is always fail
• #34: Wrap echo up in something so you’re sure that data coming out is always sanitized ZF2 and the autoescape in templates issue (and my take on the whole thing) Be aware of things like mongodb! Theres a page on injection security at php.net AND at the mongodb site – READ AND LEARN
• #35: Network eavesdropping ; Brute force attack; dictionary attacks; cookie replay; credential theft Session hijacking; session replay; man in the middle
• #36: Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs). Session IDs are exposed in the URL (e.g., URL rewriting). Session IDs are vulnerable to session fixation attacks. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout. Session IDs aren’t rotated after successful login. Passwords, session IDs, and other credentials are sent over unencrypted connections. See A6.
• #37: Elevation of privilege; disclosure of confidential data; data tampering; luring attacks
• #39: Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts Access sensitive data in storage; network eavesdropping; data tampering