Hacker News Reader

Comment by homakov | Hacker News Reader

Google is wrong IMO: there is no need to have such workaround. In rails we had similar problem https://community.rapid7.com/community/metasploit/blog/2013/... and fixed it by adding request.xhr? check on server side.

while(1) is ugly solution to currently non-existing problem.

View on HN

When you have n-hundred-million people's personal information at stake, 'currently non-existing (but multiple-times previously existing)' is not very reassuring. There's nothing wrong with multiple layers of safeguards.

Does your solution assumes referrer will not be manipulated on the client side?

I imagine it assumes a header like X-Requested-By has not been manipulated. You can safely assume that the referrer, or other headers, have not been manipulated. There is no way for malicious Javascript running in the users browser to edit headers.

Of course, anyone can code their own browser to lie about headers. It doesn't make much sense to specifically open yourself to vulnerabilities though.

exactly. since normal script-tag cannot drop new X-Requested-With header, there's no need to add some "while(1)" things which look ugly.

There's downside, though - you can't inspect JSONs by simply opening them in a new tab.

my solution is request.xhr? check. the link above is only to explain what rails-bug was. I don't think checking referrer is a good idea there.

Hey Egor, article author here. How come you are not such a fan of checking referer? It cannot be a global fix (some sites depend on serving xdomain scripts, have lots of users with proxies that alter headers etc), but it should work well for many cases no?

it works of course, but to be compatible with many environments we need something more reliable than Referrer.

Sorry Egor, I thought you are pointing out an article you have published.

This is joev's article. His explanations of the issue are better than mine ;)

Reply on news.ycombinator.com