nbpoole

You can find it by going to "Install Chrome for all user accounts" http://support.google.com/chrome/bin/answer.py?hl=en&ans..., which points to "Alternate (offline) Google Chrome installer (Windows)" http://support.google.com/chrome/bin/answer.py?hl=en&ans...

You want the "Alternate installer for all user accounts" (https://www.google.com/intl/en/chrome/browser/eula.html?syst...). That will install Chrome in the Program Files directory.

It was a neat little idea to play around with when I first wrote the post, since setting X-Requested-With on an arbitrary domain requires a violation of the same-origin policy. But as I point out at the top of the post, there was at least one recent case of a same-origin violation (via the Flash 307 bug) that allowed for arbitrary headers to be written.

CSRF tokens, whether they're in headers or in a form, are the more secure way to prevent an attack. They require a violation of the same-origin policy where an attacker can read (at least part of) the HTTP response sent by your server. If an attacker can do that, you already have larger issues.

The dataset also does have applications from prior to 2000, it just has (relatively) fewer.

"Today I installed Debian google-chrome-unstable and it also exhibits this issue."

One commenter (http://code.google.com/p/chromium/issues/detail?id=128339#c3) also claimed to have the issue on OS X specifically.

Edit: Are you proxying to an Apache server that runs PHP-CGI?

"Glenn Mangham, 26, had earlier admitted infiltrating the social networking website between April and May 2011."

I just checked my old emails and found XSS vulnerabilities I reported to Facebook, under their responsible disclosure policy but prior to the introduction of the bug bounty program, from late 2010 / early 2011. His timeline doesn't match reality.

That's a discussion of it from back in August. It started prior to that. And before that Facebook redid its existing responsible disclosure policy (https://www.eff.org/deeplinks/2010/12/knowledge-power-facebo... | From December 2010).

No, but they normally report the vulnerabilities they find.

I participate in a lot of responsible disclosure programs (Google, Facebook, Mozilla, Dropbox, Twitter, Etsy, etc). All of those programs dictate that you report the security vulnerabilities you find, and that you not abuse them.

What was described in the blog post sounds a lot like real security audits that I've seen done. However, the difference is that those audits are done by professional security researchers who have been hired by the company for that purpose. If you're an outside security researcher you have to abide by a very different set of standards. Common sense would argue those standards include abiding by the company's responsible disclosure policy.

http://news.ycombinator.com/item?id=3604623

This comment in particular was very relevant:

http://news.ycombinator.com/item?id=3605343

http://www.woothemes.com/2012/04/were-alive-and-kicking/

Then use === and do a type-strict comparison.

    <?php

    // Prints bool(true)
    var_dump('9223372036854775807' == '9223372036854775808');

    // Prints bool(false)
    var_dump('9223372036854775807' ==='9223372036854775808');

- http://news.ycombinator.com/item?id=3791281

- http://news.ycombinator.com/item?id=3789673

- http://news.ycombinator.com/item?id=3778158

1. What is "safe content"? That entirely depends on the context in which you're using a particular string. (See https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%... for a summary of the kinds of things you have to think about)

2. The system you're describing is somewhat similar to http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/. People still find plenty of XSS vulnerabilities in Rails applications.

3. http://lcamtuf.coredump.cx/postxss/

And the whole point of CORS is that some websites do want to make those requests. ;-)

One reason I've also heard cited is that you always want the logout links in your application to work: you want users to be able to terminate their sessions quickly and easily. If you have a CSRF token tied to your user's session and that user happens to click on an old logout link (maybe they had an old tab open or something), the user won't be logged out of the application.

It actually will work.

What you're describing is what's known as a "simple" request in XMLHttpRequest terms. That means there is no pre-flight necessary. Your browser will simply make the POST as requested and receive the response. It won't make the response available to you since the Access-Control-Allow-Origin header isn't set, but you're a malicious attacker in this example and you don't care what the response is: you just care that you were able to make the request. ;-)

You could even do this by creating an HTML form that POSTs to the right URL and using JavaScript to submit it automatically when the page loads. Same exact thing: no CORS checks.

If a pre-flight were necessary you would be right. The browser would send an OPTIONS request to the server, the server would respond without the appropriate headers, and the POST request would never be sent.

Let me know if any of this needs further explanation!

(sorry for being oblique, but I have no way to contact you privately and ask you more directly!)

---

https://developer.mozilla.org/en/http_access_control#Simple_...

A simple cross-site request is one that:

- Only uses GET or POST. If POST is used to send data to the server, the Content-Type of the data sent to the server with the HTTP POST request is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain.

- Does not set custom headers with the HTTP Request (such as X-Modified, etc.)

---

This is actually a big deal, since it means you can send a cross-domain mutlipart-POST with no preflight. That allows for an effective CSRF attack against file upload systems.

And of course, cross-domain POST requests via <form> tags have always worked and will continue to work.

If you find a major hole in a part of Git, you are by no means obligated to tell GitHub. You are, however, legally obligated not to compromise their site using that hole.

Or, a better example: you can talk about XSS mitigation strategies all you want. You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.

No it can not. I've seen this assertion popping up a few times on HN this past week: it's conflating two similar but very different attacks in a dangerous way.

X-Frame-Options prevents a type of attack known as clickjacking. It is similar to a CSRF, but it involves creating an iframe to a page with a form and convincing the targeted user to submit it. It provides this protection at the browser level: if an HTTP response contains the X-Frame-Options header and the requesting page violates that directive, the response is not rendered.

It does not prevent a CSRF attack. It's impossible for it to do so: once the malicious request had made it to the server and the server has sent back a response, the attack is already complete. There's nothing the browser can do to prevent it at that point. If you use nothing but X-Frame-Options to try and prevent CSRF, you'll have a site completely vulnerable to CSRF.

See http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-... for examples

I'm not quite sure what you're trying to say here. But you can make cross-domain POST requests in two ways, both involving JavaScript:

1. Create an HTML form, use JavaScript to submit it.

2. Use XMLHttpRequest to make a cross-domain POST.

CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to get that token, they would need to be able to do at least one of the following:

A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess)

B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues.

C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.

That was my interpretation as well and I reached the same conclusion. Having the average user make application-level security decisions is a very bad idea.

RequestPolicy is a wonderful extension and I think its use should be encouraged. But the average user does not understand enough about an application and how it interacts with third-party websites to make informed decisions about whether a particular interaction is good or not. False positives (where the user flags a good interaction) will lead to loss of functionality while false negatives (where the user fails to flag a bad interaction) will lead to security vulnerabilities that website owners can't prevent.