
Launch HN: Templarbit (YC S17) – Protect Your Web Apps from XSS Attacks - zinssmeister
Hi everyone! I am Bjoern from Templarbit (<a href="https:&#x2F;&#x2F;www.templarbit.com" rel="nofollow">https:&#x2F;&#x2F;www.templarbit.com</a>). Me and my co-founder Matthias are part of the current YC batch and are excited to launch our product. Templarbit protects web applications from XSS attacks and other malicious activity.<p>Previously Matthias and I worked together at a cyber security firm where we saw many vulnerability reports. After spending some time running engineering at another startup we realized there is a big need for a security solution that can easily be understood and deployed. Something that helps software teams protect what they are building.
We reached out to friends and strangers at other software startups to see how they handle the security of their applications. Surprisingly to us, not many teams felt like they did a good job in that area, mostly due to lack of tools available to them.<p>With the advent of browser support for Content Security Policies, there are new ways to protect against these attacks. Setting a CSP header is a great way to mitigate XSS attacks, but managing changes to the policy and having a reporting endpoint that gives you insights into what is being violated is still difficult. Templarbit helps with this. Our reporting dashboard can help you discover and fix violations in real-time and shows you in most cases exactly where in your app the issue exists.
======
thephyber
The most dangerous part of XSS is what developers _don 't_ _know_ is possible.
There are lots of sinks and sources and the more features browsers support,
the more surface area is exposed.

Lots of developers intuitively notice reflective XSS, but fewer notice
persistent XSS and even fewer know about DOM-based XSS. Each of these has
several, even dozens, of sinks and sources to check + be aware of.

I think your offerings would be vastly more valuable if you had a CSP policy
generator that defaults to the strictest possible settings, allowing the user
to opt out / loosen some rules. Perusing your docs, you only describe a small
subset of what CSP is capable of. Your average user is short on time and will
likely copy-paste your example policies as their first implementation
iteration.

It's important to explain that _every_ page on their domain should be
protected by a CSP policy. Protecting just a subset of the domain means that
there is still vulnerable surface area.

Iframe embeds. Injected forms. Injected IMG tags. Injected meta tags. Data
URIs. SVG DOM events. LocalStorage. Cookie overflow attacks. Charset sniff
attacks. Charset attacks against specific databases. IE CSS expressions.
Image/HTML + JS Polyglots. etc.

A developer that isn't familiar with all of the possible attacks is likely to
not make the CSP as restrictive as needed. I _highly_ recommend if you are
going to tackle XSS, try and aim to provide value for _all_ XSS attacks, not
just the easiest to defend against.

Also, you should provide resources to explain why XSS is dangerous, what is
potentially at risk, how much companies pay for XSS on bug bounties, and
resources for the developer to know how to craft a successful CSP policy.
Without these, you aren't selling your value proposition.

~~~
matteska
Thank you for your feedback! More resources and education material for
developers will be coming very soon.

The default policy we provide is report-only. When we started we provided a
very strict policy, but it broke too many apps. It was a major turn down for a
lot of adopters. We are constantly evolving and are currently working on a
feature that automatically generates tailored (stricter) policies depending on
the reports we receive.

------
ajpikul
Thanks for doing this, I'm definitely going to consider it since we're
implementing token based authentication and my friends have told me XSS is
what I should be concerned about there.

How did you choose to go with a trial period instead of a freemium model like
slack?

The issue my startup has with trial periods is that it's like "you have 14
days to start generating revenue". Freemium is better for us because it's like
"You can learn about our service, and use our service while your staging your
release, and when you launch if you're viable (traffic+revenue), we'll be your
partner (ie. charge you)".

That's how slack kept us, and Salesforce lost us.

We shouldn't have to worry about paying while we're still learning how to use
your service. If I haven't on-boarded it by the time the trial runs out, I'm
going to cancel it.

Then again, I don't know your costs, so forgive me if I'm wrong.

~~~
zinssmeister
You are absolutely right, trials are difficult when there is a integration
step that might take a week. We consider the trial to start once you are fully
integrated, not when you sign up.

A Freemium model is something we are interested in! We wanna support smaller
projects with a free tier in the future.

~~~
ajpikul
Yeah, that sounds good to me. Being a bootstrapped startup, "pricing" is the
first page I go to.

~~~
zinssmeister
Yep. I do the same :)

------
tomkinson
Please add pricing. And tip; to get startup founders, don't subscribe to the
silly moniker that startup's price themselves too low. I look at the low, mid
and high end price by volume to estimate any new costs now and 6 months down
the line. Way too many overpriced services cause it's in vogue right now based
on VC's saying it is. Certainly what you are doing is interesting. Nice work.

