[Owasp-leaders] HTML Security Annotations

psiinon psiinon at gmail.com
Wed Jan 4 14:15:35 UTC 2017

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

More information about the OWASP-Leaders mailing list