nbpoole

> Status code reply: always OK since SET can't fail.

So, what kind of situation are you envisioning?

Note that the fix proposed here is fairly fragile. It doesn't actually rely on the same origin policy; it relies on the fact that browser JavaScript parsers have been modified to try and prevent attackers from reading the contents of files that are pure JSON (ie: http://directwebremoting.org/blog/joe/2007/03/05/json_is_not...).

From the Browser Security Handbook (http://code.google.com/p/browsersec/wiki/Part2):

Quite a few JSON interfaces not intended for cross-domain consumption rely on a somewhat fragile defense: the assumption that certain very specific object serializations ({ param: "value"}) or meaningless prefixes (&&&START&&&) will not parse via <SCRIPT SRC="...">; or that endless loop prefixes such as while (1) will prevent interception of the remainder of the data. In most cases, these assumptions are not likely to be future-safe; a better option is to require custom XMLHttpRequest headers, or employ a parser-breaking prefix that is unlikely to ever work as long as the basic structure of JavaScript is maintained. One such example is the string of )]}', followed by a newline.

1. Can this interface be accessed from anywhere on the Internet? If so, why? If not, does that mean other systems owned by Linode were compromised as well?

2. Why can customer service representatives access and update servers without the client being notified and with minimal logging?

For JSONP, you might consider application/javascript (http://stackoverflow.com/questions/111302/best-content-type-...)

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

> His attempt to access data was outside our whitehat guidelines, had clear malicious intent, and included extensive and destructive efforts to remain undiscovered and anonymous. In addition, he made no effort to contact Facebook with his discoveries, and even denied involvement when initially questioned. His attempt to claim he intended responsible disclosure only after faced with criminal action is false and insulting to the community of responsible security researchers.

http://www.guardian.co.uk/technology/2011/aug/17/facebook-ha...

> Between 17 April and 9 May he is accused of downloading a computer program "to secure unauthorised access" to Facebook; of attempting to hack into Facebook's "Mailman" server; of using PHP script to secure access to another Facebook server, dubbed "Phabricator"; of sharing a PHP script intended to hack into that Facebook server; and of securing "repeated" access to another Facebook server.

Personally, I'd rather require the files to be in known locations than force every client that wants the information to make a request and parse HTML.

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 resource. Normally that's fine, since PHP will see the cookie.

3. But since the request looked like it was for a static resource, Varnish stripped the cookies before passing it back to Apache/PHP. That meant PHP issued a new session that replaced the old one.

All in all, a very tricky interaction between technologies (especially since Chrome didn't display the favicon request).

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

It's how HPHP works.

https://github.com/twilio/hurl/pull/9

http://secunia.com/community/research/svcrp

Edit: Ah, backend returns HTTP/1.1 503 Service Unavailable .

To be fair to Google, that sounds like a fairly standard clickjacking prevention mechanism. It's necessary to provide protection to browsers that don't support X-Frame-Options.

http://www.myspace.com/eyewonder/interim.html

    <script language="JavaScript">
    // NEW CODE 09-14-05
    var query = window.location.search;
   	var adUrl = query.substring(5, query.length);
   	var clickthru;
   	var failclickthru;
   	if (/^http:\/\/([-a-z0-9]+\.)*eyewonder\.com\//i.test(adUrl) && adUrl.indexOf('"') == -1) {
			document.write('<s'+'cript language="JavaScript" src="');
			document.write(adUrl+'"></s'+'cript>');
		}
    </script>

Actual post: http://news.ycombinator.com/item?id=2317547

Yes. If a password is too weak and it results in a user's account getting compromised, the website gets the blame. Thus, the website mandates the password policy.

And depending on the site, weak passwords and compromised accounts directly impact other users. Imagine if eBay had no password policy and some of their largest sellers had their accounts compromised as a result; what impact would that have on buyers?