Jump to content

passing variables securely in URL to PHP script


wads24

Recommended Posts

I am new to PHP,  and I am trying to pass variables (bannerURL, websiteURL, & websiteNAME) in a URL on an HTML document to a php script that will show. I have done some reading on the php.net site and saw some comments that GET is not secure here:  http://php.net/manual/en/reserved.variables.get.php

<?php
echo '. htmlspecialchars($_GET["bannerURL"]) . '!';

echo '. htmlspecialchars($_GET["websiteURL"]) . '!';

echo '. htmlspecialchars($_GET["websiteNAME"]) . '!';
?>

Would this be the correct and secure?

I would appreciate some guidance. 

Link to comment
Share on other sites

Why not send through a POST request instead?

As for the secure part of your question -- Is there anything sensitive in those variables?  If it is something the user shouldn't see, then GET or POST wouldn't be the best option.  Instead, you should have a database of these urls, each with their own unique identifier.  Then, you would pass those unique identifiers in the URL, or through POST.

Link to comment
Share on other sites

No, I used to have a Miva script that I would pass variables in a link for visitors to get html to share certain banners.  So,  I would list out banners for my websites, and they would click on the banner to go to the .mv page that would pass the banner img src, my website url, and the website name.  My new webhost doesn't support Miva on shared platforms, and so I need to change the Miva page to PHP.  I am just better with Miva because I have worked with it for years.  Complete newbie to PHP though...

I just read that post, and it mentioned security vulnerabilities with the _GET function.   So, I just wanted to make sure that I wasn't opening myself up for attacks or hacks with just such a simple php script.

Link to comment
Share on other sites

For Example:

Banner Link Here

The link then would take the visitor to a Miva Page that would input the variables to for them to be able to copy the html to share the the banner  on their website.

<!-- Start &[websiteNAME] Banner -->
<p align="center" style="margin-top: 0; margin-bottom: 0"><a onMouseOver="status='&[websiteNAME]'; return true" onMouseOut="status='';return true" href="&[websiteURL]" target="_top"><img src="&[bannerURL]" border=0 alt="&[websiteNAME]"></a></p>
<!-- End &[websiteNAME] Banner -->

 

Link to comment
Share on other sites

GET and POST are equally unsafe. It's just that one is easier to manipulate than the other. What it means is that you have to make sure you are dealing with them safely in your code. It certainly does not mean you shouldn't use either.

If people are clicking a link to this page then it "must" be through GET. Because it's a link.

By the way, that mouseover/mouseout stuff with the status bar is... dated. It's not a good thing to do anymore. If you don't want to reveal the actual link - which would be fine, this is a banner, it's okay if the link looks weird - then do something like a short URL.

Link to comment
Share on other sites

Oh, it doesn't matter about revealing the URL for the banner image or website URL.   I am just completely new at this.  I guess I am confused by saying neither is safe...

How about?

Quote

<?php
echo htmlentities($bannerURL);
echo htmlentities($websiteURL);
echo htmlentities($websiteNAME);
?>

 

 

Link to comment
Share on other sites

"Safeness" has to do mostly with whether it can be manipulated by the user. Obviously anything in the URL (GET) can be manipulated because it's right there to see. Form data (POST) can be too, but it's more awkward to do.
All input coming from a browser is unsafe. URLs, form data, cookies, uploads, none of it can be trusted. So you have to be careful with them.

What are you asking about with that code?

Link to comment
Share on other sites

So, are you saying that I should not even pass variables in a URL at all than?  

I was wondering the if that code could be the banner.php to display the html banner code?  Since there is no GET or POST in it to be able to manipulate, or if you have a different suggest to help.  I would appreciate your expertise and guidance.

 

Thank you

Link to comment
Share on other sites

13 minutes ago, wads24 said:

So, are you saying that I should not even pass variables in a URL at all than?  

I answered that question already.

13 minutes ago, wads24 said:

I was wondering the if that code could be the banner.php to display the html banner code?

Ask again when you have actual code to demonstrate. Because what you have there is not the final result so there's no sense in talking about whether it's safe or not.

Link to comment
Share on other sites

You're welcome.

Let's see how this thread got here:

