Develop Reference

Access website Y only after you are redirected from website X

I have a slightly strange question and I'm not sure if this could be achieved at all but anyway I'm curious to try.
I have 2 sites that are independent, lets say www.site1.com and www.site2.com.
site2 will be placed in a href in site1. The question is - is it possible site2 to be accessible only after the user is redirected to it from site1 and if the user tries to open site2 directly or thru an a href from another site different then site1 to not be able to access it?

Check for:
window.document.referrer
// Empty if User is directly loading page.
The value is an empty string if the user navigated to the page directly (not through a link, but, for example, by using a bookmark). Because this property returns only a string, it doesn't give you document object model (DOM) access to the referring page.
MDN Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Document/referrer
Browser Support:

You can check for a post parameter that you set from the website 1 redirection (either through a form or plain javascript). And then set a local storage variable to check for when loading site 2.
Local storage doc
JavaScript post request like a form submit
But keep in mind this can be easily bypassed with enough html/js knowledge.
To ensure that only your website can make post parameter, you could maybe (not sure about me there): generate code (used as post parameter) on the go from webserver 1 and send them to webserver 2 at the same time (or a little before) to ensure the code received by the server 2 is really generated at server 1

Depending on the backend server you are using, you can use something called REFERRER details that will be there in the http header of the request ( for your www.site2.com page for example). This REFERRER will have the information on who referred the user to this site. You can add a condition something like if REFERRER is www.site1.com then render the page .
Here is a link to start with
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

How to store a user's context with AAD B2C token

I'm using AAD B2C to secure a JavaScript application and backing web services. Users may be associated with multiple companies, so I plan to use a dropdown and allow a user to choose which context they wish to act under.
The backend web service needs to receive the "context"... so I feel like a I need to add a value to the AAD B2C token after the user has been authenticated... or I need to call back to AAD B2C with the value somehow.
I can't find any documentation to suggest this is possible.
Is this a supported user flow?

You cannot simply "add a value" to a token. The token is created and signed by MS, not by your app.
But you can define a custom claim and have it included in the token. Let's say you name it Contexts and it will be the list of IDs or names of the companies the user has access to. After a successful login, the token with this claim is returned to your js and you can parse it to get the individual items (companies) to display in the dropdown. After the user has picked the preferred context from the dropdown, you pass it to your backend web service as an extra parameter, not as part of the token.
Managing the Contexts property/claim can be done via Graph calls - I suspect you don't want to allow the users themselves to add in there whatever they want.

They only way to achieve this scenario, where a consumer has respective access rights to multiple tenancies within your scenario, is to use Custom Policies:
Collect the users credentials and validate
Call a REST API to send back a comma delimited list of tenancies the user has access to
Display a self asserted page with 2 B2C claims in textboxes. One should be populated with the comma delimited list from 2) using InputClaims.
Customise this page with JavaScript enabled, use JS to render a drop down box with its enumeration from the populated text field from 3.
When the user selects from the drop down box, send the result using JS to the other text box that was rendered.
Use CSS to hide the 2 text boxes.
When the user submits the page, use a ValidationTechnical profile to send back the users input to a REST API to make sure the value is within their authorized list of tenancies.
Insert the tenants name into the Token using the Outputclaims section of the RelyingParty element.
The App can now know which tenancy to show, with correct access rights.

Anti-CSRF approach in chat application where textarea is rendered once

I am integrating chat application in my website. Chat boxes are managed using a javascript library. They are HTML components to which I append a textarea where the user enters the message to be sent (Facebook-like style of chat).
The messages exchanged are persisted in a MySQL databases. Server side language is PHP under Symfony2 framework.
How can I secure my database in this case? Normally, to prevent CSRF vulnerability, I generate a CSRF token when the form containing textarea is rendered. Symfony2 helps to easily validate against the token. But in my situation, textarea is used without a form. I can wrap my textarea inside a form with hidden input token field, but I don't think it will be appropriate to render a new form (with new token) whenever a new message need to be sent.
Could you please share with me your insights regarding such issue? Are there any tricks for chat applications to prevent CSRF attacks? Any advice is highly appreciated.

