Hi,

I am developing a mobile app and need to have PHP webservice for it to return JSON result.

If I am going to make the service and copy it on my host then connect to it then I will achieve what I want but how about the security of the webservice? and how can I make sure it won't be indexed in Google and also how can I make sure no one will be able to access it with a kind of security?

Kindly advise...

Thanks,
Jassim

    jrahma;11059239 wrote:

    Hi,

    I am developing a mobile app and need to have PHP webservice for it to return JSON result.

    If I am going to make the service and copy it on my host then connect to it then I will achieve what I want but how about the security of the webservice? and how can I make sure it won't be indexed in Google and also how can I make sure no one will be able to access it with a kind of security?

    Kindly advise...

    Thanks,
    Jassim

    1. I am not a security expert, and I don't play one on Television/the Internet, so take this advice as a general thought, not a recommendation, requirement, or professional advice.

    2. I am not known as the "brightest star in the PHPBuilder sky" either, so keep that in mind as you read this.

    That being said, here are some thoughts. First, secure transport (HTTPS/TLS/SSL) should be used so that any communications intercepted would be harder to read/decipher. Next, you need a shared secret token, known both to your app and to your server and no one else. It should probably be pseudo-randomized, so that repeated requests intercepted and deciphered would still leave some questions as to how to fake a request. This token would be transmitted either by GET or POST to your PHP endpoint.

    The token should use an encryption function that has a known result, so that the mobile app can produce a valid token that can be verified by the PHP endpoint before allowing JSON to be sent.

    Just by way of example, using md5() --- which is probably not a recommended cipher (and technically isn't a cipher at all, but you should get the idea ... It would probably be best to use LibSodium from the PECL, or openssl_encrypt() and openssl_decrypt(), as it's my understanding that mcrypt is no longer recommended), but here is the basic idea:

    
//app code
$token = md5($some_string_of_moderate_length . $some_computed_variable_like_a_timestamp);

$url = "https://myphpendoint.com/script?token=$token";  // using GET for simplicity in example, could use POST

// app gets JSON



//server code

$check_token = md5($same_string_as_the_app . $same_computed_variable_like_a_timestamp);

//note that timestamps will differ with geography, so you might need to use some other variable, or a UTC timestamp

