Launch HN: Templarbit (YC S17) – Protect Your Web Apps from XSS Attacks
64 points
0 comments
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 :)
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.
Offtopic - wow, so the links in submission text are clickable now, or is it a special kind of submission?
> 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.)
Are you in the same space as Tcell.io? I think they have been doing this for a few years now.
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
I don't want to play with my API headers, if you can verify with TXT record on my domain, that would be great.
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.
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
What does your service cost?
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.
looking for this for months. can't wait to test it.
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.