One method would be to use a counter approach.
So on first form render, you include a token. Each response includes that token and an incrementing counter (starting at a random number). After the first request, you know on the backend which counter position is valid, and can invalidate the token if you find an invalid counter position. Then after 100 (or 1000 or whatever) requests, force a token refresh (which does a normal request to get a new token).
So the convo would look like:
Client Server
getToken --------------------->
generate new token
<-----------------------token // x4asf3%2f
generateCounter() // 2332523
sendText(text)
{text: text, token: token, counter: counter+1}
-------------------------->
if (!isValidToken(token)) error()
saveCounter(token, counter)
doSomethingWithText(text)
sendText(text)
-------------------------->
if (!isValidToken(token)) error()
if (counter != getCounter(token)+1) error()
doSomethingWithText(text)
This is similar to the syn-ack process that TCP uses.

The important features of an anti-CSRF token are that:
Each user must have a different token. (A user might also have several tokens for different purposes, but no two users may share a token.)
It must not be practical for a malicious user to obtain (or construct) a valid token for another user.
Each request (that could have unwanted effects if done maliciously) must include a token.
The server must not accept the request unless it contains a valid token for the user performing the request.
Requirements 1 and 2 are typically implemented either using a cryptographic message authentication code to generate the tokens, or simply by assigning a randomly generated token to each user (or session) and storing a copy of it on the server.
For traditional HTML forms, one way to implement requirement 3 is to include the token as a hidden field in the form. However, that's not the only way to do this. In particular, if you're submitting requests by Ajax, all you need is to have your Ajax code somehow obtain the token (e.g. from a hidden field, or an HTML data attribute, or simply from a piece of JS code somewhere on the page) and include it in the request.
For example, if you look at the HTML source of this Stack Overflow page you're reading right now, you'll find a piece of JavaScript that looks something like this (un-minified):
<script>
StackExchange.init({
"locale": "en",
// ...snip....
"site": {
"name": "Stack Overflow",
// ...snip....
},
"user": {
"fkey": "0123456789abcdef0123456789abcdef",
// ...snip....
}
});
// ...snip...
</script>
The user.fkey value (which, for obvious reasons, I've changed above) is a random 128-bit anti-CSRF token that is stored in the StackExchange JS object, and is included in every Ajax request made by the scripts on the page.

How can I go to an html page while passing a hidden parameter using Javascript or jQuery?

Upon completion of an ajax call I would like to direct the user to an html page, but at the same time passing a hidden variable (this variable contains sensitive information and should not show up in the URL).
How can I accomplish this?
window.location.href = 'userpage.html?id=14253';
But with the id remaining invisible? Can I POST the id somehow while sending the user to userpage.html?

You should not be checking user credentials on the client side of your website. Regardless of how the ID is being passed to your script, it can be replicated without you being able to check if the request is valid.
To start being even remotely secure with what information is granted to a user, you need to be checking it via the server side. With every request, ensure the user is authenticated to view such data.
If I were you, I would look into using PHP sessions as the first line of defense for checking if a user is authenticated. Doing so will at least keep the information about a user out of a replicable space that can be viewed by the user.
Look up 'php session login tutorial' on Google and you will find plenty of simple tutorials which should get you on the right track.
Example Tutorial

No matter what, the information you pass along is insecure. You can submit a post request using XMLHttpRequest objects if you'd like (or use a framework/library to make AJAX calls) -- but the user could still spoof the data and get different results.
ID enforcement should be done in the backend. Does the requested ID match the ID of the user signed in? No? Don't show it. etc etc.

Meteor.userId from the client - changing shows user email, correct behavior?

I was looking at another question's answer regarding changing the userId from the client side and following along but not getting expected results;
Meteor.userId is changeable
I followed steps 1 through 5 just fine with no issues but then set the userId() to the user I'd just logged out in a separate browser using Meteor.default_connection.setUserId('usersfjhjdskfh');
Rather than display a spinny in place of the email address since the server shouldn't be returning data, it displayed the actual user's email address I'd used there. (It did not however, bring back the party information and show it on the map).
Is this intended behavior and I missed the point of the last answer given back in December or has something changed? (I'm running Meteor 0.6.2 and both insecure and autopublish were removed from my example)

Im assuming you want to change the user's _id and not change the logged in user via an id. To change the user id you could probably do something like
Meteor.users.update(Meteor.userId(), {$set:{_id:<new Id>}});
Assuming you have the correct permissions in place with Meteor.users.allow. This should change the _id of the current logged in user.
The previous question demonstrated the security when changing local client side Meteor functions and how it would affect the server. The Meteor server doesn't trust anything from the client and double checks it with the allow/deny rules before changing it whatever the data may be for that current logged in user. So the user does need to be logged in to change any data about them on the mongodb database on the server for the allow/deny rules to comitted.