<div dir="ltr"><div><div><div><div><div>Kevin,<br><br></div>Thats why tools like ZAP should (and will in ZAPs case;) have the option to show you everything.<br></div>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.<br></div>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 :)<br></div><div>Right now I have applications failing our <a href="https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan">baseline</a> scan because of missing CSRF tokens that really arent necessary.<br></div><div>You wont be forced to believe these annotations ;)<br></div><div><br></div>Cheers,<br><br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 6:12 PM, Kevin W. Wall <span dir="ltr"><<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.<br><br><div data-smartmail="gmail_signature" dir="auto">-kevin<br>--<br>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.<wbr>blogspot.com/</a>.   | Twitter: @KevinWWall<br>NSA: All your crypto bit are belong to us.</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Jan 4, 2017 12:25 PM, "Dinis Cruz" <<a href="mailto:dinis.cruz@owasp.org" target="_blank">dinis.cruz@owasp.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thinking about this a bit more, isn't what we saying this: <b style="font-style:italic">"Form is vulnerable to CSRF which is an accepted risk (</b><i>so tools please don't report this finding)</i><b style="font-style:italic">" </b><div><b><i><br></i></b></div><div>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)</div><div><b><i><br></i></b></div><div>This is very powerful since it allows the tools to become much more clever and to react to information provided by the app.</div><div><br></div><div>Note the we can also use this annotations the other <i><b>"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" </b>etc...</i></div><div><i><br></i></div><div>Some of these mappings could also be provided via source code analysis or mappings (exposed to the tools)</div><div><br></div><div>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)</div><div><i><br></i></div><div>Dinis<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 January 2017 at 15:50, psiinon <span dir="ltr"><<a href="mailto:psiinon@gmail.com" target="_blank">psiinon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Replying inline to Dave's comments to me and Dinis publicly with his blessing ;)<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Jan 4, 2017 at 2:46 PM, Dave Wichers <span dir="ltr"><<a href="mailto:dave.wichers@owasp.org" target="_blank">dave.wichers@owasp.org</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Simon,<br><br></div>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).<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>I'm hoping these can be cross tool, but no idea if that will actually happen ;)<br><br></div><div>For info Ferruh Mavituna (Netsparker CEO) has replied to my tweet and seems broadly supportive;) <a href="https://twitter.com/fmavituna/status/816669797811441664" target="_blank">https://twitter.com/fmavituna/<wbr>status/816669797811441664</a><br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><br></div>However, for your example does it do both of these things? Or just the first:<br></div>1) It tells the auditor CSRF isn't necessary. (As you've said)<br></div>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?<br><br></div>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?<span class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div></span><div>I envisioned it as a note rather than something that _had_ to be acted upon (ie #1)<br></div><div></div><div>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:)<br></div><div>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;)<br><br></div><div>Cheers,<br><br></div><div>Simon<br></div><div><div class="m_-669201615417116466m_-1082979838873932084h5"><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-HOEnZb"><font color="#888888">-Dave<br><br></font></span></div><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-HOEnZb"><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 9:15 AM, psiinon <span dir="ltr"><<a href="mailto:psiinon@gmail.com" target="_blank">psiinon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>OK, so I did initially call it <span style="font-size:14.6667px;font-family:arial;color:rgb(255,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline" id="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248gmail-docs-internal-guid-8ceb22df-69d4-5abe-d68b-7b4242b8e52a">data-security=”no-csrf”</span> :)<br></div>I'm happy to go with the consensus...<br></div><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962HOEnZb"><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 2:12 PM, Dinis Cruz <span dir="ltr"><<a href="mailto:dinis.cruz@owasp.org" target="_blank">dinis.cruz@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">This is a brilliant idea, but I would make it a name-value pair (easier to parse and more future proof)</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248h5">On 4 Jan 2017 1:56 p.m., "psiinon" <<a href="mailto:psiinon@gmail.com" target="_blank">psiinon@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248m_-7180760410091811078quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248h5"><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><div></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<font color="#888888"><br></font></div><font color="#888888"><div>-- <br><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248m_-7180760410091811078m_-1756872739451158445gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a> Project leader<br></div>
</div></font></div></div></div></div></div></div></div></div></div></div></div>
<br></div></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" rel="noreferrer" target="_blank">https://lists.owasp.org/mailma<wbr>n/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail-m_-8232451982868673962m_-4172300883036057248gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a> Project leader<br></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>
</div></div></blockquote></div></div></div><div><div class="m_-669201615417116466m_-1082979838873932084h5"><br><br clear="all"><br>-- <br><div class="m_-669201615417116466m_-1082979838873932084m_3209911440936048210gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a> Project leader<br></div>
</div></div></div></div>
</blockquote></div><br></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></div>
</div></div></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>