Post #1: You ask if it's okay to use GET even though it's insecure.
Post #2: Zane describes situations where it is not good to use.
Post #3: You clarify that you are not dealing with one of those situations.
Post #4: I ask about how you're using the URL.
Post #5: You say you are using the URL in links for banners, and that you heard GET is insecure.
Post #6: You give an example link with the HTML markup to generate it.
Post #7: I say it's unsafe and you have to be careful. Included in there is the statement that "it certainly does not mean you shouldn't use" GET.
Post #8: You are confused that I said it's unsafe, then post some PHP code that demonstrates htmlentities in a way that you are not going to use.
Post #9: I explain what it means to be unsafe, and ask why you posted that code.
Post #10: You believe I told you not to use GET. Then you ask if the code could display the banner without GET or POST.
Post #11: I address the "not to use GET" by saying I told you already whether to use it - that would be post #7, and I thought I stated it quite explicitly. I address the "code could display the banner" by suggesting that asking about example code is pointless if it isn't the code you're actually going to use.
Post #12: You say something sarcastic.

Now, perhaps I got snarky because I was tired of having to repeat myself that using GET is fine to use if you're safe about it.

Once again, you can use GET. Which is a variable, by the way, and not a function. (You can tell because of the leading dollar sign in "$_GET" and the distinct lack of parentheses when using it.)

Nobody ever said you couldn't.

As for the code, yes, that code is safe. But you aren't going to use that code because it's pointless to just output the two URLs and website name. You and I both know you are going to write some other code to do what you actually want done. So what I did, and will continue to do, is refuse to tell you whether that code is safe because I know for a fact that you would extrapolate what I said into some new direction and I don't know what that direction is. Maybe you'll be safe. Maybe you won't. I can't tell. So I'll reserve judgment regarding my answer until/unless you give the code you actually intend to use - or something clearly close to it.

Link to comment
Share on other sites

15 hours ago, wads24 said:

No, I used to have a Miva script that I would pass variables in a link for visitors to get html to share certain banners.  So,  I would list out banners for my websites, and they would click on the banner to go to the .mv page that would pass the banner img src, my website url, and the website name.  My new webhost doesn't support Miva on shared platforms, and so I need to change the Miva page to PHP.  I am just better with Miva because I have worked with it for years.  Complete newbie to PHP though...

I just read that post, and it mentioned security vulnerabilities with the _GET function.   So, I just wanted to make sure that I wasn't opening myself up for attacks or hacks with just such a simple php script.

A couple of things:

URL Parameters are intrinsic to the web.  It doesn't matter what the serverside language might be.

There are some rules for URL parameters which can be better understood by looking at the php manual for the urlencode function.

Quote

Returns a string in which all non-alphanumeric characters except -_. have been replaced with a percent (%) sign followed by two hex digits and spaces encoded as plus (+) signs. It is encoded the same way that the posted data from a WWW form is encoded, that is the same way as in application/x-www-form-urlencoded media type. This differs from the » RFC 3986 encoding (see rawurlencode()) in that for historical reasons, spaces are encoded as plus (+) signs.

So the issue with url parameters, aside from what urlencode solves, is that when you pass a url parameter that is itself a url with url parameters, things can get confusing.  

As far as "security" is concerned, I don't see the applicability to your situation, as it sounds like you are rendering the page with the banners and the associated urls.  If you are writing a script that accepts INPUT via url parameters, that INPUT always has security concerns in that it could be malicious, malformed or in violation of the valid parameters.  Again this is not unique to PHP,  but simply the way the web works.  You can never trust user input regardless of the source, and if your script is DESIGNED to receive input via url parameters then you need to take steps to conform/strip/convert the input as needed.  If the  source of the data is a database, or file or included source file, then any concerns regarding url parameters is unwarranted.

What might be of concern is you rendering out a url to be used by others, in a way that it is valid and will be correctly resolved by a browser to the intended target location.

Link to comment
Share on other sites

Not sure why you are concerned about a url dictating actions that your script is going to undertake.  You talk about some display that you want to occur.  Why does is is have to depend upon the url for information?  Do you actually want the users to have to know this info and supply it when they type in an address in their browser's address bar?

Can the script not make this decision for you?  You might get better answers if you simply describe the actions  you are looking to handle and not how you have decided to execute it.

And try not to be rude.  You are not the easiest to understand here.

Link to comment
Share on other sites

So, given all of the recommendations provided by everyone in this thread, we ultimately understand that you want to send URLs to PHP script that then uses those URLs to do something involving banners.  The banners part was not part of your original question.  Your question was if it was secure enough, and we all agree that it isn't secure.  Security is defined as

Quote

"the state of being free from danger or threat.". 

Sending URLs through a URL is not safe in that users can manipulate the resulting URL if they so pleased.  So, at its surface, $_GET is not secure.

Let's take these URLs for example:

http://www.website.com/?bannerURL=http://www.website.com/thebanner.html&websiteURL=http://www.website2.com/thewebsite.html&websiteName=testWebsiteName

That URL contains three URLs.  Now, if a user wanted to, they could change one of those variables with little to no effort at all.  Also, it exposes where your banners would be located.  Is that something you want the user to have access to?  Is that something that you believe could compromise your PHP script?

