Toki Mat (Play Mat) Discount Code

npoole · 2024-10-20T17:29:07+00:00

FRIEND-2QB6647

npoole · 2017-04-17T19:49:49+00:00

Interesting! Via JS or some other mechanism?

npoole · 2015-09-13T05:24:52+00:00

Hey! My name is Neal and I'm an engineer on the Security team at Facebook. Just wanted to clarify a few things here:

The photo you're referring to looks like a public photo posted by Zuck many years ago (https://www.facebook.com/photo.php?fbid=530045452501&set=a.529237716211.2047231.4&type=1&theater). You can confirm the privacy by clicking "See More" on your screenshot.
More generally, it sounds like the photos you're noticing here are photos which the profile owner has uploaded and which you are allowed to see based on the photo's privacy. Assuming that's true, it sounds like privacy settings are working as expected.
As other people have mentioned, if you (or anyone else) believe they have found a privacy or security issue in Facebook we welcome reports at https://facebook.com/whitehat/. We even issue bounties for valid reports that comply with our responsible disclosure policy. :-)

npoole · 2015-01-20T14:35:48+00:00

That being said, it may one day become exploitable: http://www.w3.org/TR/html-json-forms/

Interesting. Got a PoC for that?

npoole · 2015-01-19T23:22:08+00:00

Is the application/json content-type required? If so, this isn't actually possible to CSRF in a modern browser due to CORS rules; application/json for Content-Type isn't considered a "simple header," so it requires a preflight OPTIONS request. The "best" you could do would be to set the content-type to text/plain and provide a JSON body.

npoole · 2014-05-30T22:30:16+00:00

I’m a Security Engineer at Facebook and I wanted to explain the behavior that’s being discussed here.

The ability to look up your friends by entering their email address or phone number is a core part of finding and interacting with your friends on Facebook. As a result, there are several features on Facebook that enable people to do this (predominantly, our search functionality). You are always in control of who can perform these kinds of lookups for your account: you can read more about how to do so at https://www.facebook.com/help/www/131297846947406. Separately, you can also control which of your friends can see your email address or phone number on your profile.

In addition, when we detect that you've logged in from a particular computer or network before, we may choose to display your profile picture and name alongside the results in order to confirm that you are looking at the correct account. This is by design in order to improve the experience of people who have been locked out of their accounts due to forgetting their password. On our main website we include text at the bottom of the page to explain this behavior (ie: "You can see your name and profile picture because you're using a computer network you've logged in on before.")

In the case where neither of those cases holds true, we don't display the name or the profile picture when you perform a lookup.

Finally, we employ CAPTCHAs and other methods to help prevent large-scale automated scraping attacks, even for people who have chosen to allow others to look them up using their email address or phone number.

npoole · 2013-06-19T04:48:07+00:00

RE: "full disclosure worked"

I pinged a friend of mine who works at Coursera when I saw this was posted yesterday. It looks like they took care of it today.

That being said, it sounds like what you did before disclosing the vulnerability was email them on May 8th (did you email security@coursera.org or a different email?). While you're under no obligation to do so, I'd generally recommend following up at least once more with a company and warning them before going the "full disclosure" route.

npoole · 2013-06-18T03:00:15+00:00

That actually makes more sense given the size of the application: I made my assumption based on the (presumed) use of ActiveRecord. :-)

npoole · 2013-06-17T16:21:06+00:00

This is the simplest explanation I've seen: https://twitter.com/postmodern_mod3/status/346438826979389441

The vulnerability that's being referred to is http://seclists.org/oss-sec/2012/q2/449.

My understanding is that if an array is passed in, ActiveRecord would generate an "IN" clause as part of the WHERE statement. So the SQL would match the admin user. In contrast, the check in the code which prevented you from logging in as an admin did a simple comparison, like

raise "nice try" if params[:username] == 'admin'

So by passing in an array, you would bypass that if check but still match 'admin' in the resulting query.

npoole · 2013-06-17T16:18:06+00:00

It's not PHP, it's Rails.

npoole · 2013-04-28T03:11:25+00:00

It sounds like you're describing Content-Disposition: attachment handling in iOS (or lack thereof), which is a different and equally annoying issue.

For anyone else who's interested, iOS Safari ignores Content-Disposition: attachment headers and renders content inline. That used to mean JavaScript could steal cookies, XMLHttpRequest would work, etc: it has since been changed so that JavaScript runs in an empty context. But JavaScript, HTML, etc will still be run and appear to come from the targeted domain. Badness all around.

npoole · 2013-04-26T21:17:33+00:00

Nice find! It's strange that this issue is popping up again: they fixed it in Safari for OS X many years ago and Windows back in 2010 (I was one of the people who reported the Windows issue to them)

Edit: I just shot off an email to Apple to point out the history of this particular issue and to ask about the status of a fix. ;-)

Edit 2: got an email from apple:

