K
Krzysztof Kotowicz
blog.kotowicz.net · Personal blog · on HN since 2009
Krzysztof Kotowicz, a security researcher, writes about web and browser vulnerabilities such as XSS, clickjacking, CSRF, and Chrome extension attacks.
What HN saysCommenters cite it for details on stripping the Referer header and for WebSocket security, treating it as a reference for web attack techniques.
15HN people shared it
3linked it in comments
12stories submitted
792story points
7 years agolast shared
2009people per year2026
Most-shared posts
- 1Use "Amazon 1 Button" Chrome extension to sniff all HTTPS websites2 people · 530 points · first shared 2013 · 58 comments on HN
- 2Stripping HTTP referrer for client-side CSRF2 people · 1 points · first shared 2011 · discussion on HN
- 3Chrome addons hacking: Bye Bye AdBlock filters1 people · 137 points · first shared 2012 · 55 comments on HN
- 4XSS in Gmail through Rapportive1 people · 110 points · first shared 2013 · 13 comments on HN
- 5Who's behind Facebook clickjacking scams?1 people · 5 points · first shared 2011 · 1 comments on HN
- 6Cross-domain 'content extraction' using fake captcha and iframe1 people · 3 points · first shared 2011 · discussion on HN
- 7XSS-Track: Hijacking a whole website with a single XSS vulnerability.1 people · 2 points · first shared 2010 · discussion on HN
- 85 ways to prevent clickjacking on your website (and why they suck)1 people · 1 points · first shared 2009 · discussion on HN
- 9How to upload arbitrary file contents cross-domain1 people · 1 points · first shared 2011 · discussion on HN
- 10The sad state of DOM security (or how we all ruled Mario's challenge) (2011)1 people · 1 points · first shared 2019 · discussion on HN
- 11Analysis of New Generation Facebook Worm1 people · 1 points · first shared 2010 · discussion on HN
- 12Jealous of prism use amazon 1 button.html.1 people · first shared 2015
- 13Html5 websockets security new tool for1 people · first shared 2011
What HN people wrote when they linked it
nbpoole · 2012-03-30
Except an attacker can strip a referer header: if you fail open like that, you leave yourself open to attack.
See http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-and-profit… for examples
zeroxsys · 2011-07-17
I agree, security in Web Socket must be robust/comprehensive in both ends. This post says so too: http://blog.kotowicz.net/2011/03/html5-websockets-security-new-tool-fo… Thanks!
simonster · 2015-08-22
It's not entirely clear to me from the post whether the reason for changing the add-on API is to get rid of XUL/XPCOM (which was inevitable) or to limit what extensions can do for security reasons and/or to make AMO reviews easier.
If it's really just about XUL/XPCOM, there are promises you (by which I mean Mozilla) could do to make developers happier:
1) That you'll figure out what will replace XUL/XPCOM in Firefox before you force add-on developers to make similar changes. Perhaps there's been some discussion of this at Mozilla since https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html that I'm not aware of.
2) That functionality provided by non-XPCOM-based APIs currently available to extensions will remain available, e.g. OS.File and js-ctypes.
3) That there will be some mechanism for overlays for future browser UIs, beyond simple browser buttons.
If it's about limiting what extensions can do, and not about the needs of new technology, I think a serious discussion needs to happen. There's always going to be some compromise between security and liberty, and developers would probably have understood if told that they have to write things in certain ways so that the browser itself can be more secure. But telling developers that they can't build what they want to build because Mozilla doesn't trust them to write secure code is more questionable. A bad programmer can write insecure code with any extension API. (Chrome's extension API didn't protect against…