[Owasp-leaders] HTML Security Annotations

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


Thats why tools like ZAP should (and will in ZAPs case;) have the option to
show you everything.
We use ZAP in our CI/CD pipeline. We have good developers, and I'm fine
with them flagging forms as not needing CSRF tokens.
For manual testing I would explicitly look for these annotations and double
check to see if I can abuse such forms in ways the developers didnt expect
Right now I have applications failing our baseline
<https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan> scan because of
missing CSRF tokens that really arent necessary.
You wont be forced to believe these annotations ;)



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

> 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/baae4bad/attachment-0001.html>

More information about the OWASP-Leaders mailing list