[Owasp-leaders] HTML Security Annotations

Kevin W. Wall kevin.w.wall at gmail.com
Wed Jan 4 18:12:19 UTC 2017

Overall, I am supportive of developers adding hints to tools that something
*should* be in place, like a anti-CRSF token, an HSTS or CSP header should
be used here, etc. Not as mich for something not being needed.

Maybe I am missing something here, but I am very uncomfortable in having
developers indicate that some tool should blindly accept that they know
better and not flag (say) a CSRF vulnerability because they have marked a
form "data-no-csrf". This is like saying "Trust me, I know what I'm doing".
They may, but they may not, so if ZAP or some other tool decides that a
security analyst doesn't really need to see an potential issue because some
developer says "move along, move along; nothing to see here", to me that is
tantamount to putting the fox in charge of guarding the henhouse. I can see
the value of when devs are running SAST or DAST tools against their own
code, but not when an independent security analyst is doing this
validation. Then I want to see everything.

Blog: http://off-the-wall-security.blogspot.com/.   | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

On Jan 4, 2017 12:25 PM, "Dinis Cruz" <dinis.cruz at owasp.org> wrote:

> Thinking about this a bit more, isn't what we saying this: *"Form is
> vulnerable to CSRF which is an accepted risk (**so tools please don't
> report this finding)**" *
> Of course that this needs to be followed up internally and the awareness
> of this issue must be known (and risk accepted). Ideally, there should be
> (passing tests) that prove the exploitability and confirm it's non-impact
> status (ZAP could be used for this)
> This is very powerful since it allows the tools to become much more clever
> and to react to information provided by the app.
> Note the we can also use this annotations the other *"Form should be
> protected to CRSF" , "CSP should be in place", "HSTS header should exist",
> "Server side validation should match client side validation", "this field
> is a asset (credit card)", "this field should not be an predictable direct
> object reference" etc...*
> Some of these mappings could also be provided via source code analysis or
> mappings (exposed to the tools)
> What is very important for this to work is the speed of CI loop (so that a
> code change, lets to very quick tool results)
> Dinis
> On 4 January 2017 at 15:50, psiinon <psiinon at gmail.com> wrote:
>> Replying inline to Dave's comments to me and Dinis publicly with his
>> blessing ;)
>> On Wed, Jan 4, 2017 at 2:46 PM, Dave Wichers <dave.wichers at owasp.org>
>> wrote:
>>> Simon,
>>> I like these ideas but I've had resistance to code annotations that are
>>> tool specific. i.e., to them they just clutter the code unnecessary.
>>> (e.g., SonarQube specific ignore warnings notations).
>> I'm hoping these can be cross tool, but no idea if that will actually
>> happen ;)
>> For info Ferruh Mavituna (Netsparker CEO) has replied to my tweet and
>> seems broadly supportive;) https://twitter.com/fmavituna/
>> status/816669797811441664
>>> However, for your example does it do both of these things? Or just the
>>> first:
>>> 1) It tells the auditor CSRF isn't necessary. (As you've said)
>>> 2) Does it actually tell some control to NOT enforce CSRF on this form?
>>> i.e., without this annotation, it WOULD be protected from CSRF?
>>> If it does #2 then its not just a 'note' its actually part of the
>>> configuration and as such they of course can't complain about using it. I
>>> suspect it doesn't do #2. Assuming that is correct is there any way to
>>> correlate these annotations with the configuration to make sure there
>>> aren't any mismatches? I.e., no-CSRF note in HTML when its actually ON, or
>>> vice versa?
>> I envisioned it as a note rather than something that _had_ to be acted
>> upon (ie #1)
>> If an auditor (or tool) found a form with this annotation _and_ an anti
>> CSRF token then I think they should flag that as a real problem. I'll
>> certainly do that in ZAP:)
>> In order to prevent CSRF tokens from having any affect if the annotation
>> was supplied then we'd have to change every application/framework that
>> implemented CSRF tokens. I dont see that happening;)
>> Cheers,
>> Simon
>>> -Dave
>>> On Wed, Jan 4, 2017 at 9:15 AM, psiinon <psiinon at gmail.com> wrote:
>>>> OK, so I did initially call it data-security=”no-csrf” :)
>>>> I'm happy to go with the consensus...
>>>> On Wed, Jan 4, 2017 at 2:12 PM, Dinis Cruz <dinis.cruz at owasp.org>
>>>> wrote:
>>>>> This is a brilliant idea, but I would make it a name-value pair
>>>>> (easier to parse and more future proof)
>>>>> On 4 Jan 2017 1:56 p.m., "psiinon" <psiinon at gmail.com> wrote:
>>>>> Leaders,
>>>>> All security tools suffer from false positives (FP’s), and good tools
>>>>> allow these FPs to be flagged in the tool. SAST tools also typically allow
>>>>> the source code to be annotated to prevent FPs from being flagged, eg the
>>>>> @SuppressWarnings annotation in Java.
>>>>> I've discussed this with Mozilla web developers and we have decided to
>>>>> start using what I've dubbed 'HTML security annotations'.
>>>>> The first one we will be using is to allow forms to be flagged as not
>>>>> requiring (anti) CSRF tokens, eg
>>>>> <form action="/my-handling-form-page" method="post" data-no-csrf>
>>>>>     <div>
>>>>>         <label for="search">Search:</label>
>>>>>         <input type="text" id=”search" />
>>>>>     </div>
>>>>> </form>
>>>>> The 'data-no-csrf' attribute is an indication that the developers know
>>>>> all about CSRF tokens and have decided that this form doesnt require one.
>>>>> Security tools _can_ choose to not flag such forms as being insecure
>>>>> because they dont have a CSRF token. They can also make it easier for their
>>>>> users to find all forms that so have such tokens:)
>>>>> Theres no guarantee that the developers are right, so a sensible
>>>>> pentester would not place too much faith in this attributes use.
>>>>> However its an easy and effective way to reduce FPs in DAST tools and
>>>>> also an easy way to indicate to bug bounty participants that they should
>>>>> only report these forms if they are _really_ sure they can be usefully
>>>>> exploited.
>>>>> There are other alternative solutions to this particular problem,
>>>>> including:
>>>>>    1. Adding CSRF tokens to all forms whether they need it or not.
>>>>>    That feels nasty to me and I'm not going to suggest it to our devs ;)
>>>>>    2. Having tool specific configurations for flagging FPs. Many
>>>>>    tools support this but personally I like the annotation approach that can
>>>>>    be adopted by all tools
>>>>> So thats the first one we're trying out, and I can see the potential
>>>>> for more of them.
>>>>> What do you think?
>>>>> If everyone else hates this idea then we can keep as Mozilla specific.
>>>>> However if there is broad support for this them maybe it could be mentioned
>>>>> on the relevant pages of the OWASP wiki.
>>>>> In any case I'll be adding the option to ignore forms flagged in this
>>>>> way to ZAP ;)
>>>>> All constructive feedback appreciated, including suggestions for other
>>>>> annotations that could be useful.
>>>>> Cheers,
>>>>> Simon
>>>>> --
>>>>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>>>>> _______________________________________________
>>>>> OWASP-Leaders mailing list
>>>>> OWASP-Leaders at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>> --
>>>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> --
>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170104/f8d313e7/attachment.html>

More information about the OWASP-Leaders mailing list