[Owasp-leaders] HTML Security Annotations

psiinon psiinon at gmail.com
Thu Jan 5 15:47:29 UTC 2017


I've just started this gdoc for exploring the idea:
https://docs.google.com/document/d/1VQD_Feq1IsGG6mV7sEzHQnboL9t_jwyTrSymVbYyrGs/edit?usp=sharing
(and to prevent us spamming the leaders list before any project gets set
up).
Thats the read-only link - everyone who's replied to this thread _should_
have comment access, just request it if you dont have and want to add a
comment.

Cheers,

Simon


On Thu, Jan 5, 2017 at 9:20 AM, psiinon <psiinon at gmail.com> wrote:

> I agree that annotations could become out of date.
> However I think that in this case they just show more value - they are
> essentially documented assumptions which you can easily search for.
>
> The whole idea of proposing them to OWASP was to standardize them.
> Otherwise I'd have just created a custom ZAP add-on and used that
> internally within Mozilla :)
>
> So based on the feedback so far it looks like there is some level of
> support for them.
> I think its time to take it off the leaders list - whats the best forum
> for exploring this in more detail?
> Is it a new OWASP project, a wiki page, a github repo, a mailing group or
> ??
>
> I'd be happy to co-lead a new OWASP project - would anyone else be
> interested in co-leading it with me?
> But if people think thats too heavy weight we could just document the
> proposals on the wiki and pilot it in Mozilla with ZAP...
>
> Cheers,
>
> Simon
>
> On Thu, Jan 5, 2017 at 3:02 AM, Steve Springett <Steve.Springett at owasp.org
> > wrote:
>
>> 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.
>>
>> —Steve
>>
>>
>>
>> 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.
>>
>> 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
>>>
>>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>> _______________________________________________
>> 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
>



-- 
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/20170105/276a0021/attachment.html>


More information about the OWASP-Leaders mailing list