[Owasp-leaders] HTML Security Annotations
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
On Wed, Jan 4, 2017 at 2:46 PM, Dave Wichers <dave.wichers at owasp.org> wrote:
> 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
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
> 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
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;)
> 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:
>>> 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>
>>> <label for="search">Search:</label>
>>> <input type="text" id=”search" />
>>> 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
>>> There are other alternative solutions to this particular problem,
>>> 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.
>>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders