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.
Related
This may be a question someone has already asked. (If it is I'm sorry, I could not find another question like this.)
I designed a webapp on PHP-NODEJS-Static HTML. I send a form from the static HTML to the NODEJS app to get approved. If approved I want the nodejs application to redirect to a php page. I already have the nodejs application up on heroku, and it is designed so if it is approved, it automatically redirects to a php page. The problem is that I only want the redirects from the server to be able to display the php page if that makes any sense. How do I go around doing this.
You'll need to have your nodejs, before redirecting, create a secure one-time token. The token should be embedded into the URL pointing to the PHP server (the one that the browsers will follow for redirect), and stored in a database (probably associated with an expiration, umm, say 5 minutes?).
When PHP page receives the request, it should extract the token from the URL, and validate whether the token exists, and only proceed further then. PHP page should also remove the token once used. You will need some sort of a database to store the token, I would recommend Redis, as it has an automatic expiration of keys, so you don't have to worry about clean up, or clogged database.
I have a simple PHP script which accepts a $_REQUEST from a javascript Ajax call and adds a post to the DB
But I need to ensure that only javascript requests from my domain is allowed, to prevent someone from submitting thousands of junk posts to my DB.
My question is, how do I ensure that my script only accepts $_REQUEST from my domain?
Thanks
The short answer is: You can't.
It sounds like you need to introduce the usual defences against CSRF (i.e. to generate a random security token and store it in a cookie (or session) as well as in your HTML document. You then submit the token as part of your request and compare it to the one in the cookie. If they match, then it is an intentional post from the user and not their browser being tricked into making the request by another site).
This won't stop people submitting "thousands of junk posts" though. You also need to authenticate users and check they are authorised to make a submission before allowing it to go through.
You can consider also including rate limiting checks and spam filtering.
You use a 'secret' key, a response and a remote IP to validate.
Google has provided this for you
https://developers.google.com/recaptcha/docs/verify
https://developers.google.com/recaptcha/docs/display
https://developers.google.com/recaptcha/docs/invisible#auto_render
works like a charm.
Once you implement you get an ADMIN panel here:
https://www.google.com/recaptcha/admin
At which time you set the Domains to be ONLY your URL's.
Which will do what you want and make sure the form validates from your domain using both keys from server side and client side integration. If someone try's to generate the "key" using their domain recaptcha will detect it as spam.
(see the verify link above)
I'm seeking to utilize an iframe to embed some html in customers websites that will list some information from my database using a simple GET request like so:
// customer would copy/paste this code onto their site
// value of key would be unique key for that customer
<iframe src='http://mydomain.php/api?key=1234j1lj1hj124kh' ></iframe>
Now I want to be able to verify that the request is coming from customer that owns the key, and not just anybody who copy/pasted that code onto their page.
I've done some research and found that $_SERVER['HTTP_REFERRER'] can give me this information, but with mostly mixed reviews saying it isn't always reliable (and most of the questions I came across were a couple years old).
QUESTIONS
1.) Is this method of using an iframe/GET request the standard way of achieving this functionality?
2.) Is there a standard, SECURE and RELIABLE way to verify the origin of the GET request?
Unfortunately this is not possible in a secure way.
To answer your questions: In fact this is not a standard functionality itself. I mean, there is no standard secure way of allowing content to be loaded only through iframes from allowed websites.
There are three parties in this communication:
1) Your website
2) Customer website that loads your website's data in an iframe
3) End user visiting customer website
When an end user visits customer web site, he will perform a GET request to your website through the iframe. At this connection, 2nd party above (customer website) is not involved. In this case, there is no reliable way for your website to know whether this request is coming through the iframe or not. Only favor that party 2 does here is adding HTTP_REFERER header to end-user's request. But this header cannot be trusted.
For example, if I want to abuse this and show that content on my website, I can create a proxy page on my application, where I perform a back-end call to your app (adding a valid HTTP_REFERER header) and display results back.
Personally I would never use iFrames for this functionality. I am assuming that this has to be reasonably secure, which is why only your specified customer can view it? If for whatever reason you can't use PHP to embed the content you need to display (through the use of an "included" file for example), I would instead use AJAX which would still use any PHP user verification you have in place to dynamically load content into a secure webpage.
This is because your PHP user verification will (should!) use cookie/session information to determine which customer is viewing the page and therefore decide whether the content should be delivered, since Session variables are determined by a single unique code stored client-side, which match up to as much information as you want to collect about a user server-side (Which could include the last page they visited, which is what the "HTTP_REFERRER" variable would give you, if they came from another page on your website).
'$_SERVER' variables aren't reliable because they rely on the information given to them by the web browser when the request is made, and such information can easily be forged, by most people who have a basic understanding about how headers are sent.
In summary, use a NONCE (cookied), validate IP and user agent.
Steps:
When you deliver the outer frame, generate a unique identifier
(totally random, long string) and return that in a cookie with the
HTML content.
At the same time, note the IP and the user agent string you have
sent that unique identifier to, and store in a DB with the time.
When requesting the inner frame, assuming the same domain, the
cookie will come too. (If a different domain, you'll need to attach
the unique identifier as a visible string, but that's not really of
concern, just uglier)
If the user agent or IP do not match those you stored against the
unique string, or the request is too long (i.e. after an hour, or
whatever is reasonable for your application) or the unique string is used more than once
(or whatever other restrictions you place on it) then reject the
request and invalidate (delete) the unique identifier.
Not 100% foolproof, but just combine more options to make it less and less likely to be abused.
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.
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 ?