[Owasp-topten] Comments on OWASP Top 10 - 2017 RC 1 (with a rewording proposal for A7)

Dave Wichers dave.wichers at owasp.org
Wed Apr 12 19:09:30 UTC 2017

Thanks Christian for your thoughtful response. We clearly need to clarify
A7 in both what it covers and how you might address it, without dictating a
particular solution or even set of solutions. I believe WAFs are one of
many technologies organizations should consider when working to address A7,
which is why it is already mentioned. But its not the only solution. In
fact, I think you need a set of technologies (both off-the-shelf and
custom) to address A7, not just one. This is clearly a 'hot' topic in the
new Top 10 and I believe we can work together effectively to clarify its
intent without mandating or even strongly recommending any particular

Thanks for your suggestion.


On Wed, Apr 12, 2017 at 1:56 PM, Christian Folini <
christian.folini at netnea.com> wrote:

> Hi there,
> It is only the recent release of the draft Top 10 document that brought
> me to this list, so apologies if I am re-iterating arguments that have
> been heard before.
> I have read the new version and especially the new A7 very carefully and
> I think it is very well written. Finding a good title for this
> heterogeneous category is hard and the proposed title sounds unfamiliar,
> but I guess that's a characteristic of new terms.
> If you read through A7 you start the understand that it encompasses
> a lot that goes unnoticed in many web applications: They are constantly
> under attack, but they do not even notice. So they are not protecting
> themselves. Hence the attack protection is insufficient. I like the
> way this is described and worded. Good job.
> But then maybe I am a bit biased: I am the author of the 2nd edition of
> the ModSecurity Handbook and I am a member of the OWASP ModSecurity Core
> Rule Set team.
> (Here are two recent articles covering ModSec and CRS if you are not
> familiar with the two open source projects:
> https://lwn.net/Articles/708673/ https://lwn.net/Articles/709693/
> ModSecurity is the most widespread open source WAF and the Core Rule
> Set is the WAF rule set with the biggest user base on the internet)
> I guess you see where this is going now. ;)
> The first two paragraphs under "Am I vulnerable to Attack?" describe the
> situation I see all the time: People are not effective at fixing their
> applications. If fixing the application would work, then we should see
> some simple mistakes disappear. Yet it is 2017 and I still explain
> developers that they should put a secure flag on their session cookie.
> When you have attended 2-3 meetings talking about secure flags on
> cookies, you lose all illusions about the ability of most organisations
> to fix vulnerabilities in the code.
> What we usually advocate is a layered approach to security. Let me give
> you an example. I landed in SFO airport the day of the muslim ban.  The
> officers were overwhelmed and we waited three hours in the queue to pass
> the customs. Jetlag was really wearing me down and I remember a moment
> when I thought I could cross one single rope and that it would be very
> unlikely that one of the officers would notice me slipping past the
> queue and his cubicle.  When it was finally my turn the officer left a
> handwritten mark on my form and let me go. I thought this was it, but in
> fact I had to pass a huge empty hall with a single person waiting at the
> end checking that handwritten mark. That is layered security.  That 2nd
> layer of security was not very sophisticated, but it effectively killed
> the possibility of sneaking past the main officer.
> And this is exactly what you can achieve with a decent WAF, with RASP
> or OWASP App sensor. It's an additional layer of security that if done
> right brings a high ROI. (If done wrong it costs a lot of money and
> brings only a false sense of security, though. As do bad developers
> that promise to "pay attention to OWASP Top 10".)
> Now doing it right is admittedly hard in case of a WAF. When I joined
> the Core Rule Set project in early 2016, we knew we had to work on the
> false positives that killed every default install unless there was an
> expert performing the tuning, With the 3.0 release last November
> we eliminated over 95% of false positives in the default installation
> and we no longer try to brand our rule set as the silver bullet to
> anything security. Instead we call it the "1st Line of Defense":
> It is supposed to take out all the simple stuff with a minimal
> investment of resources in the default installation. And I think
> it achieves this (come and see my CRS3 talk at AppSecEU and I will
> bring some proof.)
> Still, I see that A7 - namely the final paragraph in the "Am I
> vulnerable to Attack" section - may come across as an endorsement of an
> industry with a bad reputation. Maybe it could be rearranged, reworded
> and bent a bit to provoque less fundamental opposition.
> Furthermore, I think the first two sentences from that paragraph are a
> bit hard to interpret and I miss the term threat model that is used in
> A10 and again on page 19 in a small section of its own. So how about
> this as a replacement for the third paragraph:
> "Make sure your protection against standard attacks matches your threat
> model. If you are not able to provide sufficient attack protection
> within your application software, then technologies like RASP, the
> OWASP AppSensor project or a WAF with a ruleset as the OWASP ModSecurity
> Core Rule Set can fill the need to detect, block and/or virtually patch
> vulnerabilities."
> Cheers,
> Christian Folini / @ChrFolini
> --
> https://www.feistyduck.com/training/modsecurity-training-course
> mailto:christian.folini at netnea.com
> twitter: @ChrFolini
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170412/7793a947/attachment.html>

More information about the Owasp-topten mailing list