If it doesn't matter to you that a user can manually edit the URLs, then $_GET should be fine.  However, in the end, it depends on what exactly you want to do with those URLs.  Are you going to have them displayed for users to click?  Are you going to have them used as the source of a banner image?  What do you plan on doing with these URLs?!  That's the elephant of information in this thread that we've attempted to get from you.  What will you do with these URLs in your PHP script?

Having said that, sending complete URLs through a URL as a variable may or may not function as you want it to.  Take the following URL:

http://somesite.com/phpscript.php?urlVariable=http://anothersite.com/somescript.php?getVar=something&anotherVar=somethingelse

If you haven't noted what I did there, I'll explain it.  Notice that the urlVariable value has a URL with a query parameter.  This will break your URL and result in you not getting the proper data.  The same issue applies when you then add a second URL to the URL string.  Since there are two ? marks, the browser will interpret only up until that first ?.  The rest will not be read correctly if at all.

To answer your question about htmlspecialchars, take a look at the manual, you'll see at the very beginning:

Quote

Certain characters have special significance in HTML, and should be represented by HTML entities if they are to preserve their meanings. This function returns a string with these conversions made.

htmlspecialchars will not work because it does not convert the whole string to something useable.  htmlspecialchars will not change the extra question marks.  The best option is to use: htmlentities

$bannerURL = htmlentities($bannerURL);
$websiteURL = htmlentities($websiteURL);
$websiteName = htmlentities($websiteNAME);

This will get you the correct format for sending through a URL

 

http://website.com/myscript.php?bannerURL=$bannerURL&websiteURL=$websiteURL&websiteName=$websiteName

On the myscript.php page, you would then decode those URLs into variables for your use using html_entity_decode()

$banner = html_entity_decode($_GET['bannerURL']);

You could then use that variable appropriately.

<img src="{$banner}"/>

Now, after all of that, can you understand the insecurities involved with sending URL through URL variables?  A user could manipulate that image source very easily.  Then again, the "secure"  part of how you use these URLs depends on what you are doing with them.  We don't know.   Assuming this method is used, you will need to first validate the URL to make sure nothing malevolent was added by the user manually.  How you do that is up to you.  Do you only want to accept URLs from certain domains?  Do you want to make sure the syntax of one of the URL variables is correct?  What do you want to happen?

In any case, if you haven't grasped what we've all been talking about by now, then you should probably outsource your project.

 

 

Link to comment
Share on other sites

Here's some examples that might help illustrate the issue with encoding a url with parameters that could include a url or in fact any string using special characters like the '&'

<?php

$url = 'http://www.phpfreaks.com?foo=Hi there&bar=7323';
$title = 'Fred & Wilma Flinstone!';

$link = 'http://www.example.com?url=' . $url . '&title=' . $title;
echo "Link without encoding: $link" . PHP_EOL;

$link = htmlentities($link);
echo "Link run through htmlentities: $link" . PHP_EOL;

$link = 'http://www.example.com?url=' . urlencode($url) . '&title=' . urlencode($title);
echo "Link with variables urlencoded: $link" . PHP_EOL;
echo "Url decoded link: " . urldecode($link) . PHP_EOL;

$link = 'http://www.example.com?url=' . urlencode(htmlentities($url)) . '&title=' . urlencode(htmlentities($title));
echo "Link with variables urlencoded: $link" . PHP_EOL;
echo "Url decoded link: " . urldecode($link);

Results:

Quote

Link without encoding: http://www.example.com?url=http://www.phpfreaks.com?foo=Hi there&bar=7323&title=Fred & Wilma Flinstone!

Link run through htmlentities: http://www.example.com?url=http://www.phpfreaks.com?foo=Hi there&amp;bar=7323&amp;title=Fred &amp; Wilma Flinstone!

Link with variables urlencoded: http://www.example.com?url=http%3A%2F%2Fwww.phpfreaks.com%3Ffoo%3DHi+there%26bar%3D7323&title=Fred+%26+Wilma+Flinstone!

Url decoded link: http://www.example.com?url=http://www.phpfreaks.com?foo=Hi there&bar=7323&title=Fred & Wilma Flinstone!

Link with variables urlencoded: http://www.example.com?url=http%3A%2F%2Fwww.phpfreaks.com%3Ffoo%3DHi+there%26amp%3Bbar%3D7323&title=Fred+%26amp%3B+Wilma+Flinstone!

Url decoded link: http://www.example.com?url=http://www.phpfreaks.com?foo=Hi there&amp;bar=7323&title=Fred &amp; Wilma Flinstone!

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.