OWASP top 10 change visualization from 2004 to now(public.flourish.studio)
public.flourish.studio
OWASP top 10 change visualization from 2004 to now
https://public.flourish.studio/visualisation/7574790/
8 comments
It says that your software is open source. What type of open source license is it and why did you pick that particular license?
There's many links to their github page [0] which is all Apache 2.0. I'm unaffiliated with Cerbos so IO can't speak for why that license.
[0] https://github.com/cerbos
[0] https://github.com/cerbos
I went to their github and saw no license mentioned at all.
Here [0] is a link to the license file on their main repo, and Here [1] is a screenshot of the link in my previous comment highlighting the license on all of the repos.
[0] - https://github.com/cerbos/cerbos/blob/main/LICENSE [1] - https://imgur.com/a/dbVHwUW
[0] - https://github.com/cerbos/cerbos/blob/main/LICENSE [1] - https://imgur.com/a/dbVHwUW
well I think the biggest problem in authorization is definitv if you need object access control and implement lists, it makes things really really tricky and there is basically no good standard for it.
resource-based rbac is hard, extremly hard and it can easily become either a mess or a performance bottleneck.
I agree with your points. We have adopted a resource-based RBAC/ABAC and a policy language in simple YAML to address some of these challenges. In terms of performance, a side car architecture with SDKs give good response times. In such simple architecture the implementation of lists is the current challenge we are addressing. However, for majority of use cases abstracting the decision making logic to a centralized service and providing a simple API that addresses the question of can this principal, do this action on this resource with a true or false answer goes a long way.
If you're interested in resource-based rbac [1] with list endpoints [2], Oso supports both! You're right, it's a tough problem, we've invested a ton of time to make this work well without needing to rearchitect your app.
(I'm cofounder/CTO at Oso).
[1]: https://docs.osohq.com/guides/rbac.html
[2]: https://docs.osohq.com/guides/data_filtering.html
(I'm cofounder/CTO at Oso).
[1]: https://docs.osohq.com/guides/rbac.html
[2]: https://docs.osohq.com/guides/data_filtering.html
OWASP Top 10 is subjective to a certain extent, because it is consensus-based. At the same time, it is very useful to most developers and pen testers (and security tool makers), in preparing a list of vulnerabilities to check for. Consider it as a starting point.
With cloud platforms rising in popularity, the top two rising to those spots is not surprising. From a cursory glance, they seem to have added more scenarios under those two as well.
With cloud platforms rising in popularity, the top two rising to those spots is not surprising. From a cursory glance, they seem to have added more scenarios under those two as well.
While access controls is now top of the list this year, a SAML integration to Flourish Studio is only available in the enterprise plan (for pricing contact them).
This is probably why access control is number 1.
SAML and MFA should be available for all plans. Secure access should not be gated just to the expensive plans.
Disclaimer: I was involved in the design of the MFA and SAML integration UX for saas pass.
This is probably why access control is number 1.
SAML and MFA should be available for all plans. Secure access should not be gated just to the expensive plans.
Disclaimer: I was involved in the design of the MFA and SAML integration UX for saas pass.
For you and anyone else in agreement, https://sso.tax/ sounds right up your alley.
Broken access control is things like direct object vulnerabilities and authorisation bypasses _as well_ as broken authentication controls.
I'm not saying you're wrong, and agree that security should never be a 'premium' product, but it's important to identify that it isn't _just_ limited to authentication.
That being said, messing with SAML/Oauth assertions is generally pretty fruitful when pentesting, and MFA is something I'd recommend in almost all public facing applications.
I'm not saying you're wrong, and agree that security should never be a 'premium' product, but it's important to identify that it isn't _just_ limited to authentication.
That being said, messing with SAML/Oauth assertions is generally pretty fruitful when pentesting, and MFA is something I'd recommend in almost all public facing applications.
Federated access control is really important for enterprise and a significant security benefit.
However i dont think that shows up as vulns. Even if you use saml you still have to implement it, and its an absolutely terrible protocol full of ways to shoot yourself in the foot and do it wrong.
However i dont think that shows up as vulns. Even if you use saml you still have to implement it, and its an absolutely terrible protocol full of ways to shoot yourself in the foot and do it wrong.
Boy do I agree with you, although I suspect SAML is a potentially huge source of support woes for the seller.
I'm not sure how useful this is as is, over the years they've bundled/unbundled terms which this doesn't capture. "(Insecure) Design" @#4 arguably applies to many of the other top 10 (but is rightfully separated because of how often it comes up?). "(Software and Data) Integrity (Failures)" @#8 includes what was called insecure de-serialization (also @#8).
For some reason XSS is missing from 2017 (should be 7), and as others noted, some categories merge (XSS is now part of injection)
(author) : Thanks for the feedback. Now corrected.
Yeah, this is neat looking, but there is nothing resembling the rigor or even simple empiricism baked into the OWASP Top 10 to enable this kind of visualization. The Top 10 is ultimately a marketing mechanism for web software security. That's not a bad thing! Web software security can use all the marketing help it can get. But, regardless of what anyone at OWASP says about this, I don't think there's much validity either to the way it buckets vulnerabilities into these categories, or the way it "prioritizes" them.
Earlier, regarding this year's Top 10:
https://news.ycombinator.com/item?id=28470955
Earlier, regarding this year's Top 10:
https://news.ycombinator.com/item?id=28470955
There are always low-hanging fruit, though.
I remember pwning php-nuke sites with SQL injection more than a decade ago. At least as far as that dumpster fire (php nuke) goes there are 2021-dated CVEs for SQL injection so clearly at least some people aren't making headway.
I wonder if anyone publishes a broad survey of CVE categories akin to tfa.
I remember pwning php-nuke sites with SQL injection more than a decade ago. At least as far as that dumpster fire (php nuke) goes there are 2021-dated CVEs for SQL injection so clearly at least some people aren't making headway.
I wonder if anyone publishes a broad survey of CVE categories akin to tfa.
Friendly reminder that this is about frequency, as opposed to severity. 'Cryptographic Failures' is everything from theoretical vulnerabilities which require millions of dollars to exploit, through to systems with no encryption whatsoever. Granted both should be fixed, but the latter is of far more real world consequence under most threat models.
My personal and current recommendation for developers is to focus on sane authorisation models - I commonly see direct-object type vulnerabilities related to cross-user/organisational access where the user is the correct role / privilege level to access a resource, but has no association with the record owner. An example of this would be a a multi-tenant web-store where an admin for the EvilCorp entity can modify products belonging to InnocentPtyLtd.
I also suspect poorly configured CORS policies might be in the top 10 in a few years time due to situations where SPA apps (who will inevitably use JWT) and traditional cookie apps are hosted using similar configs, resulting in the latter being vulnerable to CSRF-type attacks.
My personal and current recommendation for developers is to focus on sane authorisation models - I commonly see direct-object type vulnerabilities related to cross-user/organisational access where the user is the correct role / privilege level to access a resource, but has no association with the record owner. An example of this would be a a multi-tenant web-store where an admin for the EvilCorp entity can modify products belonging to InnocentPtyLtd.
I also suspect poorly configured CORS policies might be in the top 10 in a few years time due to situations where SPA apps (who will inevitably use JWT) and traditional cookie apps are hosted using similar configs, resulting in the latter being vulnerable to CSRF-type attacks.
It's not even credibly about frequency. There is no meaningful survey done across the industry of vulnerability occurrences; they just invite and solicit contributions of vulnerability data from arbitrary sources.
By and large your average developer hasn't really come a long way in writing more secure code and avoiding common decades old vulnerabilities. However what has changed is there are more people using frameworks such as angular, vue, react whereby they gain some protection those frameworks offer.
Though obviously there is still some shared responsibility and it's no panacea - but has had a noticeable impact on the ordering of the OWASP list.
Though obviously there is still some shared responsibility and it's no panacea - but has had a noticeable impact on the ordering of the OWASP list.
OTOH, the raise of ajax-based calls IMO become the main culprit for broken access or unsafe information leak.
With SSR, we only need to limit rendered information and we're fine. Now we need to limit the json (or xml if soap) response. If we need a condition based on protected data, we need to have additional, derived (computed) property for it and there isn't a standard way to do it, then make the view to condition based on that derived value.
That process is too alluring to be skipped and many choose to just breach the security and deal with them later, unless you have different team managing front and back.
With SSR, we only need to limit rendered information and we're fine. Now we need to limit the json (or xml if soap) response. If we need a condition based on protected data, we need to have additional, derived (computed) property for it and there isn't a standard way to do it, then make the view to condition based on that derived value.
That process is too alluring to be skipped and many choose to just breach the security and deal with them later, unless you have different team managing front and back.
Broken access control becoming the number one issue is no surprise. We have faced this so many times when building enterprise SaaS software and having to go through ISO certifications.
We believe re-invention of the access control wheel causes these problems at every software company because there is no good standards to start from. With Cerbos we try to address this issue in the market.
We wrote about this issue and how we can help solve it in our blog few weeks ago. https://cerbos.dev/blog/broken-access-control-is-the-1-issue...