nbpoole

25 ms·

61.
by nbpoole 15y ago
You can make but CAN NOT view the result of a cross-domain request via XMLHttpRequest unless the site specifically opts in to it. Same-origin policy again.
62.
by nbpoole 15y ago
" Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly
63.
by nbpoole 15y ago
Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In ord
64.
by nbpoole 15y ago
" Am I correct in interpreting that the fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used that for it for quite a while now, and although it works well for me as a power-user
65.
by nbpoole 15y ago
X-Frame-Options (in supported browsers) prevents the result of a request from being rendered in the browser, it doesn't prevent the request itself from being made. So does X-Frame-Options actually prevent this? Is the change to your recomme
66.
by nbpoole 15y ago
http://redis.io/commands/set > Status code reply: always OK since SET can't fail. So, what kind of situation are you envisioning?
67.
by nbpoole 15y ago
To be clear, this is not a CSRF attack in the usual sense. A standard CSRF attacks involves sending state-changing requests to a website using the credentials of an unsuspecting user. This is closer in nature to an information disclosure vu
68.
by nbpoole 15y ago
That update had already been released when I made my original comment (hence why I said "a customer service interface was compromised via stolen credentials"). It doesn't reveal how the credentials were compromised, nor how the attacker man
69.
by nbpoole 15y ago
So, a customer service interface was compromised via stolen credentials and used to access various Linode instances. A couple questions that immediately come to mind: 1. Can this interface be accessed from anywhere on the Internet? If so, w
70.
by nbpoole 15y ago
Previous discussion of Screenleap: https://news.ycombinator.com/item?id=3539792
71.
by nbpoole 15y ago
Content-type for JSON is application/json For JSONP, you might consider application/javascript ( http://stackoverflow.com/questions/111302/best-content-type-... )
72.
by nbpoole 15y ago
Not quite. Your rate limiting seems to be cookie based, which makes it easy for someone to circumvent just by replaying their initial request (or by deleting the cookie you set).
73.
by nbpoole 15y ago
I've participated in the program as well (and I'm going to be interning with Facebook's Security team this summer). This incident doesn't worry me personally and I hope it doesn't worry anybody else. But if you want clarity, I think arice's
74.
by nbpoole 15y ago
The title of this submission is completely inaccurate: the person in question is in no way a "white hat": http://www.guardian.co.uk/technology/2011/aug/17/facebook-ha... > Between 17 April and 9 May he is accused of downloading a com
75.
by nbpoole 15y ago
It's actually not so clear-cut. The solution of presenting resources within the head of the page only works if those resources are supposed to be loaded as a result of visiting the page. That's not true of robots.txt (in fact, you want a
76.
by nbpoole 15y ago
So, the components at play here: 1. Users are assigned a session cookie when they land on a PHP page. A CSRF token is associated with a session when users visit the login page. 2. Favicon requests were going to PHP instead of a static resou
77.
by nbpoole 15y ago
It happened almost a year ago! http://news.ycombinator.com/item?id=2398095
78.
by nbpoole 15y ago
https://github.com/facebook/hiphop-php/wiki/Running-HipHop It's how HPHP works.
79.
by nbpoole 15y ago
Just sent
80.
by nbpoole 15y ago
How do I report a security vulnerability to you guys?
81.
by nbpoole 15y ago
http://goo.gl/vulnz if you'd like a web form to submit it to. Otherwise, security@google.com works just fine.
82.
by nbpoole 15y ago
Done ;-) https://github.com/twilio/hurl/pull/9
83.
by nbpoole 15y ago
I assume it's a card issued by Secunia's program: http://secunia.com/community/research/svcrp
84.
by nbpoole 15y ago
Indeed. It's a Chase Visa card :)
85.
by nbpoole 15y ago
The card is a Chase Paymentcard ( https://www.mychasepaymentcard.com/ ). None of us have authorization to mess with Chase's applications. ;-)
86.
by nbpoole 15y ago
You can also do what I do: take the card to your local bank branch and have them widthdraw all the money off the card. ;-)
87.
by nbpoole 15y ago
It always says 'Yep' for me :/ Edit: Ah, backend returns HTTP/1.1 503 Service Unavailable .
88.
by nbpoole 15y ago
> A web you cannot easily read without JavaScript because somewhere in the page header there is a „<style> body { visibility: hidden; } </style>” later getting unset by a script that the platform owners want you to run.
89.
by nbpoole 15y ago
Interesting: MySpace seems to have a "fixed" version of the code (but the date indicates that it isn't a recent fix): http://www.myspace.com/eyewonder/interim.html <script language="JavaScript"> // NEW CODE 09-14-05
90.
by nbpoole 15y ago
http://news.ycombinator.com/item?id=3060215

More ›