[Owasp-leaders] HTML Security Annotations

dan cornell dan.cornell at owasp.org
Wed Jan 4 23:19:10 UTC 2017


I mentioned this on the Twitter discussion but wanted to echo here:

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.

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.

Thanks,

Dan


On Wed, Jan 4, 2017 at 4:26 PM, Bjoern Kimminich <bjoern.kimminich at owasp.org
> wrote:

> Hi Simon,
>
> 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,
>
> data-nosec-*
> or
> data-ignoresec-*
>
> 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!
>
> Cheers,
> Bjoern
>
>
> Am 4. Januar 2017 14:53:06 MEZ schrieb psiinon <psiinon at gmail.com>:
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170104/b846ec28/attachment.html>


More information about the OWASP-Leaders mailing list