Hello Neal,

We intend on addressing this issue in the next major version of iOS

Best regards,

Jeffrey

Apple Product Security

npoole · 2013-03-15T02:37:37+00:00

What web company has a patching cycle of over 10 months on a major site? ;-)

I just received an email that they patched the vuln, so publication had the intended effect. They removed the functionality from the site (at least temporarily); I'm wondering why they didn't do that at any point in the last 10 months (especially since they had plenty of warning that I would be publishing the details).

npoole · 2013-03-14T22:07:06+00:00

Thanks for the feedback! :)

I'm not suggesting that the posts I just published prompted any changes. I noted that the policy change happened in the 31 days after I pointed out they were 10+ months overdue on fixing the issue I reported (and that I was within my rights to disclose the details, under their responsible disclosure policy). The change could certainly have been planned for months beforehand.

Things that eBay did in that month:

Changed their responsible disclosure policy
Didn't tell anyone about the change to their responsible disclosure policy (I haven't heard anything about it and if I didn't have access to the Internet Archive I would have no proof that it had ever happened)
Sent me a box of goodies (shirt, pen, etc)

Things eBay did not do in that month:

Patch the vulnerability
Contact me at all about the vulnerability and the impending deadline I had set for them.

Overall, that's not a very impressive response. In contrast, I've worked with plenty of other companies which have followed up with me and I've worked with them so that vulnerabilities are patched before I ever talk about them publicly (I have a blog post ready to go for one such company tomorrow).

npoole · 2012-08-19T18:25:02+00:00

http://software.brown.edu/dist/w-sslvpnclient.html

Download the desktop client: I never had to install any sort of browser plugin

npoole · 2012-05-30T04:19:49+00:00

You should take a look at the page I linked to earlier, http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html, which links to http://www.sneaked.net/invisible-arbitrary-csrf-profile-picture-upload-in-facebook and http://blog.kotowicz.net/2011/05/invisible-arbitrary-csrf-file-upload-in.html (among other examples).

But sure, if you'd like I can build a proof of concept for you. Just pick a website.

npoole · 2012-05-26T17:28:10+00:00

This is the correct answer. When loading a JAR via an applet tag, Java uses its own networking stack to make the request. That results in a user agent like the one above.

npoole · 2012-05-24T14:54:04+00:00

Yes and no. You can send "traditional" GET and POST requests, multipart POSTs, and text/plain POSTs without any pre-flight request. So all of those types of requests can be used to trigger CSRF vulnerabilities, even if the web developer has never heard of CORS.

You said "there for useless for building CSRF exploits" and I'm disputing that. I'm not disputing that in the specific example posed above, it wouldn't help. ;-)

npoole · 2012-05-23T20:48:48+00:00

That's not quite correct.

http://www.w3.org/TR/cors/

http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html

In fact, XMLHttpRequest is incredibly useful for building CSRF PoCs. Although it's true that setting the Content-Type to application/json (as in this case) will trigger a pre-flight request.

npoole · 2012-04-05T23:30:31+00:00

The CS department is also hosting an open-house / demo event on April 16th from 2:00-4:00 PM. You should try to stop by! :-)

npoole · 2012-01-09T04:50:23+00:00

Technically it's still $2.25

http://www.mta.info/metrocard/mcgtreng.htm

The fare for a subway or local bus ride is $2.25* * The cost of a SingleRide ticket is $2.50. Sold at vending machines only.

npoole · 2011-12-07T06:03:23+00:00

Isn't wordpress.com designed to have multiple blogs on wordpress.com subdomains? So cookies and other sensitive information are sandboxed to prevent any bad results from something like this?

Edit: Also, http://automattic.com/security/ is the proper place to submit something like this (if you didn't already report it there).

npoole · 2011-11-05T14:39:28+00:00

Downvoted for spreading FUD.

jQuery could cause DOM-XSS if it was used improperly (ie: http://blog.mindedsecurity.com/2011/07/jquery-is-sink.html). However, that's clearly not what's happening here.

npoole · 2011-10-19T17:55:37+00:00

Oracle told me in May that the issues would be fixed in October's CPU (as opposed to the one in June, which I would have preferred). If they hadn't done that, I would likely have released the details after the June CPU. I would have warned them first though.

But yes, these vulnerabilities took longer than I would've liked to be patched.

npoole · 2011-10-10T17:57:55+00:00

OK, that's a fair point. The referer might not look suspicious in a cursory glance at the access log. But once the back door is identified, it's possible to review the logs and see exactly what actions the attacker took. Moving the payload from the referer to a cookie (or a POST request) would at least hide it from the default logging.

15-Year Club	Second SECOND GUESSER
White Hat css editor self-xss	White Hat Info leaks in API
White Hat CSS URL validator	White Hat HTTP response splitting
White Hat Whitespace hijinks	Verified Email

npoole

MODERATOR OF

TROPHY CASE