[Owasp-leaders] HTML Security Annotations

psiinon psiinon at gmail.com
Wed Jan 4 18:58:50 UTC 2017

Well in that case people should switch to tools like ZAP that will allow
you to choose how to handle these things ;)

On Wed, Jan 4, 2017 at 6:45 PM, Kevin W. Wall <kevin.w.wall at gmail.com>

> Dinis,
> I didn't claim it doesn't have valid use cases. I do see the value here.
> But unlike ZAP, I am not sure that _all_ SAST & DAST tool vendors will
> allow you to disregard markup such as data-no-csrf and show the potential
> issues regardless.  *THAT* would be a huge mistake IMO and I had not seen
> that concern raised.
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/.   | Twitter: @KevinWWall
> NSA: All your crypto bit are belong to us.
> On Jan 4, 2017 1:26 PM, "Dinis Cruz" <dinis.cruz at owasp.org> wrote:
>> Hi Kevin, I view this annotations useful for the cases where the issue
>> either known (and marked as 'no fix'/'risk-accepted') or a true false
>> positive.
>> for example I've seen shopping cards solutions that 'by design' and 'on
>> purpose' allow CSRF to add items to the basket (they are used by 3rd party
>> integrations). In this case there are other mitigation controls and the
>> risk has been understood and accepted by the customer/client
>> Does that make sense?
>> Dinis
>> On 4 January 2017 at 18:12, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
>>> 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.
>>> -kevin
>>> --
>>> 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

OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170104/36fc5bf8/attachment-0001.html>

More information about the OWASP-Leaders mailing list