------
whichdan
Small suggestion: your docs could use a little work. The language switching is
broken, and the history state is broken, so when you click around the docs,
you quickly end up with 20+ entries in your history.

Also, the site could definitely use more copy: how do CSPs work? How does the
app work in general? Right now the only real details are in the documentation.

Also also, what information ends up back on your servers? Is any user data
relayed through an API?

It's a very cool idea, just non-obvious at first glance what exactly it does
:)

~~~
zinssmeister
That is great feedback! Some of this was on our "immediately post-launch" todo
list. Expect us to implement everything you just mentioned over the coming
days.

------
Alex3917
> managing changes to the policy and having a reporting endpoint that gives
> you insights into what is being violated is still difficult.

Is this targeting management at companies with multiple products? As a
developer I just use Django Middleware to add this line to all our responses
and call it a day:

response['Content-Security-Policy'] = "default-src 'none'"

(Well, we still sanitize all our inputs and have the headers to block XSS
reflection, but there's still not much complexity.)

~~~
zinssmeister
Setting a CSP header can be simple but managing changes to it can get
difficult. Especially as team members add or remove services from the app
(Intercom, Google Analytics, etc.)

We also provide a reporting endpoint that captures all violations. Do you
currently use a CSP header with a report-uri setting?

~~~
Eridrus
Have you actually found much value from these reports? Most people I talk to
tell me they're full of garbage.

~~~
zinssmeister
Noise is a problem and we are in this fight to improve exactly that.

~~~
Eridrus
There is clearly noise, but is there any signal at all? I wouldn't be
surprised if there was no signal to be found.

~~~
zinssmeister
There is a lot more signal than noise, especially they way we aggregate the
security reports. CSP can be deployed in report only mode, which provides a
great way to detect how your policy has to come together.

~~~
Eridrus
I guess in my mind signal == attacks, but I guess there's also value in having
reports when your policy broke things if you don't have other methods for
detecting that, or if your integration tests disable CSP.

------
Scirra_Tom
I think Google Webmaster tools report some XSS vulnerabilities. I'm not
suggesting their detection is in any way as sophisticated as your solution -
but do you see internet search giants offering and improving this sort of
service as threat to you in the long term?

Congratulations on the launch though, don't think this product is targeted
towards us though so probably wont get a chance to try it but love the
objective.

~~~
zinssmeister
Thank you!

Google Webmaster tools has made an effort to help fight XSS vulnerabilities by
providing some educational tools to devs (among other things). It's not a
solution in the same realm as ours, for example they don't collect any
violations and show you detailed reports on where something bad happened.

I don't see Google as a threat to us at all. We actually sat down with them at
their SF office last week to work closely together on how they can quickly
provide a better Content Security Policy feature set to their cloud customers.

------
CiPHPerCoder
For PHP integration, have you considered hooking into CSP-Builder? (It's MIT
licensed, so you can just make a private fork for internal use forever, but if
you upstream your changes, I'd greatly appreciate it.)

[https://github.com/paragonie/csp-builder](https://github.com/paragonie/csp-
builder)

~~~
zinssmeister
Yes we are looking at this. We will release a more integrated solution for PHP
soon + docs.

------
manglav
Are you in the same space as Tcell.io? I think they have been doing this for a
few years now.

~~~
zinssmeister
I actually have never heard/seen Tcell.io so I can't speak to them and what
they do. Will check it out though!

------
geedzmo
Watch out you got a typo on the front page: "A central dashboard shows all
secuirty events and directs your attention to the exact part of your
application that has issues" \- security is spelled wrong

~~~
matteska
Thanks for finding this one. Just fixed it.

------
TeMPOraL
Offtopic - wow, so the links in submission text are clickable now, or is it a
special kind of submission?

~~~
dang
We did this for Launch HN and Show HN to lessen the penalty for making a text
submission. There's a quality of density, and I would even say intimacy, in
the text launches that fits well with HN.

------
buremba
I don't want to play with my API headers, if you can verify with TXT record on
my domain, that would be great.

~~~
buremba
I thought that this was related with the verification but it looks like a
feature of the browser.

~~~
matteska
No domain verification is required at this point. Content-Security-Policies
are ideally delivered through the HTTP response headers and then enforced by
the browser. We are working on making the integration as easy and smooth as
possible.

------
dawie
What does your service cost?

------
german_http
looking for this for months. can't wait to test it.

~~~
matteska
This is awesome! Let me know if I can help you getting started.

