nbpoole

42 ms·

361.
by nbpoole 16y ago
Yes
362.
by nbpoole 16y ago
I just tested the extension and I can confirm that Flashblock only downloads and runs the content when the placeholder is explicitly clicked on. So, Wikipedia is wrong. ;) Edit: If I browse to an SWF directly, it does appear to load the con
363.
by nbpoole 16y ago
Are you sure about that? Because that's not the way Flashblock describes itself: Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on
364.
by nbpoole 16y ago
Github has been announcing a ton of new hires in the past couple of their days (5 since the beginning of February). See: - https://github.com/blog/ - https://github.com/blog/792-aman-gupta-tmm1-is-a-githubber - https://github.com/blog/
365.
by nbpoole 16y ago
That's the point of the fix: X-CSRF-Token requires the CSRF token, which is per-user, as its value. X-Requested-With, the old way of doing things, just had to be present in the request.
366.
by nbpoole 16y ago
Correct. Put it up using Google Adwords or a similar network, make sure attacker.com has a proper crossdomain.xml file (because the SWF won't be served from attacker.com), and you have a working exploit that can be deployed all over the Int
367.
by nbpoole 16y ago
No, but that wasn't my point. My point was that this vulnerability can be (and has been) worked around by using nonces in the header. If you can see the response body, that protection becomes worthless as well (and there is no workaround fo
368.
by nbpoole 16y ago
<embed src="http://attacker.com/evil.swf></embed> is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs t
369.
by nbpoole 16y ago
No. Let me try explaining the simplest possible version of this attack. Your bank ( http://victim.com ) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer , you can tra
370.
by nbpoole 16y ago
It's actually fairly straightforward 1. It doesn't matter where the SWF is, as long as it can make requests to a redirecting script. That's the point of the attack: you can make cross-domain requests via a redirect. 2. Victim is referring t
371.
by nbpoole 16y ago
Fortunately, the attack is limited by the fact that the attacker can't see the response from the server. If the attacker could view the response, it would break CSRF protection based on nonces as well.
372.
by nbpoole 16y ago
Except they specifically list anti-phishing as one of the use-cases: "if you reuse the same password on multiple sites and one of those sites gets hacked, or your password is conned out of you directly through a phishing scam, it can be use
373.
by nbpoole 16y ago
Devil's advocate here: If I can trick a user into submitting their username and password on my site, I can send a request to Google using that username/password and trigger a message to the mobile application. The user continues with the fl
374.
by nbpoole 16y ago
This was my most recent report as part of the Mozilla Web Security Bug Bounty ( http://www.mozilla.org/security/bug-bounty-faq-webapp.html ). It also happens to be the first one that was marked public, so I decided to publish my writeup.
375.
Directory Traversal / Local File Inclusion on addons.mozilla.org(nealpoole.com)
2 points by nbpoole 16y ago|1 comments
376.
by nbpoole 16y ago
That's right. Of course, without knowing more details about the vulnerability, it's hard to say whether there's a benefit to ending the session.
377.
by nbpoole 16y ago
Out of curiosity, why doesn't hooking beforeSend (as suggested in the blog post) work?
378.
by nbpoole 16y ago
Good password hashing is important. However, every single Django application being vulnerable to CSRF is a much bigger deal. ;-)
379.
by nbpoole 16y ago
I wouldn't call it a mistake. If you had asked me before this afternoon whether trusting X-Requested-With would protect against CSRF, I would have said yes. I still have no idea how you can send arbitrary cross-domain requests in Java and F
380.
by nbpoole 16y ago
Cross-posting the recent discussion about the new Ruby on Rails release, which included a fix for the same CSRF issue: http://news.ycombinator.com/item?id=2195283
381.
by nbpoole 16y ago
To be perfectly clear, Sam is not wrong. Flash and Java both let you issue requests with that header. However, if you try and make a cross-origin request, they'll both throw exceptions unless you have permission (in the form of a crossdomai
382.
by nbpoole 16y ago
That's not it, unless I'm missing something big. Flash and Java both disallow cross-domain requests unless specifically allowed by a crossdomain.xml file (or you use a DNS rebinding attack on Java). Furthermore, to the best of my knowledge,
383.
by nbpoole 16y ago
Fair enough. I guess I'll just have to work it out for myself. :P
384.
by nbpoole 16y ago
...and Reddit is currently down (well, in emergency read-only mode). :(
385.
by nbpoole 16y ago
http://code.djangoproject.com/changeset/15464/django/trunk/d... Django released a similar fix. According to their changeset, we'll see a release from them shortly as well. Maybe they'll shed some more light on the issue.
386.
by nbpoole 16y ago
Same here. Based on the changes made in the patch, it seems like the attack involves being able to make cross-domain requests but not being able to read back the response. I didn't think that was the way Java and Flash behaved.
387.
by nbpoole 16y ago
This was posted on Twitter earlier today (~4 hours ago): http://twitter.com/#!/EFF/status/34679524058861568 Tell your Representative to reject the #PATRIOTAct sneak attack before tomorrow's vote! https://eff.org/r.x8P
388.
by nbpoole 16y ago
I'd be curious how many vulnerabilities he found that followed those three patterns. $13k is actually a lot to earn from the program (the average payout I've received per accepted vulnerability is ~$666). Regardless, those are some very nic
389.
by nbpoole 16y ago
My mistake: for some reason I thought it had been around for a little bit longer than that.
390.
by nbpoole 16y ago
http://twitter.com/about/security has been on their website for a little while now, but it's not so easy to find via Google (at least for me).

More ›