Launch HN: Templarbit (YC S17) – Protect Your Web Apps from XSS Attacks
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.
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.
38 comments
[ 5.5 ms ] story [ 55.9 ms ] threadHow 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.
A Freemium model is something we are interested in! We wanna support smaller projects with a free tier in the future.
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 :)
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.
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.
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.)
We also provide a reporting endpoint that captures all violations. Do you currently use a CSP header with a report-uri setting?
https://github.com/paragonie/csp-builder
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.
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.