if ($_GET['token'] == $check_token) {
    //send JSON
} else {
   header("HTTP/1.0 403 Forbidden");
   exit;
}

      Off topic but...

      dalecosp;11059255 wrote:

      2. I am not known as the "brightest star in the PHPBuilder sky" either, so keep that in mind as you read this.

      I consider you one of the brighter members of our fair community. Have a good day!

        Derokorian;11059261 wrote:

        Off topic but...

        I consider you one of the brighter members of our fair community. Have a good day!

        Well, thankies! I write better English than I do PHP, I'm afraid. But I've been doing it a long time and I do get by. I just look at the understanding some people 'round here have and consider my first area of training was unrelated to comp. sci, so I will gladly defer to one of several of us with a greater genius if and when they wish to post....

          dalecosp;11059279 wrote:

          ...I just look at the understanding some people 'round here have and consider my first area of training was unrelated to comp. sci,...

          Music Education major here. I sometimes feel stupid around some of the people I work with, but fortunately now have 5 years of experience here, allowing my subject matter expertise to compensate for my (comparative) technical mediocrity. 🙂

            :glare: All I have to say to the both of you.

            Also wouldn't be better than MD5?

            base64_encode()

              Also wouldn't be better than MD5?

              base64_encode()

              [/QUOTE]

              base64_encode() is easily reversed via the decode method, so by itself would not truly be hashing or encrypting. If the result of a hash does not look the way you want it to, you could base64_encode() that to get a nice combination of A-Za-z0-9 and whatever the couple of special characters are that it uses. But if being able to decode the string doesn't matter, then it could be fine.

              Also, the result of a hash will always be the same length (for a given hashing algorithm), in case that matters -- though of course you could substr() anything to truncate it to a desired length, but again, depending on what the exact purpose is, how secure/unique it needs to be, etc., the "best" solution here might still be up in the air (like there is ever a single "best" solution to such things?).

                NogDog;11059289 wrote:

                base64_encode() is easily reversed via the decode method, so by itself would not truly be hashing or encrypting. If the result of a hash does not look the way you want it to, you could base64_encode() that to get a nice combination of A-Za-z0-9 and whatever the couple of special characters are that it uses. But if being able to decode the string doesn't matter, then it could be fine.

                Also, the result of a hash will always be the same length (for a given hashing algorithm), in case that matters -- though of course you could substr() anything to truncate it to a desired length, but again, depending on what the exact purpose is, how secure/unique it needs to be, etc., the "best" solution here might still be up in the air (like there is ever a single "best" solution to such things?).

                Ah ok didn't know that, my lesson of the day

                  11 days later
                  dalecosp;11059255 wrote:

                  2. I am not known as the "brightest star in the PHPBuilder sky" either, so keep that in mind as you read this.

                  We can't all be laserlight or weedpacket (or nogdog or derokorian or...oh nevermind). You do just fine. 😃

                  Dalecosp is correct that HTTPS is usually sufficient to protect the privacy of communications between a client (i.e., a web app) and a server. More specifically, this kind of communication protocol means that all the packets exchanged between a web server application (or mail server or ssh server or whatever) and the client browser/mail client/ssh client should be extremely difficult, if not impossible to spy on. That doesn't necessarily mean that your web app is "secure." One of your users might email a link they requested via HTTPS to a friend (and the email gets snooped by a bad guy) or one of your users might tweet "hey lol if you wanna use my app go to https://example.com rofl." What I mean to say is that just hosting your web app via HTTPS/TSL/SSL is just a starting point. Think of it as a secure, private line that anybody can call.

                  Above and beyond using HTTPS/TSL/SSL, most applications require you to authenticate each user who may show up separately -- i.e., you identify each of your users separately and grant them access to the stuff they need. This usually involves prompting them for a login ID (either a username or password) and a password. It can be made more secure if you use key pairs or something like that. This would be analogous to answering the private line I mentioned above and forcing each person to identify themselves by name and provide some secret answer (or use voice recognition?) to identify them uniquely. It's important to note that you would never want anyone to mention their password or sensitive credentials unless they were speaking to you on a secure, private line. Think of it this way. If you are a bank and Alice calls and ask for Bob's information, should you give Alice his information? You really need to know who you are talking to before you start doing stuff for visitors.

                  Once someone has contacted you securely via HTTPS/TSL/SSL and authenticated with an ID or password, you can have your server generate a session ID and send this to the client so the client can identify themselves. Think of it like a ticket stub that can be used to locate someone's account. Like a coat check clerk at a fancy restaurant, your server needs to take care of tracking which coat (or which session) belongs to which customer (or authenticated user). PHP has features to support sessions which can be very helpful.

                  jrahma;11059239 wrote:

                  Hi,
                  If I am going to make the service and copy it on my host then connect to it then I will achieve what I want but how about the security of the webservice? and how can I make sure it won't be indexed in Google and also how can I make sure no one will be able to access it with a kind of security?

                  If you want to politely ask web servers from crawling your web service, you can use a robots.txt file like this:

                  User-agent: *
Disallow: /

                  Keep in mind that every web crawler can rudely ignore that request and to try crawl any url they get their hands on. These urls tend to leak out as folks email them to each other and as users post stuff on forums and make bookmarks and stuff.

                  If you want to know 'about the security of the webservice' then you would need to be more specific. What, exactly, do you want to know? There's security that'll keep your little sister from reading your diary, and there's security that'll prevent nation-states with multi-billion-dollar budgets from decrypting your nuclear codes -- the cost to implement each is extremely different. Chances are that there are some common practices that will do what you want, but you'll have to decide for yourself what is "secure enough."

                    Write a Reply...