Y
Yan Zhu
zyan.scripts.mit.edu · Personal blog · on HN since 2013
Yan Zhu, a security researcher, writes about browser privacy, fingerprinting, history sniffing, and web security attacks.
What HN saysHN links it for browser history leaks such as the Sniffly HSTS timing attack and for her response to a Cypherpunks 2.0 talk.
22HN people shared it
11linked it in comments
14stories submitted
920story points
10 years agolast shared
2013people per year2026
Most-shared posts
- 1Backdooring JavaScript using minifier bugs5 people · 211 points · first shared 2015 · 36 comments on HN
- 2Timing attack against HSTS to sniff browser history in Chrome and Firefox4 people · 257 points · first shared 2015 · 94 comments on HN
- 3New Tricks for Browser Fingerprinting [pdf]4 people · 82 points · first shared 2015 · 10 comments on HN
- 4Lessons from the ad blocker trenches3 people · 4 points · first shared 2015 · discussion on HN
- 5Thoughts on Cypherpunks 2.02 people · 2 points · first shared 2013 · discussion on HN
- 6Sniffly2 people · first shared 2015
- 7Visiting Chelsea Manning in prison1 people · 344 points · first shared 2016 · 171 comments on HN
- 8RSA conference site sends an ajax request per keystroke when entering password1 people · 11 points · first shared 2014 · 1 comments on HN
- 9A boring xss dissection1 people · 4 points · first shared 2014 · discussion on HN
- 10Happy Birthday Chelsea1 people · 2 points · first shared 2015 · discussion on HN
- 11Certificate Transparency for PGP?1 people · 2 points · first shared 2014 · discussion on HN
- 12Tips on Heartbleed recovery (other than "Change your password")1 people · 1 points · first shared 2014 · discussion on HN
- 13Index.js1 people · first shared 2015
What HN people wrote when they linked it
bcrypt · 2015-10-27
In addition to Egor's stuff, I'd recommend just reading the "Privacy and Security Considerations" sections of various RFC's and W3C specs. Lots of theoretical attacks in there that people simply haven't built demos for!
In case anyone's interested, slides are up at https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf and talk recording at https://www.youtube.com/watch?v=kk2GkZv6Wjs
unhush · 2013-10-13
I went to this talk last night and wrote a blog post in response to it: http://zyan.scripts.mit.edu/blog/thoughts-on-cypherpunks-2-0/
The gist of it is that although the Cypherpunks 2.0 movement is doing fantastic pro-privacy work, it will eventually be constrained by the apathy of the average person who uses technology (aka, surveillance victim). I don't know how we can fight this, but we should try.
pbhjpbhj · 2017-02-24
Do browsers still leak history info (eg http://zyan.scripts.mit.edu/sniffly/) is it possible to have a page show visitors if they are likely to be affected?
cpeterso · 2016-04-06
There are a number of ways (some patched) for sites to guess at your browsing history, such as the color of visited links or HSTS cache timing.
https://zyan.scripts.mit.edu/blog/sniffly/
bigethan · 2015-11-03
Sorry to TL;DR but 50 page PDFs can be opaque for discussion.
The presentation takes a while to get around to it, but it's a way to see your browser history using cert pinning/redirection. Specifically (ab)using features in the browser that even the paranoid don't disable. And then using that information to fingerprint you.
Demo: http://zyan.scripts.mit.edu/sniffly
Code: https://github.com/diracdeltas/sniffly
It's a good find, even if it's not perfect the way the CSS link visited computed style checks was.
tux · 2015-10-28
More Related Resources:
GitHub: https://github.com/diracdeltas/sniffly
Sniffly: http://zyan.scripts.mit.edu/sniffly/
Blog Post: https://zyan.scripts.mit.edu/blog/sniffly/
lifthrasiir · 2015-10-27
A slide discussing HSTS+CSP attack (this one) and also HPKP attack: https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf
jimminy · 2015-08-31
All of the interesting content is in the link provided in the list[1], and otherwise this is just a post about how debian should handle the security issues presented there.
This might be a good candidate for having the link updated.
[1]: https://zyan.scripts.mit.edu/blog/backdooring-js/
lukeschlather · 2015-08-31
No, you want the minified source to do something different but predictable so that nobody reading the source could spot the backdoor without knowledge of the bug. Here's an example:
https://zyan.scripts.mit.edu/blog/backdooring-js/
AgentME · 2015-08-31
That defends you from a different type of attack. That can't fix bugs in your compiler or minifier. See https://zyan.scripts.mit.edu/blog/backdooring-js/
TheLoneWolfling · 2015-08-31
Read the linked article: https://zyan.scripts.mit.edu/blog/backdooring-js/
It has the answer to your question. Namely, you can write bugs that are exploitable that aren't present in the original source, that only appear in the minified output. Which means that a) it is a whole lot harder for someone to find (especially if it's something that is "obviously" correct), and b) it's plausibly deniable.