<div dir="ltr"><div><div><div><div>I agree that annotations could become out of date.<br></div>However I think that in this case they just show more value - they are essentially documented assumptions which you can easily search for.<br></div><br></div>The whole idea of proposing them to OWASP was to standardize them.<br></div>Otherwise I'd have just created a custom ZAP add-on and used that internally within Mozilla :)<br><br><div><div><div><div><div>So based on the feedback so far it looks like there is some level of support for them.<br></div>I think its time to take it off the leaders list - whats the best forum for exploring this in more detail?<br></div>Is it a new OWASP project, a wiki page, a github repo, a mailing group or ??<br><br></div>I'd be happy to co-lead a new OWASP project - would anyone else be interested in co-leading it with me?<br></div><div>But
 if people think thats too heavy weight we could just document the 
proposals on the wiki and pilot it in Mozilla with ZAP...<br></div><div><br></div>Cheers,<br><br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 3:02 AM, Steve Springett <span dir="ltr"><<a href="mailto:Steve.Springett@owasp.org" target="_blank">Steve.Springett@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I like the idea of HTML security annotations, however, one of the reasons why I’m in this field is the dynamic nature of it. What is safe today, may not be safe tomorrow. Reflected XSS was a thing, then persisted XSS, then just when we thought we knew it all, along came DOM XSS. Tomorrow it could be something else, and what we deem as safe today, may not be true tomorrow.</div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">If the behavior of HTML5 does one thing today, and behaves slightly different with an updated spec, then what benefit are the annotations? They will be outdated; correct in their analysis at the time they were introduced, but could very well become obsolete (or worse, inaccurate) within the lifetime of the application.</div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">The example was provided of @SuppressWarnings, which is good, and it’s universally supported due to being included in the Java language itself. All static analysis tools (SonarQube, FindBugs, PMD, etc) respect these. However, security-specific annotations such as @FortifyXSSValidate, are very much tool specific. So, if HTML security annotations are introduced, there should be plans on standardizing them so that they are not specific to a vendor or scanning technology.</div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">IMO, I’m less concerned about the amount of false positives, as I am about making tools smarter and more capable of finding issues that normally would require human testing. I would love to see HTML security annotations take into consideration business logic and workflow scenarios. For example, being able to annotate a site which tells ZAP (or some other tool) that you must add items to the cart before you can hack the checkout. If there was a universally accepted annotation for that, I’d be using them today.</div><span class="HOEnZb"><font color="#888888"><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">—Steve</div></font></span><div><div class="h5"><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="m_-3226549518857774520bloop_sign_1483583465431243776" class="m_-3226549518857774520bloop_sign">
</div> <br><p class="m_-3226549518857774520airmail_on">On January 4, 2017 at 5:20:44 PM, dan cornell (<a href="mailto:dan.cornell@owasp.org" target="_blank">dan.cornell@owasp.org</a>) wrote:</p> <blockquote type="cite" class="m_-3226549518857774520clean_bq"><span><div><div></div><div>





<div dir="ltr">
<div>
<div>I mentioned this on the Twitter discussion but wanted to echo
here:<br>
<br>
Annotations like this would be a good option for security-savvy
developers to mark up their code/HTML to get by checks like you
would find in a CI/CD pipeline. Full assessments and penetration
tests will likely want to ignore these annotations (or use them for
targeting like they would a robots.txt file) But - especially in
situations where you might have application security testing
breaking a CI/CD build - it should be possible for developers to
communicate to the testing system that a finding is a false
positive so that they can keep the build moving without
intervention from the security team.<br>
<br></div>
<div>This would only work for situations where a representative
from the development team has the security savvy to make this call
- and where you trust the developer to use the annotations where
appropriate and not just to bypass checks. BUT - for teams at that
level of maturity this could be an effective mechanism.<br></div>
<div><br></div>
Thanks,<br>
<br></div>
Dan<br>
<br></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 4, 2017 at 4:26 PM, Bjoern
Kimminich <span dir="ltr"><<a href="mailto:bjoern.kimminich@owasp.org" target="_blank">bjoern.kimminich@owasp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi Simon,<br>
<br>
I like this idea. To make the life of the tools-people easier, a
fixed unique prefix would be good, so they can basically ignore
all,<br>
<br>
data-nosec-*<br>
or<br>
data-ignoresec-*<br>
<br>
And if "*" would share a set of terms for vulns with the
__vulns.json idea for scanner result assessment on intentionally
vulnerable apps (1st draft see VWAD repo), that would be even more
consistent!<br>
<br>
Cheers,<br>
Bjoern
<div>
<div class="m_-3226549518857774520h5"><br>
<br>
<div class="gmail_quote">Am 4. Januar 2017 14:53:06 MEZ schrieb
psiinon <<a href="mailto:psiinon@gmail.com" target="_blank">psiinon@gmail.com</a>>:
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Leaders,<br>
<br>
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.<br>
<br></div>
I've discussed this with Mozilla web developers and we have decided
to start using what I've dubbed 'HTML security
annotations'.<br></div>
The first one we will be using is to allow forms to be flagged as
not requiring (anti) CSRF tokens, eg<br>
<br>
<div style="margin-left:40px"><span style="font-family:monospace,monospace"><form
action="/my-handling-form-page<wbr>" method="post" <span style="color:rgb(255,0,0)">data-no-csrf</span>><br>
    <div><br>
        <label
for="search">Search:</label><br>
        <input type="text"
id=”search" /><br>
    </div><br>
</form><br></span></div>
<br></div>
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.<br></div>
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:)<br></div>
Theres no guarantee that the developers are right, so a sensible
pentester would not place too much faith in this attributes
use.<br></div>
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.<br>
<br></div>
<div>There are other alternative solutions to this particular
problem, including:<br>
<ol>
<li>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
;)</li>
<li>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<br></li>
</ol>
</div>
So thats the first one we're trying out, and I can see the
potential for more of them.<br>
<br></div>
What do you think?<br>
<br></div>
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.<br></div>
In any case I'll be adding the option to ignore forms flagged in
this way to ZAP ;)<br clear="all">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br></div>
<div>All constructive feedback appreciated, including suggestions
for other annotations that could be useful.<br>
<br></div>
<div>Cheers,<br>
<br></div>
<div>Simon<br></div>
<div>--<br>
<div class="m_-3226549518857774520m_-4917689358370698391gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a>
Project leader<br></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a><br>

<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailma<wbr>n/listinfo/owasp-leaders</a><br>

<br></blockquote>
</div>
<br></div>


______________________________<wbr>_________________
<br>OWASP-Leaders mailing list
<br><a href="mailto:OWASP-Leaders@lists.owasp.org" target="_blank">OWASP-Leaders@lists.owasp.org</a>
<br><a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/<wbr>mailman/listinfo/owasp-leaders</a>
<br></div></div></span></blockquote></div></div></div>
<br>______________________________<wbr>_________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/<wbr>mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a> Project leader<br></div>
</div>