[Owasp-leaders] HTML Security Annotations

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


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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170104/0513396a/attachment-0001.html>


More information about the OWASP-Leaders mailing list