I need to send only special Users an Email. That is not a big amount. The Website must send 6 E-Mails a week. I found many solutions. I found this simple solution: https://medium.com/#edigleyssonsilva/cloud-functions-for-firebase-sending-e-mail-1f2631d1022e
When you look at the code, I need to fill out the variables. So I must type in my Email and the Password. As the web is opensource I think that is a very bad way. Do you know other simple solutions or know how to do this without typing in password?
With this solution you are using firebase functions. You most certainly want to set some environmental variables to protect some sensitives data like your gmail password.
You can do this in firebase: go check their documentation right here : https://firebase.google.com/docs/functions/config-env
The doc is going to help you set something like :
{
"mailer": {
"mail":"YOUR GMAIL ADRESS",
"password":"YOUR GMAIL PASSWORD"
}
}
So instead of you password in plain text you'll have this in your code :
'password': `${functions.config().mailer.password}`
Much safer right ?
The web is not open source. If you run a script in the browser then yes, the user can read the code. The example you link, however, runs on the server in response to HTTP(S) requests, and as such is not readable by a visitor.
I just want everyone to know that I am in no way a professional web developer nor a security expert. Well, I'm not a beginner either. You can say that I am an amateur individual finding interest in web development.
And so, I'm developing a simple, small, and rather, a personal web app (though I'm thinking of sharing it to some friends and any individual who might find it interesting) that audits/logs every expense you take so you can keep track of the money you spend down to the last bit. Although my app is as simple as that (for now).
Since I'm taking my app to be shared to some friends and individuals as a factor, I already implemented a login to my application. Although it only needs the user key, which acts as the username and password at the same time.
I've used jQuery AJAX/PHP for the login authentication, as simple as getting the text entered by such user in the textbox, passing it to jQuery then passing it to the PHP on the server to verify if such user exists. And if yes, the user will be redirected to the main interface where his/her weekly expense will be logged.
Much for that, my main problem and interest is within the security, I've formulated a simple and a rather weak security logic where a user can't get to the main interface without having to login successfully first. The flow is like this.
when a user tries to go the main interface (dashboard.php) without successfully logging in on the login page (index.php), he will then be prompted something like "you are not able to view this page as you are not logged in." and then s/he will be redirected back to the login page (index.php)
How I've done this is rather simple:
Once a user key has been verified and the user is logged in successfully, cookies will then be created (and here is where my dilemma begins). the app will create 2 cookies, 1 is 'user_key' where the user key will be stored; and 2 is 'access_auth' where the main interface access is defined, true if logged in successfully and false if wrong or invalid user key.
Of course I'm trying to make things a little secure, I've encrypted both the cookie name and value with an openssl_encrypt function with 'AES-128-CBC' with PHP here, each and every user key has it's own unique iv_key to be used with the encryption/decryption of the cookie and it's values. I've encrypted the cookie so it wouldn't be naked and easily altered, since they won't know which is which. Of course, the encrypted text will vary for every user key since they have unique iv_keys although they have same 'key' values hard-coded in the PHP file.
pretty crazy right ?. yea i know, just let me be for that. and as how the main interface (dashboard.php) knows if a user has been logged in or not and to redirect them back to the login page (index.php) is purely easy. 'that' iv_key is stored together with the user_key row in the database.
I've attached a JavaScript in the main interface (dashboard.php) which will check if the cookie is equal to 2, if it is less than or greater than that, all those cookies will be deleted and then the user will redirected to the login page (index.php).
var x = [];
var y = 0;
//Count Cookie
$.each($.cookie(), function(z){
x[y] = z;
y++;
});
//Check if Cookie is complete
if (x.length != 2) {
//If incomplete Cookie - delete remaining cookie, prompt access denied, and redirect to login page
for (var i = 0; i < x.length; i++) {
$.removeCookie(x[i], { path: '/' });
};
alert("You are not allowed to enter this page as you are not yet logged in !.");
window.location.href = "index.php";
} else {
//If complete Cookie - authenticate cookie if existing in database
}
As you can see, the code is rather incomplete, what I want to do next after verifying that the count of the cookies stored is 2 is to dig in that cookie, decrypt it and ensure that the values are correct using the 'iv_key', the iv_key will then be used to decrypt a cookie that contains the user_key and check if it is existing in the database, at the same time the cookie that contains access_auth will also be decrypted and alter it's value depending on the user_key cookie's verification (returns true if user_key is found in database, otherwise false). Then after checking everything is legitimate, the cookies will then be re-encrypted using the same iv_key stored somewhere I don't know yet.
My question is and was, 'where is a safe location to store the encryption/decryption key?' and that is the 'iv_key'. I've read some threads and things about Session Variables, Local Storage, and Cookie. And I've put this things into consideration.
SESSION - I can use session storage of PHP to store the key in something like $_SESSION['user_key'] then access it later when needed be. But I've read an opinion saying that it is not recommended to store sensitive information including keys, passwords, or anything in session variable since they are stored somewhere on the server's public directory. And another thing is the session variable's lifespan, it lasts for around 30 minutes or so. I need to keep the key for as long as the user is logged in. The nice thing I find here is that, it'll be a little bit hard to alter the value and I don't need to encrypt it (the iv_key) here since it is server sided, and hidden to the naked eye, well not unless when being hacked of course. What I mean is, they don't appear on the debugging tools just like how localStorage and Cookies are visible there.
LOCAL STORAGE - this eliminates my problem of lifespan, since it will be stored in the localStorage vault of the browser not until I close the browser. But the problem here is that the values can easily be changed via console box of the debugger tool, I can eliminate this problem by encrypting the 'iv_key', but what's the point of encrypting the encryption/decryption key? Should I encrypt it using itself as the 'iv_key' too? Or I can use base64_encode?, which eliminates the security of needing a key, and can be decrypted so easily with no hassle.
COOKIE - this one adopts two problems, one from session variable and one from localstorage. From session variable, I mean is the lifespan. As far as I've read, cookies last for about 1 hour or so, but still depends if an expiry has been declared when setting the cookie. The other is from localStorage, since it can easily be altered via console box of the debugger tools too. Although I've already encrypted 2 Cookies beforehand, but what's the point of storing the encryption key together with the values you encrypted?, should I go on with this and encrypt the 'iv_key' by itself, just like what I might do with localStorage?.
I'm lost as to where I should save this sensitive 'encryption_key' as it is crucial in encrypting and decrypting the cookies and other information my app needs.
Why am I so devastated with such security, despite having a simple worthless app?.
Well, because I know and I believe that I can use this as a two-step further knowledge which I can used with my future projects. I maybe doing web development for fun right now. But I'm taking it to consideration as my profession. And so, I want my apps to be secure in any means.
For the passport input field:
<input type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">
When the <input type="password"> is changed to <input type="text"> The password is revealed. This can be risky in systems which have saved passwords or generated from Password managers.
Can client side encryption be used in here? How can it be implemented?
Short answer: It can not be prevented, unfortunately. This is because all client-side code (JavaScript) is modifiable by the client itself - thus making a client-based security system vulnerable.
The only workable solution I can think of, is to store a hashed representation of the password, instead of the raw password. This will (if you disregard hash-bruteforce attacks) keep the raw password safe.
A hash is a representation of the original text, and is non-reversable. That is, the original string of characters can not be retrieved by any algorithm, using only the hash. Examples of hash' is MD5 and SHA. This technique is commonly used in routers, where password often is stored in the browser.
Clarification: Never store your passwords in plain-text, and if you want to adopt this technique of pre-entered password; the hashing and/or encryption must occur on server side.
I saw solutions in different answers. In all of them, it is just harder to see the password, but it does not prevent someone from seeing it.
Note: On client side JavaScript objects can be manipulated and inspected. In the solutions provided in other answers I could easily
access the password information.
As others stated, you cannot prevent the user from viewing the
password using developer tools on client side.
I could not think of a use case, but you mentioned automatic form filler and the Remember me option.
Automatic form filler, as far as I know are master password protected. They should be; I would not use one if I could not switch it on or off securely. In this case it is my responsibility to log out, whenever I am in situation of sharing a computer.
Remember me option, as often promoted by web sites, should only be used when it is your personal computer and you do not expect to share your device with another person. Don't use it or make sure no one else uses your account. Again, it is your responsibility.
Now, you still see a need to prevent such an attack. All I can come up with is the following:
There is no viable solution on client side. So your solution must work on server side.
On server side you can encrypt or hash the function. Please see this question for more details. I will discuss this further in the rest of this answer. You can opt for either solution, however implementation differs.
If you use encryption, then you can always decrypt.
That might help you in the following scenario: Keep the password always encrypted. They should always match. However, when the user wants to change his password it will be clear text. The user cannot type it in an encrypted form. You have to solve that. There are solutions. I am sure you get that.
If you use (encrypted) hashing, then it is very hard to crack. You cannot decrypt it.
This might help you in the following scenario: The server sends only the hashed version. This way no attacker can use this information. You need to design it accordingly, but I imagine you figure that out too.
Having said that, I really don't see an acceptable use case for your requirement.
Let me explain why. You want to prevent an attacker from seeing the password in case a user remembers the passwords or uses an automatic form filler. Well, if an attacker is able to access a user's computer he would be able to simply log in, why bother seeing the password?
There is a reason why companies like Google or Facebook did not bring
in a solution for your use case. The went another path and trying to
push for increased security by 2-factor authentication
If you can use that, do it. It does not solve the issue completely, but you can expect it to increase security. In particular it is harder for an attacker.
As it is clientside, there is no real way to prevent this. In terms of a security model: we can't trust the client. On the other hand, however, there is no real way to implement this differently without the use of a third party device.
If you're willing to go through the trouble of having a third party device assist in authentication: have the website generate and show a random seed, have the device ask for the seed and password to generate a hash, and authenticate on the site using the hash. Of course, the hash will still be visible if you use a web debugger, but at least there's no point in storing/reading it as the hash will differ for each session. This isn't completely secure either, by the way, as this method is prone to chosen plaintext attack.
Kudos if you're willing to go through all this trouble though. I suppose you could write an app for this to have a smartphone function as the third party device.
Absolutely not. You can't prevent the end user to manipulate the DOM from Developer tools or firebug.
Use of any client side trick can't prevent user to do that. Until or
unless the browser restrict user's from doing that.
I believe the issue you are facing is multiple people using the same computer, and if one user saves their password on your site, then any one else that visits the site on the same pc will be able to manipulate the field to reveal the password.
One way of preventing this from happening is to disable the auto-complete. autocomplete="off" Place this code in the input element and even if the password is saved, it shouldn't show up. <input autocomplete="off" type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">
Pros You don't have to worry about users sharing computers, and passwords being revealed for the most part.
ConsUsers may think their passwords are saved (and they can still save passwords) but when they get to your site, it will not show up. NOTE This isn't the full-proof way of preventing users form manipulating the form and retrieving other users passwords.
As a side note, if the site does not refresh after entering a password and user name the web browser will not ask to save the password. For example, using an ajax call in stead of form submit.
You can use JavaScript to erase the text inside the password field when the page loads. A better style would be adding the field when the page loads with JavaScript like so:var x = document.createElement("INPUT"); x.setAttribute("type", "password");
An alternative to the autocomplete="off" autocomplete alternative It involves generating a name from the backend and using it as the name of the fields so that the autocomplete will never know where to put your users saved data
Well it is not possible with current technology. Like others stated, you still can inspect all the client side code and try to manipulate the DOM.
The other solution is to implement like banking login. Randomise the password sequence every time user login. For example if password length is 10, give user three password fields, ask the sequence of password eg. 3rd, 5th, 10th. This will change every time user try to login. And in the server side you compare them.
Note: I think you should avoid doing this as it will break basic browser functionality.
But if you insist, you could make it harder for someone to reveal the password by "delegating" the typing to another input field and populating the password field with random characters.
Below is an example of one way to do so. Keep in mind that by no means does it prevent someone from retrieving the password from the request body directly or if they find your 'hidden' delegate element.
!function() {
var passwordEl, delegateEl;
function syncPassword() {
passwordEl.value =
Array(delegateEl.value.length + 1).join('*');
}
function createDelegate() {
delegateEl = document.createElement('input');
delegateEl.style.position = 'absolute';
delegateEl.style.top = '-9999px';
delegateEl
.addEventListener('keyup', syncPassword, false);
document.body.appendChild(delegateEl);
}
window.addEventListener('load', function() {
passwordEl = document.getElementById('passwordId');
createDelegate();
// steal the focus from the password input
passwordEl.addEventListener('focus', function(e) {
e.preventDefault();
delegateEl.focus();
}, false);
syncPassword(); // clear if was auto completed
}, false);
}();
Now you have the option of re-filling your password input with the correct password on form submit, or simply have your server expect the password to arrive from the delegated field.
If you fancy, you could add the appropriate styling to the password field when the delegate field is focused and thus give the user the impression that they are still focused on the password field itself.
But don't.
As already said, having a password in an input element will let the user easily reveal password.
...And as #Elyasin asks, you really should let us know what your use-case is.
Being in the dark about your use-case, let's assume you have a website that users can subscribe to for a fee and you don't want multiple users sharing one person's login to get around paying your subscription fee.
You might use cookie authentication to check that a user is subscribed to your site.
When a new user subscribes, send them an email containing a link to a special registration page on your website.
When the user follows that link, place a cookie on the user's computer indicating they are a valid subscriber.
Create a landing page on your site. This landing page will read the cookie from the user's computer and authenticate that they are indeed a valid subscriber.
All other pages on your site must redirect users to the landing page if those users don't have the validating cookie.
Since un-subscribed users may be redirected to the landing page, you might offer to let them become subscribers on the landing page.
If a subscribed user's subscription has expired, you take the cookie off the (now unsubscribed) user's computer the next time they visit your site. Like any unsubscribed user, you redirect them to the landing page.
While it's true that cookies can be intercepted or stolen, it's usually beyond the casual user's ability to do so.
If you want more security using cookies, you can capture a user's IP address when they initially subscribe. Then you can verify that the user both has a validating cookie and also is accessing from the same IP address they originally subscribe from. Of course, this limits the subscribe to using only their original IP address to access your site.
You can use a simple Javascript code to store the password value in a variable onblur and then restore it onfoucs or/and onsubmit.
Look at the following demo code and its online demo here:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>JS Bin</title>
<script>
password = '';
function setPasswordBack(){
showPassword();
}
function hidePassword(){
p = document.getElementById('pass');
password = p.value;
p.value = '*********';
}
function showPassword(){
p = document.getElementById('pass');
p.type= "password";
p.value = password;
}
</script>
</head>
<body>
<form action="" method="get" onsubmit="setPasswordBack()">
<input type="password" value="" name="password" id="pass" onblur="hidePassword()" onfocus="showPassword()" />
<input type="submit" />
</form>
</body>
</html>
It is clear that solution is JavaScript dependent solution, so in the case of disabling javascript, you may use noscript asking for JavaScript enabled browser.
Well, you can't.
But then again. There is one way of course to prevent user never seeing it using Developer console - never display the INPUT field which has the password.
The alternative would be to emulate the field's behaviour so that it seems to be there, but isn't. I have not found a technically sound solution yet how it could be done, but here is one example how it might be done: (updated) http://jsfiddle.net/858kef4h/
In this example, the idea is to create a DIV based pseudofield which looks like password INPUT and is listening keypresses from the user and saving the value to a JavaScript variable
<div class="pwField">
<div class="pwData"></div>
<div class="cursor"><div class="tfarea"></div></div>
</div>
This simple hack just has three state variables for password, focus state and the hidden textarea
var pw = "", bHasFocus = false, tfArea;
The "cursor" class is toggled on / off using JavaScript to emulate real cursor
setInterval( function() {
$(".cursor").toggleClass("blink");
},600);
When the div is clicked it creates a textarea at the place of the cursor and focuses to it.
$(".pwField").on("click", function() {
// enable cursor and create element if needed
$(".pwField").addClass("active");
if(tfArea) { // if already created, just focus to the field
tfArea.focus();
bHasFocus = true;
return;
}
tfArea = document.createElement("textarea");
tfArea.value="";
$(".tfarea").append(tfArea);
tfArea.focus();
bHasFocus = true;
$(tfArea).on("blur", function() {
// disable cursor and exit
$(".pwField").removeClass("active");
bHasFocus = false;
});
});
Then you can listen to keyup/keydown and record the values
$(document).keydown(function( ) {
if(!bHasFocus) return;
pw = tfArea.value;
// print asterisks
$(".pwData").html( asterisks( pw.length ) );
});
And when you are ready to login, the value is in the "pw" variable.
This dynamically created TEXTAREA may go unnoticed by the automatic password managers, because it is not the kind of INPUT -field the Password Managers are expecting to see.
The user which edits the field can naturally inspect the value of this element using the Chrome Developer tools, but the point here is, if the PW manager does not consider that field as a password -field it is not filling it with the password of the previous user.
I don't recommend using this, this was just made out of curiosity. The idea was to show that even though you can not prevent the user from seeing the elements, you may still be able hide the result from Password Managers. But like the old saying goes, "you can fool some of them some of the time, but not all of them all of the time".
The user experience is not the same as with standard input, but it could be improved. One problem is also that, even though you wanted to prevent the password to be shown, that may be what the users really want. They may want to user the Password Manager. But in this case you are out of luck anyway.
There may also be problems with the click, focus and blur with different browsers, they may not work with mobile devices as you expect. If this kind of hack is ever used, you should carefully tested. It could be used, if you know exactly what kind of browsers the users are using and you know they have JavaScript enabled.
EDIT: I tested the approach with some mobile devices and it seemed to somewhat work, but with iPad, and noticed that placing the hidden textarea will still create a visible cursor and change the zoom, so now the hidden textarea is placed inside the pseudocursor DIV and the zoom should follow it.
You can't, and you shouldn't. This is not a security issue you should be tackling on your website. It's up to the user to keep their passwords safe. If I have the ability to use the dev console or otherwise inject javascript on your page, no matter what you do the user's passwords will still be compromised.
If a user chooses to save their passwords in their browser, then it's up to them to prevent them from falling into wrong hands, and there's absolutely nothing you can do about it on your site. In fact, if you're using Chrome and have passwords saved, navigate to chrome://settings/passwords and click on some password fields.
Other answers talk about hashing passwords etc. That's something you should definitely do, but on your server. You could of course hash or encrypt a password before sending it to your server (and you really should too, using https), but that's a completely different issue.
The premise of this question is that the client computer is compromised and is being used by someone who should not have access. Assuming that a password manager is in use (such as Chrome's) which does not require a master password before each login form auto-fill, there is nothing you can do to prevent the attacker from gaining access to accounts.
You are trying to solve a problem at the application level when the access problem is deeper than that.
Suppose Bob forgets to log out of his computer. An attacker (Eve) stumbles upon his open Windows session and wants to gain access to his PayPal account. Bob uses a password manager for multiple accounts, including his Gmail, Paypal, and Reddit accounts. Suppose PayPal took application level precautions to prevent Eve from learning Bob's password from a password manager's auto-filling. Eve thinks she will only be able to have control of Bob's PayPal account for as long as it takes for Bob to return. But then, Eve notices PayPal's password reset link feature. Bob's email account is also compromised because his password for it is also in the password manager. With access to Bob's email account, Eve can reset any of Bob's passwords that she wants. She could maintain access by installing a keylogger on Bob's computer.
Bottom line, the security concerns you are trying to address are beyond your power to address (assuming a conventional username password model). Even without assuming anything about your application, Eve has physical access to Bob's computer, so she could compromise it in a multitude of ways.
If you make your users use two factor authentication (send them a code via text message via Twilio), make them carry around a hardware usb key, etc...you will increase security and avoid the password manager problem at hand.
But ultimately, you face a trade-off of security and usability. If Bob is too lazy/forgetful/apathetic/negligent to log out of his PC, no amount of JavaScript you write can save him.
Well , in 2019 there is a tricky way ..
you can generate forms with JavaScript / jQuery over a div
and you can put them on READ ONLY.
If the attacker will disable JavaScript then the gen code will not work then will not be any form at well...
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="Generator" content="EditPlus®">
<title>Basic security for mr. Hacker</title>
</head>
<body>
<div id="ticketAF0122"></div><!-- it is assumed that id is generated every time !!! -->
<script src="https://code.jquery.com/jquery-3.3.1.js"></script>
<script>
$(document).ready(function(){
function readonly(){
$('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
}
readonly()
$('div#ticketAF0122').bind("DOMSubtreeModified", function(){
readonly();
});
});
/*
Basicly you can load this part from an encoding external php file:
<script src="page.php?ticket=ticketAF0122">< /script>
and the php file generate something like:
$(document).ready(function(){
function readonly(){
$('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
}
readonly()
$('div#ticketAF0122').bind("DOMSubtreeModified", function(){
readonly();
});
});
*/
</script>
</body>
</html>
i already check this on xampp /windows 10 with firefox and changing with the inspector from type="password" to type="text" the script will "repair" again the things
in EDGE works buggy : when with Inspector i modify that stuff then all form is strip then inserted above html document
I've been thinking about services such as pwnedlist.com and shouldichangemypassword.com and the fundamental problem with them - trust.
That is to say the user must trust that these services aren't going to harvest the submitted queries.
Pwnedlist.com offers the option to submit a SHA-512 hash of the users query which is a step forward but still leaks information if the query does exist in the database. That is, a malicious service would know that the given email address was valid (see also: why you should never click unsubscribe links in spam email).
The solution I came up with is as follows:
1) Instead of the user calculating and submitting the hash herself, the hash (I'll use the much simpler md5 in my example) is calculated via client side javascript:
md5("user#example.com") = "b58996c504c5638798eb6b511e6f49af"
2) Now, instead of transmitting the entire hash as a query to the server, only the first N bits are transmitted:
GET http://remotesite.com?query=b58996
3) The server responds with all hashes that exist in it's database that begin with the same N bits:
{
"b58996afe904bc7a211598ff2a9200fe",
"b58996c504c5638798eb6b511e6f49af",
"b58996443fab32c087632f8992af1ecc",
...etc... }
4) The client side javascript compares the list of hashes returned by the server and informs the user whether or not her email address exists in the DB.
Since "b58996c504c5638798eb6b511e6f49af" is present in the server response, the email exists in the database - inform the user!
Now, the obvious problem with this solution is that the user must trust the client side javascript to only transmit what it says it is going to transmit. Sufficiently knowledgable individuals however, would be able to verify that the query isn't being leaked (by observing the queries sent to the server). It's not a perfect solution but it would add to the level of trust if a user could (theoretically) verify that site functions as it says it does.
What does SO think of this solution? Importantly, does anyone know of any existing examples or discussion of this technique?
NOTE: Both pwnedlist.com and shouldichangemypassword.com are apparently run by reputable people/organizations, and I have no reason to believe otherwise. This is more of a thought exercise.
Services like pwnedlist.com are working with public information. By definition everyone has access to this data, so attempting to secure it is a moot point. An attacker will just download it from The Pirate Bay.
However, using a hash function like this is still easy to break because its unsalted and lacks key straighting. In all reality a message digest function like sha-512 just isn't the right tool for the job.
You are much better off with a Bloom Filter. This allows you to create a blacklist of leaked data without any possibility of obtaining the plain-text. This is because a permutation based brute force likely to find collisions than real plain text. Lookups and insertions a cool O(1) complexity, and the table its self takes up much less space, maybe 1/10,000th of the space it would using a traditional sql database, but this value is variable depending on the error rate you specify.
Lets say I have a php generated javasrcipt file that has the user's name, id number and email adress that is currently logged in. Would a simply document.location.href look up prevent remotes sites from determining the currently logged in user?
Would this be safe?
if(window.document.location.hostname == 'domain.com')
var user = {
name:'me',
id:234243,
email:'email#email.com'
};
else alert('Sorry you may not request this info cross sites.');
Initially it appears safe to me.
EDIT: I had initially thought this was obvious but I am using cookies to determine the currently logged in user. I am just trying to prevent cross domain access to the users info. For example if the if statement was removed malicious site A could embed the javascript file and access the users info. By adding the if statement the user js object should never appear. Cross site ajax isn't supported therefore only through javascript insertion could the malicious site attempt to determine the currently logged in user.
EDIT 2: Would checking my http_refer using php be safe? What if caching is also enabled for the client? For example if the user visits my site A where the user script is downloaded and then later visits site B malicious site would the script be cached, therefore bypassing the need for the server to check the user's http_refer?
You're basically saying "here's the keys to the bank vault, here's the guard's schedule, and here's the staff schedule. But hey, if you're not from the Acme Security Company, pretend I didn't give this to you".
"oh, sure, no problem, lemme just pretend to shred this note and go rent a large truck haul away your vault contents with"
You really just don't want to try something like this. Suppose I'm running an evil site; what do I do?
<script>
RegExp.prototype.test = function() { return true; };
</script>
<script src="http://yoursite.example.com/dynamicjs.php"></script>
<script>
alert("Look at the data I stole: " + user);
</script>
No, what you have there is not "safe" in that it will reveal those details to anyone requesting the HTML page containing that JavaScript. All they have to do is look at the text (including script) returned by the server.
What it comes down to is this: Either you have authenticated the other end to your satisfaction, in which case you don't need the check in the JavaScript, or you haven't, in which case you don't want to output the details to the response at all. There's no purpose whatsoever to that client-side if statement. Try this: http://jsbin.com/aboze5 It'll say you can't request the data; then do a View Source, and note that you can see the data.
Instead, you need to check the origin of the request server-side and not output those details in the script at all if the origin of the request is not authenticated.
Update 1: Below you said:
I was specifically trying to determine if document.location.href could be falsified.
Yes, document.location can be falsified through shadowing the document symbol (although you might be able to detect that if you tried hard enough):
(function() {
var document; // Shadow the symbol
document = {
location: {
href: "http://example.com/foo.html"
}
};
alert("document.location.href = " + document.location.href);
})();
Live copy
Cross-domain checks must happen within the browser's internals, nothing at the level of your JavaScript code can do it securely and robustly.
But that really doesn't matter. Even if it couldn't be falsified, the quoted example code doesn't protect the data. By the time the client-side check is done, the data has already been sent to the client.
Update 2: You've added a note about checking the HTTP_REFERER (sic) header (yes, it really is misspelled). Sadly, no, you can't trust that. HTTP_REFERER can be spoofed, and separately it can be suppressed.
Off-topic: You're probably already doing this, but: When transferring personal details you've promised to keep confidential (I don't know whether you have, but hopefully so), use HTTPS (e.g., SSL). But it's important to remember that while HTTPS ensures that data cannot be read in transit, it does nothing to ensure that the origin of the request is authenticated. E.g., you know the conversation is secure (within reason and current practice), but you don't necessarily know who you're talking to. There's where authentication comes into it.