from Hacker News

Launch HN: Templarbit (YC S17) – Protect Your Web Apps from XSS Attacks

by zinssmeister on 7/24/17, 4:47 PM with 34 comments

Hi everyone! I am Bjoern from Templarbit (https://www.templarbit.com). 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.

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.

  • by thephyber on 7/24/17, 7:58 PM

    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.

  • by ajpikul on 7/24/17, 4:58 PM

    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.

  • by tomkinson on 7/25/17, 3:49 AM

    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.

  • by whichdan on 7/24/17, 5:49 PM

    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 :)

  • by Alex3917 on 7/24/17, 6:00 PM

    > 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.)

  • by Scirra_Tom on 7/24/17, 5:53 PM

    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.

  • by CiPHPerCoder on 7/24/17, 6:52 PM

    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

  • by manglav on 7/24/17, 6:07 PM

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

  • by geedzmo on 7/24/17, 8:42 PM

    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

  • by TeMPOraL on 7/24/17, 5:55 PM

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

  • by buremba on 7/24/17, 7:02 PM

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

  • by dawie on 7/24/17, 9:47 PM

    What does your service cost?

  • by german_http on 7/25/17, 8:07 AM

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