[Owasp-leaders] HTML Security Annotations

psiinon psiinon at gmail.com
Wed Jan 4 15:50:49 UTC 2017


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


More information about the OWASP-Leaders mailing list