[Owasp-leaders] HTML Security Annotations
Steve.Springett at owasp.org
Thu Jan 5 03:02:13 UTC 2017
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.
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.
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.
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.
On January 4, 2017 at 5:20:44 PM, dan cornell (dan.cornell at owasp.org) wrote:
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.
On Wed, Jan 4, 2017 at 4:26 PM, Bjoern Kimminich <bjoern.kimminich at owasp.org
> 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,
> 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!
> Am 4. Januar 2017 14:53:06 MEZ schrieb psiinon <psiinon at gmail.com>:
>> 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-Leaders mailing list
OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders