How do I encode a URL or hide confidential information from being displayed in the browser?
For example, I have the following link:
<a href="path/profileId/<?php echo $this->data['profile_id'];?>Edit</a>
I don't want profileId to be displayed in the browser.
Is there any function or method in Zend or PHP to accomplish this task? I am newbie in Zend so I have no idea if there is even a template which provide such functionality.
I suppose you will need the ID in some form or another on the /path/profileId/ page, otherwise you won't know which profile to display, right? If that's the case, it's impossible to completely hide it.
You could use a POST request instead of a GET request so the ID won't show up in the URL, but it'll still be visible in the HTML and the request body if you know where to look.
The real question is, why is a profile_id confidential to begin with? If somebody is able to do something bad just by knowing an identifier, your system has a huge problem.
You could of cause encrypt the information before sending it and decrypt it on the receiving end, but that seems pretty nonsensical. The typical way would be to simply pass tokens that are by themselves worthless, but allow you to resolve the real data on the backend. The prime example of this is a Session, another is passing the ID of a record and retrieving the related record, including confidential information, from the database.
You can use obfuscation for it. XOR the ID befor echo it out, XOR it back when handling the GET request.
But you should have access controls anyways, is this user allowed to open this link ?
Related
HTMLCODE IMG
PHPCODE IMG
I used the HTML file to redirect to the php file and from there i want to redirect to address below
header( "Location: https://csp-thanhhung123213.c9users.io/FINAL/HOME.php?username = thanhhung" );
My only question is that is there any way I can hide "username = thanhhung" from the link when redirect to the address above
THKS for helping me, have a nice day
There's no way you can hide any information that goes through the client. You're trying to redirect the client to another site, and make it carry some information with it. That means in one way or another, the client will need to know about the information to carry it to the other site.
The only way to not expose information to the client is to… well, not expose it. If you control both the origin and the target server, you store the information in a session server-side instead of transporting it client-side. If the two servers are separate, you could encrypt the information you give the client so the client can transport, but not read it. Another option is to give the client a meaningless token, and exchange the actual information associated with that token directly server-to-server behind the scenes.
You want a POST field, you should not use GET variables for sensitive information.
https://www.w3schools.com/tags/ref_httpmethods.asp
Edit:This question wasn't as clear when I initially posted, so here's the revised solution.
Solution 1:Nonce
What you want here is a nonce, a nonce is a value held on your server that represents a hidden value. It stands for number-once. A one time value. that way the sensitive information never leaves the server.
Before rewriting the location, store a map from nonce->username on the server, then rewrite with the nonce instead of the username. In the receiving script map the nonce back to the username, and proceed as usual.
Solution 2: Less secure
You could encrypt the string by XORing it with a secret hardcoded into each script, but since that's constant, an attacker could easily recover the key if they are able to manipulate username.
i've a jquery script which post/get data to .php script. but i wanna prevent direct access to the php script. for example if the user look at the html source code,they will be able to access the php script directly by copying the url from the js file and i dont want that. how do i prevent users from doing that?? i want the user to use it via the html UI. i've google but found no link on this. however, i did notice that some popular websites are able to do that. how should i go about doing this??
It seems like a simple redirect is what you're looking for here.
Add something like this to the top of your php file. This will prevent the page from being accessed if the proper post has not been made. Of course you'll have to change the post and redirect to content more relevant to your project.
if (!isset($_POST['data'])) {
header('Location: your-redirect-location');
}
You may also be able to redirect based on the $_SERVER['HTTP_REFERER'] variable.
EDIT: I was going to explain this in a comment but it's too long. I should note that this is a simple solution. It will keep people from accidentally accessing your script. It's really difficult to create a 100% secure solution for your issue, and if somebody really wants to access it, they will be able to. If you don't have anything secure in the script in question, this will be fine. Otherwise, you'll have to look for an alternative.
Here is one solution:
<?php
if(isset($_POST["post_var]))
{
//to the code you want to do when the post is made
}
else
{
//do what you want to do when the user views the post page
}
?>
how do i prevent users from doing that?
You can't - all you can do is mitigate the risk people can fiddle with your script. Making sure you have the right HTTP_REFERER and/or POST data are both useful in that regard: a "malicious" user would need more than pointing her browser to the URL.
More techniques can be used here:
using session variables: you might not want users that are not logged in - if applicable - to use the URL.
using a one-time challenge (token): you can place a value in the HTML page and have the JS code send this value along with the POST request. You store this value in the session when it is generated. Checking the POSTed token against the session token guarantees the user has at least "seen" the HTML page before submitting data - this can also be useful to prevent duplicate submissions.
However, remember that anything a browser can do, people can do it as well. All these techniques can prevent the curious from doing harm, but not the malicious.
All you can do is making sure nobody can really harm you, and in this regard, your Ajax URL is no different than any other URL of your site: if it's publicly reachable, it has to be secured using whatever technique you already use elsewhere - sessions, user rights, etc.
After all, why should you care that users use this URL not using a browser ? You might want to think of it in terms of an API call that, incidentally, your page happens to use.
Your problem is similar to and has the same problems as a cross site request forgery.
To reduce your risk, you can check the request method, check the referrer, and check the origin if set. The best way is to have a secret token that was generated on the server that the client transmits back in every request. Since you're dealing with friendly users who have access to your live code, they may be able to debug the script and find the value, but it would only be for one session and would be a real hassle.
I am working on a PHP/MySQL messaging application in which a user can see a conversation and reply to it. On the view page of the message I have a reply field. To save the reply I need to know the ID of the message which is being replied to. I have been trying to pass this ID in a way, which is both secure and reliable. A simple hidden field with a POST won't do it, since the user can tamper the data and modify which message he is answering. Creating a session variable with the id of the message on the view page provides the security but causes a highly undesirable side-effect: if the user views another message after opening the one he is replying to, the response will be posted to the other message.
Any one got any alternatives ?
You can encrypt the id with the mcrypt library and pass the encrypted form in the url. If your userbase has the collective IQ of a zucchini, you could probably get away with simple obfuscating as Hex or base64. But otherwise, mcrypt->base64 will be more than enough
Use 2 kind of ID, like: ?id=45sdf6g78g9s7987sd9f87&id_hash=65d4f98s7gsdg54g98dg
Is there a way to only let a webpage be viewed if the link pointing to it is pressed. I am sending emails to members of my organization with links that attach values to the URL so I can use phps $_GET to figure out who they are on the webpage and update appropriately. What I am worried about is individuals changing the values of the link and changing other members data. If there is a better method for doing this, I am all ears. Using a log in system is not an option.
Not exactly, no.
What you could do is include some token that you keep associated with a particular user id and is very difficult to guess, and include that in the link as well - then, when you get a GET request, you check to make sure the token matches the one you know is correct for that userid. (You'd store the "correct" tokens locally in a database when sending out the emails.)
For instance, you might have...
/modify_info_script?user_id=123&token=aSDqWEqwejk2123salskq
And then you'd have a database table or some other storage that has...
user_id token
----------------------
... ...
122 klqwkejajwie8u8213nak
123 aSDqWEqwejk2123salskq
... ...
and thus if someone tried to change the user_id in the URL, the token wouldn't match and you could reject their request. For instance, this would get rejected...
/modify_info_script?user_id=122&token=aSDqWEqwejk2123salskq
since the right token for 122 would be klqwkejajwie8u8213nak, not aSDqWEqwejk2123salskq.
This is probably the best option if using a login system isn't an option. However, you should really make sure that using a login system isn't an option at all, because user data really should be protected by a login.
This is really not the proper way to secure your site.
However, the simple fix for you is to check the "referer" header and make sure it's not blank. If it's not blank, then it came from a click (or they spoofed it, which is why this isn't secure).
The real way to protect data is to implement a login system with a set of permissions.
To check, if someone came from a link, see $_SERVER['HTTP_REFERER'].
To protect the application against link manipulation, you can combine it with a secret passphrase (only internally, the passphrase must not be known to anyone) and use md5() on the result. Attach the MD5 to the url. If anyone manipulates the url, you will know because the MD5 of "the url plus your passphrase minus the MD5" will be different.
Quite a lot password reset systems work like this so you could say it's reasonably safe provided you use long enough random token. Something like 32 chars should be fine.
Just providing the token should be enough since you don't need the user ID to check it against issued tokens in database.
/modify_info_script?token=aSDqWEqwejk2123salskqfilltill32chars
The other alternative is to have login system where use has to type in their credentials in order to change information.
Also if you really fear that someone might try to guess it, just timeout/ban users after 3 wrong token attempts. No one should be trying to type them in by hand anyway.
I have
echo <a href=\"javascript:;\" onClick=\"window.open('". $link ."','no','scrollbars=yes,width=550,height=400')\" >View report</a>
$link contains sensitive information, so I'm wondering if there is a simple way to prevent this link showing up explicitly when you "view source code" on the browser. Any alternative to href would be fine. I just need to give the user an option to click and see his processing result after he submits some data. I would like to avoid having auto popups as soon as the processing is submitted.
UPDATE: so the $link is a GET URL that includes a user ID and password.. It's internal right now so it's fine, but I'm thinking of putting this on our online server in the future. I'm very much a novice with PHP, so this is probably not in the near future as I don't know much about security features that need to be implemented for a live site on the Internet. Right now, it seems that utilizing a database would be the best way to go. Correct me if I'm wrong, please, and thanks for all of the support!
If the user has to navigate to the link, there is no way to actually hide the information. You should rethink how your process works so sensitive information is not displayed in the link.
Perhaps you can store the information in a database table and the link would just use the id of the row that has the information.
Simply put: No. If you send me to a URL, I will be able to see it using some sort of tool. Wireshark, Fiddler, etc. Consider using a different link structure.
If the user already owns a session, this is an option:
If you render a page and need to protect this given sample secret URL
http://www.MyHost.com/?what?secret&id=23232
save the URL in the user's session and associate a hash value with the secret URL.
Instead of sending the URL to the result HTML-page, insert another URL, e.g.
http://www.MyHost.com/?continueWith=<hashValue>
If this URL gets called, check the user's session and retrieve and delete the secret URL. Then continue to evaluate, as if the user had called the secret URL.
This way, no parameter of the original secret URL ever reaches the user's browser.
To refine the schema, attach a lifetime to the URL saved in the session. If a request comes later as the end of life, return an error.
If you protect all URL in such a way, users won't be able to call arbitrary URLs, since all acceptable URLs are those inside their sessions. Thus, a user will even not be able to change parameters of less secret URLs.
How is $link generated in the first place? If it is sensitive, this implies that the user has already been authenticated somehow. Thus, the information in $link can be stored in the session where it's safe
Save all the information in your PHP session (or preferably the session system your PHP framework uses) and then just send some kind of non-db-associated identifier in the link so that the code knows what you want to do next.
For example you could have a link to "http://www.yourdomain.com/sec/special_action/4" with "sec" meaning secure, "special_action" being the name of the action to take, and "4" being the action id reference.
So lets say you have to have it associated to their social security number. Then you would in your back end use a salted hash to encrypt the SSN and save it to the session data. You then append it to the end of your session array and get an array count. If it returns 5 then you know that the encrypted SSN is saved in index 4 (since PHP uses 0 based indexing). So you send along that index as part of the link to confuse things even more. Heck you can even salt and hash the index if you want.
The user clicks on the link, the code finds the index, grabs the encrypted content, decrypts it, then uses it. Easy and secure.