11 ms·

The OWASP Top 10 is killing me

116 points by sidcool 9y ago

SomeStupidPoint 9y ago
> Create a culture of writing and deploying secure code. How? That may sound glib, but this is really just asking everyone to try, right? I would guess that the vast majority of security mistakes stem from ignorance not apathy, and that most coders are trying. Relying on people trying clearly isn't working because there's simply too much to know and it requires too constant of attention. I think we actually do need better tooling, in terms of things like using type systems to flag sensitive data and automatically suggesting a threat modeling report include that item. The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms?
- alexnewman 9y ago
  Every big bug I have seen has been known by a developer and not ticketed and triaged. Apathy, sometimes, ignorance more often, lack of organization, almost always
  - SomeStupidPoint 9y ago
    Anecdata will vary, but my experience has been those bugs get filed, marked "not important", and PMs have no way to sift the security impactful dozen out of hundreds to thousands of small defects in a large product's backlog. (And sometimes that backlog gets deleted, disappearing knowledge of those bugs.) I'm hoping we'll eventually be able to flag bugs with the types involved, and let systems automatically look for combinations that have a set of types that could be dangerous. My point was that it's not enough to focus on good intentions -- or culture -- you have to talk about mechanisms and technologies if you want a reliable system. Because the parts, humans in this case, are highly unreliable in isolation.
- module0000 9y ago
  You can't control humans unfortunately. Humans write code, and some of them will care more about the quality of work than others do. These people will at some point work above/below/with you, and their mistakes will cause you some sort of inconvenience. My mother taught medical school, and she had a saying... "What do you call the least qualified idiot who passes my class?", the answer is "Doctor". There are good coders and bad coders, and unless we start somehow forbidding the bad(but still good enough to get hired) ones to work with/for us - this isn't going to change.
  - diroussel 9y ago
    If one developer can introduce a bug, that is life. But if it can go undetected by the compiler, unit tests, code review, component tests, acceptance tests, mutation testing, static analysis, pen test, etc, then maybe the process can be improved. It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.
    - IncRnd 9y ago
      > It may not be cost effective, but then it's still not a lone developer problem. It's a management decision. That's one way of looking at the issue. Another way is that this is a way for an individual developer to stand out above his or her peers.
- mtgx 9y ago
  I think it's less about the culture and it's more about the big language developers making their languages safe by default for 90% of the developers using them. The "culture" aspect may come in when you're encouraging people to use languages such as Rust over C++, rather than something like "always follow this 50-point security checklist no matter what language you use".
  - IncRnd 9y ago
    Product design, protocols, cryptography, regulatory restrictions, and so many other aspects have nothing to do with the language. Not every vulnerability stems from missing range or bounds checks. I mean this is the best way possible, but your answer shows that even people on HN don't understand what goes into securing a product.
- IncRnd 9y ago
  We've created the beginnings of this type of culture at my employer. More and more, developers reach out to the security team to point out their security conscious thoughts on how to improve new features or the existing codebases. But, this took over a decade. It certainly didn't happen overnight. The inception for this is in training, a security team that markets itself, and in constant communication with managers. Key to this is that devs don't set the direction of their coding projects, which is where many security teams get it wrong. The C-level on down to team managers set the direction. They need to be sold on the security team and the strategic value of their output. Just like passing functional tests, passing security tests needs to be part of a minimum viable product in a way that doesn't stop shipment of products. > The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms? Because, in 2017 developers need to understand more about security than they did just 3 years ago. Universities really haven't kept up with this. The reason you can't push security off to tooling, other than the minimal low-hanging fruit, is that human ingenuity is required. Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.
  - SomeStupidPoint 9y ago
    > Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. That's my point -- why doesn't my IDE auto-generate a template threat assessment report to share with security as part of my code review process? ...why does it rely on me understanding the possible threats, rather than clearly expressing what data I use and letting security set flags on what I should watch? That sounds like a lack of tooling -- because there's not a technical reason.
    - IncRnd 9y ago
      >> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. > Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. I don't think you read prior to replying. Type signatures are orthogonal to the purpose of code. Just because a call is made to XTS don't convey that disk encryption is used. That is the issue that you glossed over. An IDE only has enough information to threat model an application correctly if it had enough information to write the application in the first place.
