ptoomey3

11 ms·

61.
by ptoomey3 10y ago
Yes, the attack assumes a content injection bug in GitHub.com. The attack is not using our own gravatar URL generation against us; it is the attacker crafting an arbitrary URL and using that URL inside of an arbitrary image tag. The reason
62.
by ptoomey3 10y ago
Funny enough, I tried doing exactly that when I submitted the post to HN this morning: https://news.ycombinator.com/item?id=13437920 . But, unfortunately, my submission wasn't the one to make the front page .
63.
by ptoomey3 10y ago
Apologies for that not being clear. Given I had linked to the original article in the first sentence, I took the perspective of people knowing which "CSP" I was talking about. I'll update the post in the morning to spell&#x2F
64.
GitHub's post-content-security-policy journey(githubengineering.com)
23 points by ptoomey3 10y ago|0 comments
65.
by ptoomey3 10y ago
Agreed. The choice isn't between SMS and TOTP for most users. The choice is between SMS and just a 6 character reused password (maybe an old pet name with an exclamation point on the end for extra security ;-)).
66.
by ptoomey3 10y ago
Unless we are talking about something terribly dire (arbitrary code execution) browser vendors are super unlikely to change behavior that has existed, and potentially relied upon, for many years. The bar for changing existing behavior is ex
67.
by ptoomey3 10y ago
This game off whack-a-mole feels different. Unlike the typical "memory corruption of the week", this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites. And, this kind of fix
68.
by ptoomey3 10y ago
Another benefit of implementing it in CSP is that you could retroactively fix existing sites without having to go back and fix up potentially thousands of links that didn't set the attribute mentioned in this article.
69.
by ptoomey3 10y ago
Sure...but that is another thing that needs to be added to all browsers; it begins to feel like a game of whack-a-mole. In the end, browsers rely on an admittedly fragile premise...the only thing that guarantees your current location is a p
70.
by ptoomey3 10y ago
I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080 . In short, the solution here only closes one of potentially many other similar attacks: http://lcamtuf.coredump.cx/sw
71.
by ptoomey3 10y ago
I get that linking from a "trusted site" to a "not trusted site" is probably of greater concern. But, this `noopener` does nothing to address a similar attack demonstrated here: http://lcamtuf.coredump.cx&#x2F
72.
by ptoomey3 11y ago
I don't disagree. There was some discussion on the W3C mailing list about the idea of a resource file (something analogous to how we have CSS and JavaScript resources). I proposed a means of composing static policies with dynamic overr
73.
by ptoomey3 11y ago
We set a CSP policy via meta-tag on our static error pages as belt and suspenders protection: (view source on https://github.com/500.html ). Setting this policy does two things. First, it ensures we have a policy set in case
74.
GitHub's Content Security Policy journey(githubengineering.com)
165 points by ptoomey3 11y ago|23 comments
75.
by ptoomey3 11y ago
Nor might a consumer expect escaped outputs. Using my iOS example, the consumer would end up with malformed data and be required to manually unescape every API response. Assuming all data should be escaped is a very HTML centric view, and o
76.
by ptoomey3 11y ago
Unless the API deals exclusively with returning HTML I'd vote it is the consumer's responsibility. It is impossible for the API producer to know in what context the consumer intends to use it. For example, what if the API consume
77.
by ptoomey3 11y ago
When we first deployed our policy there was no support for reporting in browsers. I think that Firefox still lacks support and chrome only added support recently (I'd have to double check, or I'm sure Scott knows).
78.
by ptoomey3 11y ago
Yeah, we deployed this short max-age just to be safe on the initial deployment. I have a pull request open right now to switch our backup CA and add the intermediate certificate pins (to avoid possible future cross-signing issues) before we
79.
by ptoomey3 13y ago
I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the problem feels a bit more grey. In the particular scenario I propo
80.
by ptoomey3 13y ago
I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down. But, that said, I have seen the following problem several times, and it seems like client-side crypto
81.
Keychain Dumper updated for iOS 5 - audit encrypted content on iOS devices (labs.neohapsis.com)
2 points by ptoomey3 15y ago|0 comments
82.
by ptoomey3 17y ago
Not to mention, the article mentions using HMAC for his password databases. I am not sure how this is any better than salting. His argument against salting was that the salt is going to be stored somewhere. Well, the key he is going to u
83.
Zip/Tar directory traversal in Python, Java, Ruby, .Net(labs.neohapsis.com)
1 points by ptoomey3 18y ago|0 comments
84.
Hulu "encryption" explained(labs.neohapsis.com)
1 points by ptoomey3 18y ago|0 comments