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

Christian Folini christian.folini at netnea.com
Wed Apr 12 17:56:29 UTC 2017

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


Christian Folini / @ChrFolini

mailto:christian.folini at netnea.com
twitter: @ChrFolini

More information about the Owasp-topten mailing list