beager 9y ago
The OWASP Top 10 isn't changing because we can't (or won't) stop not patching those issues. Quite telling that when talking about how to move beyond the baseline security struggles of the OWASP Top 10, TFA provides only superficial suggestions, rather than actual links to libraries, tools, and implementation guides that can be used to quash or audit OWASP Top 10 issues.
ynniv 9y ago
Many of these are due to the use of unstructured strings, which we do because we’re lazy. We’re so lazy about it that our modern languages don’t even support the ability to distinguish user strings from application strings (perl’s taint mode). The workaround in development has been extensive testing, but this is insufficient in an adversarial environment. The best solution is to bring structure to your strings so that you can tasing about how they can be abused. Parse your strings, kids.
- taeric 9y ago
  I challenge the "lazy" claim. We do it in large, because it is hard not to. At the border, you are either passing binary data around, or you are passing structured strings. Building structured strings to send through a border though, is often easiest done by building up an unstructured one and then sending it to the other side. Worse, it is not uncommon to find that the layer you are using to keep things structured becomes a major source of complexity in the application.
- minitech 9y ago
  > We’re so lazy about it that our modern languages don’t even support the ability to distinguish user strings from application strings (perl’s taint mode). “User strings vs. application strings” is too coarse. You just need to enforce types (a type for SQL – see query builders, a type for HTML – see MarkupSafe, etc.) and provide safe constructors for those types. Safe syntactic sugar for those is supported by JavaScript (template strings), Rust (macros), C++ (overloadable string literals), Haskell (overloadable string literals and Template Haskell), and probably plenty of other modern languages. For the others, explicit type wrappers are generally enough (like the aforementioned MarkupSafe in Python) – the only thing that’s lacking is enforcement by libraries.
- jlesk 9y ago
  This is why I introduced LockStrings as a key feature of THT (a language that compiles to PHP). It takes the opposite approach to Perl's taint mode. You mark string literals as safe -- everything else is untrusted. Functions that do risky things (Database, System calls, etc.) only accept LockStrings and are responsible for escaping, so all you have to do is provide the placeholders. https://tht.help/tutorials/language-tour#lock-strings https://tht.help/tutorials/language-tour#lock-strings
nanodano 9y ago
Most developers don't know security http://www.akashasec.com/most-developers-dont-know-security/ http://www.akashasec.com/most-developers-dont-know-security/
methodover 9y ago
We experienced our first successful attack at my startup a few weeks ago. What got us wasn't anything on the top ten list. I'm pretty sure it isn't covered anywhere in OWASP to my knowledge. Users reuse passwords across different websites. An attacker tried a database of usernames/passwords sourced from elsewhere; a small percentage (about 1000 out of more than 10M requests) succeeded. 100 of those had something to steal. Attacker used a botnet, so our IP-based fail-to-ban logic was ineffective. We thought about lots of ways to deal with this moving forward. My boss (CEO) didn't want to implement any kind of 2 factor authentication, because it's cumbersome and will lower conversion rates. We took a different strategy which is kind of complicated to explain, but it's not nearly as secure. Anyway. What gets me is like: Password authentication SUCKS. It's a terrible terrible authentication strategy. It's awful. It should not be relied upon. It would be good if humans didn't reuse passwords. But we do. So it sucks.
- sixhobbits 9y ago
  You can mitigate this almost completely by finding that "database of usernames/passwords sourced from elsewhere" (they're not hard to find) and blacklisting them. Users should not be allowed to use any breached password when they register. A simple message saying "this message was included in a recent password breach and is therefore not secure" should suffice to prevent users getting annoyed that they can't use their favourite password on your site. Enforcing a minimum length of 10 or even 12 is a great way to eliminate nearly all previously leaked passwords from being used on your site, and it further encourages users to use password managers. Passwords are shit, but they're here to stay for a while still.
  - wongarsu 9y ago
    HaveIBeenPwned makes this really easy by publishing a list of hashed passwords that have been observed in breaches [1]. The list is by no means complete, but it should cover a lot and is very easy to setup. 1: https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords
    - methodover 9y ago
sixhobbits 9y ago
Not all vulnerabilities stem from ignorance, although this seems to be the default assumption of the infosec community. Writing secure code takes more time than writing insecure code. Time is expensive. In every organization I've worked, security has been neglected pretty explicitly. It's not a case of "OK this looks secure", but instead more like "I am aware that our codebase has some security issues but I need to prioritize rushing out this new feature/improving our CPA". And this is not always the wrong choice. For most organizations, the probability of having someone who is both malicious and competent enough to exploit an XSS vuln visit your site is pretty small. The chance that you'll go under if you don't get that new feature out or improve your CPA is pretty high. If you want to criticise the state of security (and there is definite room for criticism), I think there is a need for tools and education to allow people to better make these decisions. We need ways to communicate a) how likely it is that we'll be attacked? b) what would the consequences be? For now, when these questions are asked, the answers are almost always "pretty small" and "uh, possibly like really bad, depending on the attacker" We need ways to translate these into numbers that we can compare with profit margins, etc. This is way more important than actually learning how to mitigate SQLi.
- mindcrime 9y ago
  We need ways to translate these into numbers that we can compare with profit margins, etc. There is a way. I'll refer you to How To Measure Anything by Douglas Hubbard. His model is based on a combination of things: 1. Calibrated Probability Assessments 2. nth order effects 3. building a mathematical model 4. Monte Carlo simulation apply his methodology and you can determine the impact of "hard to quantify" variable like "security" and get a probability distribution that can be used to assign values to specific scenarios. Yeah, it's a little bit complicated and time-consuming; but the best things in life are, no?
  - collingreene 9y ago
    If you like that book he wrote one about applying those ideas to this exact problem! https://www.amazon.com/How-Measure-Anything-Cybersecurity-Risk/dp/1119085292 https://www.amazon.com/How-Measure-Anything-Cybersecurity-Ri... I've never managed to make the effort to apply his ideas with much rigor but they are definitely appealing and possibly better than the alternative of "maybe nothing".
gcb0 9y ago
I love OWASP. but everything they do has zero usability. At times it looks like a bunch of 7yr old trying to mimic a big corporation. This list is a huge example of it. Instead of a text, they have a repo, that generates a huge PDF, mentioned in a press release, with the release described verbosily in a wiki! And I went trhu all those hops, and I still couldn't find a single link that points me to what "Injection" means.
- rst 9y ago
  It's a generalization of SQLi, to cover situations where the queries (or commands, or whatever) built up by unguarded string concatenation are something other than SQL. (Though, oddly, the examples in the current draft seem to all be SQL based.)
  - gcb0 9y ago
    thanks. have an upvote. I was mostly interested in learning why they have such atrocious publications/content organization though... i write on that subject internally for my employer. if OWASP goal is to inform the public, and not look like a mega-corporation, they are doing things very wrong. Their press releases are less parseable than the worse our legal department can produce.
partycoder 9y ago
A functional prototype is not finished software, but it is for many people considered to be a product. Functional prototypes in many cases do not even implement their functional requirements properly, let alone the non-functional ones like security. Security in any form is not a priority for many startups. Especially the ones that aim to be acquired before their hot potato blows up.
nfriedly 9y ago
This is one thing I like about IBM: they have a separate security team that audits stuff before you ship it. I was working on a react app where I set up server-side rendering, and then had it JSON-encode the state and dump it into a script tag in the end of the HTML. My thinking at the time was "It's JSON-encoded, and it's all the user's own data anyways, so it's safe." Eventually I needed something from the querystring and for whatever reason put it into the state. It turns out that a <script> tag from the querystring in a string in a blob of JSON in a HTML page will execute. Oops. Fortunately IBM's security team caught it before it ever shipped. Now it's been fixed and the app has a CSP header to help nullify any future mistakes.
- mmcnl 9y ago
  That's weird, shouldn't that be a responsibility of your router? Or did you roll your own?
  - nfriedly 9y ago
    I think it was a combination of react-router and react-router-redux, and something I was doing for SSR that led to the issue. The initial fix was just to delete the react-router-redux data from the store just before JSON.stringify'ing it. There were a number of weird things that were specific to my usage, so I'm not sure that the vulnerability would be there in a "proper" setup.
vacri 9y ago
Why should the top 10 change? We still secure our houses with locks, secure our neighbourhoods with police, secure our borders with armies. We drive safer cars these days yet we still secure our road edges with barriers at dangerous points. Why would the categories of risk change on a bi-annual basis?
- MattPalmer 9y ago
  One might hope that these low hanging fruit would be addressed, leaving more sophisticated attacks to fill the top 10. Buffer overflows used to be a major vulnerability. These only stopped being such a major problem when languages that prevented them became widely used. The lesson is probably that developers and the business don't have the time or inclination to address them, and the nest defence is to make the problem impossible rather than relying on good security practices being followed.
JeanMarcS 9y ago
> This means that the malicious script can read the user's cookies, session tokens, stored usernames and passwords, or files on a local hard drive. I've seen those. On a website for a company who hired me for building their server infrastructure. The password was in clear text in the main cookie. I signaled it and the dev team corrected it. It was only 3 years ago...
ianamartin 9y ago
In my experience, it’s not been a lack of understanding or knowledge on the devs’ part. It’s been more about how much of a hurry we are in to deploy. I’ve tried a few different strategies to get around this. 1. Build the backend first. Don’t show a UI that looks anything like it’s functional until you sneak in the requirements that you know are needed but can’t get buy-in from. Fails because PMs and stakeholders don’t see progress fast enough. 2. Plan security into the design specs and feature list. Fails because there’s always someone who (like when presenting speed as a feature) is higher up than you who will cross it off the list because “we’re behind a VPN/our users are too stupid to hack us/the only speed that matters is how fast we can deploy this. 3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way. This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress. Direct, straightforward communication about the importance of security doesn’t work. Obfuscating your team’s process to sneak in best practices doesn’t work. The bottom line is that—again, much like speed—-if your leadership doesn’t see the value or can’t be persuaded to see it, it’s not going to happen, even from very well-educated teams. This is a cultural issue that an individual contributor can only do so much about by choosing the safest frameworks to start with. And that’s about it. It’s added a number of items to the list of things I ask in interviews now that I’m on the job market again. Where does the company prioritize security in web applications? Where does it prioritize speed? How hard do people have to fight to get these included as product features? I won’t make a blanket statement that if those answers are not to my liking, I won’t take the job. But you need to know where these things stand as company commitments before you accept a job with a primary role of web developer.
- Sacho 9y ago
  > 3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way. This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress. It sounds like this approach should work, because you can sell a bunch of reasons rather than just security. If you don't take the needed time to develop the code, you will have correctness(not enough testing) and maintenance(not enough refactoring) problems alongside security issues. If the company's leadership shuns all three in favor of quicker deployment, then security is most likely not going to be the biggest problem, it would be all the bugs you have to chase down in spaghetti code.
ianamartin 9y ago
Also, a response to some of the mitigation’s suggested here: 1. Prevent people from reusing passwords from other websites/lists. Fail: you shouldn’t know if the pw is the same as any other pw. If you can tell, you are already doing it wrong. PW + random salt protects you against reused passwords. If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. (re)Captcha: fuck you. Even if it’s after the second failed attempt. Fuck you. I hate you. You are implementing security theater, making everything worse for the user, and killing your conversation rate for everyone but spammers,who have this down pat. Pushing x numbers of rules, whether or not they are special characters or not. 8 vs. 10 doesn’t matter that much. Push passphrases instead. Multi-factor is sort-of okay, but the implementations are garbage and the user experience is awful. I’m not a security expert or a researcher. I’m a data engineer with a lot of web app experience. But most of the advice in this thread is total garbage. Web apps need to find a way to make the gold-standard of authentication accessible to users: per-device public/private key pairs. Until we do that well, we suck at life and our jobs compared to native apps. I include myself when I say that we have held ourselves to an incredibly low standard. OWASP is a pathetically low bar. Yet we often fail. It’s time to step up our game, people. And it’s on us to do it.
- jjnoakes 9y ago
  > PW + random salt protects you against reused passwords. That only protects you if every other site does it. If you salt your passwords and some other site which doesn't is compromised, you are hosed too if your users reused passwords. > If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. Sorry, don't follow. How is it a mistake to compare a password your user is entering to a known blacklist of compromised passwords?
  - ianamartin 9y ago
    To your second point, giving this information leaks too much about the user trying to create a password. I go to a site and try to register an account. The app says, “sorry, you can’t use that password because it’s been used with this username before and has been compromised.” Your attacker now knows that the user is in a compromised list. You can’t do this without leaking information about the user. If you compare to a global list instead of the user, then you’ve leaked the opposite information. That at least one user is on some list of compromised passwords. You can’t do that without leaking information about at least one user. And, as discussed, exponential fall-off doesn’t work in the world of distributed attacks. That’s my response to point two in a nutshell. But I’ll add that the application layer should have no knowledge of the plain-text password to begin with. The password should be hashed on the client side before being sent to the application layer. Then salted and hashed and stored in the database. The double hashing doesn’t get you anything in crypto terms as far as I know, but it means that if your application leaks or the network between the front and back end is MITMd, then you are leaking hashes and not plain text. Of course, if the network between your front and back ends is compromised, you fucked up pretty bad anyway. But it adds at least a little effort for the attacker instead of allowing them to just grab username and password pairs in plain text. I also salt + hash usernames in transit, so it’s not immediately obvious who is associated with what. That gets me to your first point. You are correct that doing all of this doesn’t protect any individual user from illicit access, and I should have been more clear about my concerns. If an individual user chooses to reuse passwords, their account can be compromised. You are 100% correct about that. But in the case of a data breach, which is what I was thinking of in terms of “preotection”, it’s going to be really hard to compromise a collection of salted, hashed username/password combos. In my opinion—again, I’m not a security expert, and I welcome criticisms such as yours—I don’t think we’re going to get people to stop reusing passwords. And I don’t think we’re going to get people to use multi-auth any time soon. I think this is the best we can do until someone comes up with a way to get per-device key pairs to work in a friendly way. Thanks for your thoughts and criticisms and questions.
tofflos 9y ago
The article mentions home grown authentication and authorization mechanism and suggests that we stick to proven solutions. The problem is that, at least within the Java community, that library-, framework- and application server authors are not providing easy to use solutions that integrate well with applications. Instead there are a bunch of complex solutions that require manual configuration, proprietary extensions and arcane programming models for something that sits in front the application making it difficult for application authors to provide a seamless user experience. No wonder so many people are rolling their own. This is why JSR-375 was created. It needs to happen! I've tried the reference implementation and it was awesome! If you're working on the JSR or the RI then I'm rooting for you! But I don't know if anyone is working on them these days?
tim333 9y ago
It's always seemed to me that the web2py approach of providing a secure starter app with auth included and then letting developers break it if they want seems quite a sensible way to go. Not sure how well that works in other frameworks. http://www.web2py.com/book/default/chapter/01#Security http://www.web2py.com/book/default/chapter/01#Security
mmcnl 9y ago
Perhaps security isn't as easy as (often self-proclaimed) security experts think it is. Unlike them, developers don't devote 100% of their time to security. I couldn't care less about people standing on the sideline yelling at me what I can't do. How about proactively seeking out and suggesting meaningful improvements which actually help increase security? Security in big corporations often boils down to a unit of people ranting about everything and nothing, and telling people what they can't do, while in fact, they should be doing the opposite.
BrandoElFollito 9y ago
It is a shame that A10 and A7 were rejected. In our mobile held, APIs are often unprotected because authentication is hard for machine to machine transactions. OpenID and the misused oAuth are a solution but it is hard to implement. A7 addressed an organizational issue completely absent from the top 10. Since there à so much controversies, they sold have made it a top 12.

116 points by sidcool 9y ago

> Create a culture of writing and deploying secure code. How? That may sound glib, but this is really just asking everyone to try, right? I would guess that the vast majority of security mistakes stem from ignorance not apathy, and that most coders are trying. Relying on people trying clearly isn't working because there's simply too much to know and it requires too constant of attention. I think we actually do need better tooling, in terms of things like using type systems to flag sensitive data and automatically suggesting a threat modeling report include that item. The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms?

alexnewman 9y ago
Every big bug I have seen has been known by a developer and not ticketed and triaged. Apathy, sometimes, ignorance more often, lack of organization, almost always
- SomeStupidPoint 9y ago
  Anecdata will vary, but my experience has been those bugs get filed, marked "not important", and PMs have no way to sift the security impactful dozen out of hundreds to thousands of small defects in a large product's backlog. (And sometimes that backlog gets deleted, disappearing knowledge of those bugs.) I'm hoping we'll eventually be able to flag bugs with the types involved, and let systems automatically look for combinations that have a set of types that could be dangerous. My point was that it's not enough to focus on good intentions -- or culture -- you have to talk about mechanisms and technologies if you want a reliable system. Because the parts, humans in this case, are highly unreliable in isolation.
module0000 9y ago
You can't control humans unfortunately. Humans write code, and some of them will care more about the quality of work than others do. These people will at some point work above/below/with you, and their mistakes will cause you some sort of inconvenience. My mother taught medical school, and she had a saying... "What do you call the least qualified idiot who passes my class?", the answer is "Doctor". There are good coders and bad coders, and unless we start somehow forbidding the bad(but still good enough to get hired) ones to work with/for us - this isn't going to change.
- diroussel 9y ago
  If one developer can introduce a bug, that is life. But if it can go undetected by the compiler, unit tests, code review, component tests, acceptance tests, mutation testing, static analysis, pen test, etc, then maybe the process can be improved. It may not be cost effective, but then it's still not a lone developer problem. It's a management decision.
  - IncRnd 9y ago
    > It may not be cost effective, but then it's still not a lone developer problem. It's a management decision. That's one way of looking at the issue. Another way is that this is a way for an individual developer to stand out above his or her peers.
mtgx 9y ago
I think it's less about the culture and it's more about the big language developers making their languages safe by default for 90% of the developers using them. The "culture" aspect may come in when you're encouraging people to use languages such as Rust over C++, rather than something like "always follow this 50-point security checklist no matter what language you use".
- IncRnd 9y ago
  Product design, protocols, cryptography, regulatory restrictions, and so many other aspects have nothing to do with the language. Not every vulnerability stems from missing range or bounds checks. I mean this is the best way possible, but your answer shows that even people on HN don't understand what goes into securing a product.
IncRnd 9y ago
We've created the beginnings of this type of culture at my employer. More and more, developers reach out to the security team to point out their security conscious thoughts on how to improve new features or the existing codebases. But, this took over a decade. It certainly didn't happen overnight. The inception for this is in training, a security team that markets itself, and in constant communication with managers. Key to this is that devs don't set the direction of their coding projects, which is where many security teams get it wrong. The C-level on down to team managers set the direction. They need to be sold on the security team and the strategic value of their output. Just like passing functional tests, passing security tests needs to be part of a minimum viable product in a way that doesn't stop shipment of products. > The suggestion that people spend a lot of effort all the time is clearly not going to work -- why can't we ease that barrier by focusing on better tooling so security becomes a natural part of the process, enforced by actual mechanisms? Because, in 2017 developers need to understand more about security than they did just 3 years ago. Universities really haven't kept up with this. The reason you can't push security off to tooling, other than the minimal low-hanging fruit, is that human ingenuity is required. Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose.
- SomeStupidPoint 9y ago
  > Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. That's my point -- why doesn't my IDE auto-generate a template threat assessment report to share with security as part of my code review process? ...why does it rely on me understanding the possible threats, rather than clearly expressing what data I use and letting security set flags on what I should watch? That sounds like a lack of tooling -- because there's not a technical reason.
  - IncRnd 9y ago
    >> Vulnerabilities happen from wrong function calls, yes, but also through using the wrong types of calls for the particular purpose. > Which is detectable through static analysis of the type signatures -- at least to the point of ensuring that a threat assessment document includes a section on what they did there. I don't think you read prior to replying. Type signatures are orthogonal to the purpose of code. Just because a call is made to XTS don't convey that disk encryption is used. That is the issue that you glossed over. An IDE only has enough information to threat model an application correctly if it had enough information to write the application in the first place.

beager 9y ago

The OWASP Top 10 isn't changing because we can't (or won't) stop not patching those issues. Quite telling that when talking about how to move beyond the baseline security struggles of the OWASP Top 10, TFA provides only superficial suggestions, rather than actual links to libraries, tools, and implementation guides that can be used to quash or audit OWASP Top 10 issues.

ynniv 9y ago

Many of these are due to the use of unstructured strings, which we do because we’re lazy. We’re so lazy about it that our modern languages don’t even support the ability to distinguish user strings from application strings (perl’s taint mode). The workaround in development has been extensive testing, but this is insufficient in an adversarial environment. The best solution is to bring structure to your strings so that you can tasing about how they can be abused. Parse your strings, kids.

taeric 9y ago
I challenge the "lazy" claim. We do it in large, because it is hard not to. At the border, you are either passing binary data around, or you are passing structured strings. Building structured strings to send through a border though, is often easiest done by building up an unstructured one and then sending it to the other side. Worse, it is not uncommon to find that the layer you are using to keep things structured becomes a major source of complexity in the application.
minitech 9y ago
> We’re so lazy about it that our modern languages don’t even support the ability to distinguish user strings from application strings (perl’s taint mode). “User strings vs. application strings” is too coarse. You just need to enforce types (a type for SQL – see query builders, a type for HTML – see MarkupSafe, etc.) and provide safe constructors for those types. Safe syntactic sugar for those is supported by JavaScript (template strings), Rust (macros), C++ (overloadable string literals), Haskell (overloadable string literals and Template Haskell), and probably plenty of other modern languages. For the others, explicit type wrappers are generally enough (like the aforementioned MarkupSafe in Python) – the only thing that’s lacking is enforcement by libraries.
jlesk 9y ago
This is why I introduced LockStrings as a key feature of THT (a language that compiles to PHP). It takes the opposite approach to Perl's taint mode. You mark string literals as safe -- everything else is untrusted. Functions that do risky things (Database, System calls, etc.) only accept LockStrings and are responsible for escaping, so all you have to do is provide the placeholders. https://tht.help/tutorials/language-tour#lock-strings https://tht.help/tutorials/language-tour#lock-strings

nanodano 9y ago

Most developers don't know security http://www.akashasec.com/most-developers-dont-know-security/ http://www.akashasec.com/most-developers-dont-know-security/

methodover 9y ago

We experienced our first successful attack at my startup a few weeks ago. What got us wasn't anything on the top ten list. I'm pretty sure it isn't covered anywhere in OWASP to my knowledge. Users reuse passwords across different websites. An attacker tried a database of usernames/passwords sourced from elsewhere; a small percentage (about 1000 out of more than 10M requests) succeeded. 100 of those had something to steal. Attacker used a botnet, so our IP-based fail-to-ban logic was ineffective. We thought about lots of ways to deal with this moving forward. My boss (CEO) didn't want to implement any kind of 2 factor authentication, because it's cumbersome and will lower conversion rates. We took a different strategy which is kind of complicated to explain, but it's not nearly as secure. Anyway. What gets me is like: Password authentication SUCKS. It's a terrible terrible authentication strategy. It's awful. It should not be relied upon. It would be good if humans didn't reuse passwords. But we do. So it sucks.

sixhobbits 9y ago
You can mitigate this almost completely by finding that "database of usernames/passwords sourced from elsewhere" (they're not hard to find) and blacklisting them. Users should not be allowed to use any breached password when they register. A simple message saying "this message was included in a recent password breach and is therefore not secure" should suffice to prevent users getting annoyed that they can't use their favourite password on your site. Enforcing a minimum length of 10 or even 12 is a great way to eliminate nearly all previously leaked passwords from being used on your site, and it further encourages users to use password managers. Passwords are shit, but they're here to stay for a while still.
- wongarsu 9y ago
  HaveIBeenPwned makes this really easy by publishing a list of hashed passwords that have been observed in breaches [1]. The list is by no means complete, but it should cover a lot and is very easy to setup. 1: https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords
  - methodover 9y ago

sixhobbits 9y ago

Not all vulnerabilities stem from ignorance, although this seems to be the default assumption of the infosec community. Writing secure code takes more time than writing insecure code. Time is expensive. In every organization I've worked, security has been neglected pretty explicitly. It's not a case of "OK this looks secure", but instead more like "I am aware that our codebase has some security issues but I need to prioritize rushing out this new feature/improving our CPA". And this is not always the wrong choice. For most organizations, the probability of having someone who is both malicious and competent enough to exploit an XSS vuln visit your site is pretty small. The chance that you'll go under if you don't get that new feature out or improve your CPA is pretty high. If you want to criticise the state of security (and there is definite room for criticism), I think there is a need for tools and education to allow people to better make these decisions. We need ways to communicate a) how likely it is that we'll be attacked? b) what would the consequences be? For now, when these questions are asked, the answers are almost always "pretty small" and "uh, possibly like really bad, depending on the attacker" We need ways to translate these into numbers that we can compare with profit margins, etc. This is way more important than actually learning how to mitigate SQLi.

mindcrime 9y ago
We need ways to translate these into numbers that we can compare with profit margins, etc. There is a way. I'll refer you to How To Measure Anything by Douglas Hubbard. His model is based on a combination of things: 1. Calibrated Probability Assessments 2. nth order effects 3. building a mathematical model 4. Monte Carlo simulation apply his methodology and you can determine the impact of "hard to quantify" variable like "security" and get a probability distribution that can be used to assign values to specific scenarios. Yeah, it's a little bit complicated and time-consuming; but the best things in life are, no?
- collingreene 9y ago
  If you like that book he wrote one about applying those ideas to this exact problem! https://www.amazon.com/How-Measure-Anything-Cybersecurity-Risk/dp/1119085292 https://www.amazon.com/How-Measure-Anything-Cybersecurity-Ri... I've never managed to make the effort to apply his ideas with much rigor but they are definitely appealing and possibly better than the alternative of "maybe nothing".

gcb0 9y ago

I love OWASP. but everything they do has zero usability. At times it looks like a bunch of 7yr old trying to mimic a big corporation. This list is a huge example of it. Instead of a text, they have a repo, that generates a huge PDF, mentioned in a press release, with the release described verbosily in a wiki! And I went trhu all those hops, and I still couldn't find a single link that points me to what "Injection" means.

rst 9y ago
It's a generalization of SQLi, to cover situations where the queries (or commands, or whatever) built up by unguarded string concatenation are something other than SQL. (Though, oddly, the examples in the current draft seem to all be SQL based.)
- gcb0 9y ago
  thanks. have an upvote. I was mostly interested in learning why they have such atrocious publications/content organization though... i write on that subject internally for my employer. if OWASP goal is to inform the public, and not look like a mega-corporation, they are doing things very wrong. Their press releases are less parseable than the worse our legal department can produce.

partycoder 9y ago

A functional prototype is not finished software, but it is for many people considered to be a product. Functional prototypes in many cases do not even implement their functional requirements properly, let alone the non-functional ones like security. Security in any form is not a priority for many startups. Especially the ones that aim to be acquired before their hot potato blows up.

nfriedly 9y ago

This is one thing I like about IBM: they have a separate security team that audits stuff before you ship it. I was working on a react app where I set up server-side rendering, and then had it JSON-encode the state and dump it into a script tag in the end of the HTML. My thinking at the time was "It's JSON-encoded, and it's all the user's own data anyways, so it's safe." Eventually I needed something from the querystring and for whatever reason put it into the state. It turns out that a <script> tag from the querystring in a string in a blob of JSON in a HTML page will execute. Oops. Fortunately IBM's security team caught it before it ever shipped. Now it's been fixed and the app has a CSP header to help nullify any future mistakes.

mmcnl 9y ago
That's weird, shouldn't that be a responsibility of your router? Or did you roll your own?
- nfriedly 9y ago
  I think it was a combination of react-router and react-router-redux, and something I was doing for SSR that led to the issue. The initial fix was just to delete the react-router-redux data from the store just before JSON.stringify'ing it. There were a number of weird things that were specific to my usage, so I'm not sure that the vulnerability would be there in a "proper" setup.

vacri 9y ago

Why should the top 10 change? We still secure our houses with locks, secure our neighbourhoods with police, secure our borders with armies. We drive safer cars these days yet we still secure our road edges with barriers at dangerous points. Why would the categories of risk change on a bi-annual basis?

MattPalmer 9y ago
One might hope that these low hanging fruit would be addressed, leaving more sophisticated attacks to fill the top 10. Buffer overflows used to be a major vulnerability. These only stopped being such a major problem when languages that prevented them became widely used. The lesson is probably that developers and the business don't have the time or inclination to address them, and the nest defence is to make the problem impossible rather than relying on good security practices being followed.

JeanMarcS 9y ago

> This means that the malicious script can read the user's cookies, session tokens, stored usernames and passwords, or files on a local hard drive. I've seen those. On a website for a company who hired me for building their server infrastructure. The password was in clear text in the main cookie. I signaled it and the dev team corrected it. It was only 3 years ago...

ianamartin 9y ago

In my experience, it’s not been a lack of understanding or knowledge on the devs’ part. It’s been more about how much of a hurry we are in to deploy. I’ve tried a few different strategies to get around this. 1. Build the backend first. Don’t show a UI that looks anything like it’s functional until you sneak in the requirements that you know are needed but can’t get buy-in from. Fails because PMs and stakeholders don’t see progress fast enough. 2. Plan security into the design specs and feature list. Fails because there’s always someone who (like when presenting speed as a feature) is higher up than you who will cross it off the list because “we’re behind a VPN/our users are too stupid to hack us/the only speed that matters is how fast we can deploy this. 3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way. This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress. Direct, straightforward communication about the importance of security doesn’t work. Obfuscating your team’s process to sneak in best practices doesn’t work. The bottom line is that—again, much like speed—-if your leadership doesn’t see the value or can’t be persuaded to see it, it’s not going to happen, even from very well-educated teams. This is a cultural issue that an individual contributor can only do so much about by choosing the safest frameworks to start with. And that’s about it. It’s added a number of items to the list of things I ask in interviews now that I’m on the job market again. Where does the company prioritize security in web applications? Where does it prioritize speed? How hard do people have to fight to get these included as product features? I won’t make a blanket statement that if those answers are not to my liking, I won’t take the job. But you need to know where these things stand as company commitments before you accept a job with a primary role of web developer.

Sacho 9y ago
> 3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way. This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress. It sounds like this approach should work, because you can sell a bunch of reasons rather than just security. If you don't take the needed time to develop the code, you will have correctness(not enough testing) and maintenance(not enough refactoring) problems alongside security issues. If the company's leadership shuns all three in favor of quicker deployment, then security is most likely not going to be the biggest problem, it would be all the bugs you have to chase down in spaghetti code.

ianamartin 9y ago

Also, a response to some of the mitigation’s suggested here: 1. Prevent people from reusing passwords from other websites/lists. Fail: you shouldn’t know if the pw is the same as any other pw. If you can tell, you are already doing it wrong. PW + random salt protects you against reused passwords. If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. (re)Captcha: fuck you. Even if it’s after the second failed attempt. Fuck you. I hate you. You are implementing security theater, making everything worse for the user, and killing your conversation rate for everyone but spammers,who have this down pat. Pushing x numbers of rules, whether or not they are special characters or not. 8 vs. 10 doesn’t matter that much. Push passphrases instead. Multi-factor is sort-of okay, but the implementations are garbage and the user experience is awful. I’m not a security expert or a researcher. I’m a data engineer with a lot of web app experience. But most of the advice in this thread is total garbage. Web apps need to find a way to make the gold-standard of authentication accessible to users: per-device public/private key pairs. Until we do that well, we suck at life and our jobs compared to native apps. I include myself when I say that we have held ourselves to an incredibly low standard. OWASP is a pathetically low bar. Yet we often fail. It’s time to step up our game, people. And it’s on us to do it.

jjnoakes 9y ago
> PW + random salt protects you against reused passwords. That only protects you if every other site does it. If you salt your passwords and some other site which doesn't is compromised, you are hosed too if your users reused passwords. > If your application is able to compare other passwords to the current password, not only did the othe site fuck up, but you did too. Sorry, don't follow. How is it a mistake to compare a password your user is entering to a known blacklist of compromised passwords?
- ianamartin 9y ago
  To your second point, giving this information leaks too much about the user trying to create a password. I go to a site and try to register an account. The app says, “sorry, you can’t use that password because it’s been used with this username before and has been compromised.” Your attacker now knows that the user is in a compromised list. You can’t do this without leaking information about the user. If you compare to a global list instead of the user, then you’ve leaked the opposite information. That at least one user is on some list of compromised passwords. You can’t do that without leaking information about at least one user. And, as discussed, exponential fall-off doesn’t work in the world of distributed attacks. That’s my response to point two in a nutshell. But I’ll add that the application layer should have no knowledge of the plain-text password to begin with. The password should be hashed on the client side before being sent to the application layer. Then salted and hashed and stored in the database. The double hashing doesn’t get you anything in crypto terms as far as I know, but it means that if your application leaks or the network between the front and back end is MITMd, then you are leaking hashes and not plain text. Of course, if the network between your front and back ends is compromised, you fucked up pretty bad anyway. But it adds at least a little effort for the attacker instead of allowing them to just grab username and password pairs in plain text. I also salt + hash usernames in transit, so it’s not immediately obvious who is associated with what. That gets me to your first point. You are correct that doing all of this doesn’t protect any individual user from illicit access, and I should have been more clear about my concerns. If an individual user chooses to reuse passwords, their account can be compromised. You are 100% correct about that. But in the case of a data breach, which is what I was thinking of in terms of “preotection”, it’s going to be really hard to compromise a collection of salted, hashed username/password combos. In my opinion—again, I’m not a security expert, and I welcome criticisms such as yours—I don’t think we’re going to get people to stop reusing passwords. And I don’t think we’re going to get people to use multi-auth any time soon. I think this is the best we can do until someone comes up with a way to get per-device key pairs to work in a friendly way. Thanks for your thoughts and criticisms and questions.

tofflos 9y ago

The article mentions home grown authentication and authorization mechanism and suggests that we stick to proven solutions. The problem is that, at least within the Java community, that library-, framework- and application server authors are not providing easy to use solutions that integrate well with applications. Instead there are a bunch of complex solutions that require manual configuration, proprietary extensions and arcane programming models for something that sits in front the application making it difficult for application authors to provide a seamless user experience. No wonder so many people are rolling their own. This is why JSR-375 was created. It needs to happen! I've tried the reference implementation and it was awesome! If you're working on the JSR or the RI then I'm rooting for you! But I don't know if anyone is working on them these days?

tim333 9y ago

It's always seemed to me that the web2py approach of providing a secure starter app with auth included and then letting developers break it if they want seems quite a sensible way to go. Not sure how well that works in other frameworks. http://www.web2py.com/book/default/chapter/01#Security http://www.web2py.com/book/default/chapter/01#Security

mmcnl 9y ago

Perhaps security isn't as easy as (often self-proclaimed) security experts think it is. Unlike them, developers don't devote 100% of their time to security. I couldn't care less about people standing on the sideline yelling at me what I can't do. How about proactively seeking out and suggesting meaningful improvements which actually help increase security? Security in big corporations often boils down to a unit of people ranting about everything and nothing, and telling people what they can't do, while in fact, they should be doing the opposite.

BrandoElFollito 9y ago

It is a shame that A10 and A7 were rejected. In our mobile held, APIs are often unprotected because authentication is hard for machine to machine transactions. OpenID and the misused oAuth are a solution but it is hard to implement. A7 addressed an organizational issue completely absent from the top 10. Since there à so much controversies, they sold have made it a top 12.