<< I know there aren't many php people here, but I wonder how I could reverse the encryption that Alexza was suggesting in php so I could read the encrypted data that's being passed. >>

Don't try to do your own form of encryption.  Just use TLS connections (https) and you'll have everything that you need to keep your data secure.

Tim Young
Elevate Software
www.elevatesoft.com

>Tim Young [Elevate Software] wrote:

>Don't try to do your own form of encryption.  Just use TLS connections (https) and you'll have everything that you >need to keep your data secure.

I want to make sure I understand. If I were to use HTTPS then the url displayed in the browser via the method that Raul was suggesting to look at in Chrome, would NOT be visible??

However the URL in my code still would be able to be seen unless I can obfuscate it in some manner, correct?

If that's all true, then I'm fine.

Big Al

On 7/12/2017 8:49 AM, Big Al wrote:
> I want to make sure I understand. If I were to use HTTPS then the url displayed in the browser via the method that Raul was suggesting to look at in Chrome, would NOT be visible??

No. Using TLS would prevent anybody else from seeing your URLs.

User running your app can still see these URLs thru the browser debug tools.

There is no way i'm aware of preventing this.

You need to design your web service in such a way that knowing all the
URLs and parameters does not by itself introduce any vulnerabilities
(i.e. web service should authenticate requests etc).

Raul

>Tim Young [Elevate Software] wrote:

>Don't try to do your own form of encryption.  Just use TLS connections (https) and you'll have everything that you >need to keep your data secure.

I can confirm that even under SSL, the url for the web service is found in the Chrome F12 scenario.

So the web service URL is still very much exposed.

The data coming back from the web service  may be encrypted but the url for the web service is not.

Big Al

>Big Al wrote:

>>I can confirm that even under SSL, the url for the web service is found in the Chrome F12 scenario.

Unless I'm doing something wrong. I will continue to work on testing this.

Big Al

Big Al wrote:

> So the web service URL is still very much exposed.

And will always be. You cannot stop it. But does it matter? You are presenting it to the user in the browser. They could "hack" it and get it in another form. Does that matter? Why?

--

Matthew Jones

>>"Matthew Jones" wrote:


>>And will always be. You cannot stop it. But does it matter? You are presenting it to the user in the browser. They >>could "hack" it and get it in another form. Does that matter? Why?

The webservice data that is being returned is user/client specific so it's not data that should be available to anyone.

I still am thinking that if the url data (parms) were encrypted and probably some form of authorization is the only way it's going to be foolproof.

I'm open to whatever makes sense, but I will need some sort of solution I believe for security.

Big Al

<< The webservice data that is being returned is user/client specific so it's not data that should be available to anyone. >>

Yes, which is why you need to make sure that users cannot retrieve/view data that they are not supposed to see.  This type of exploit is called "service enumeration", and involves just trying various combinations of URL parameters to see if the web service will spit out information for users other than the one that the information belongs to.

The default database layer in EWB cannot protect against this unless the user credentials being used are *also* properly implemented in the user security layer provided by the database.  If this is not the case (or possible), then you should use a back-end web server module to implement your web service and *not* rely on the user security layer in the database.

<< I still am thinking that if the url data (parms) were encrypted and probably some form of authorization is the only way it's going to be foolproof. >>

No, don't do that.  It's just trying to cover up something that is essentially an issue on the back end.

<< I'm open to whatever makes sense, but I will need some sort of solution I believe for security. >>

Raul is 100% correct: https combined with authentication on every request is the ticket.  Nothing else will work, or be as simple to implement.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>>Raul is 100% correct: https combined with authentication on every request is the ticket.  Nothing else will work, >>or be as simple to implement.

Thanks everyone for your input.

Sounds like the right way to do it is with some sort of authentication in the web service. Just have to figure out what to do and how to do it.

My SSL is setup so that's done.

Big Al

I'm not a Delphi programmer, or at least I haven't use it in years. I know 10% of what you guys know. I understand that. I chose EWB because looked exactly like what I was looking for, and with everyone's help here, I have made great strides with what I'm wanting to do with my site. It's working well for me other than this web service issue.

I know rather than using a web service, that the EWB Web Server can be extended with Delphi. I know Tim doesn't want me to go down that road because I may ask too many questions and he has a lot of other things going on, and I perfectly respect that.

Do people that use the EWB Web Server and extend it via Delphi still have the same issue with authentication??

I am perfectly happy (well not really, but I will) to purchase Delphi if that's the answer. I suspect there are some changes in the future with the EWB server, but I really need to understand how I can create a secure application.

Tim and everyone here has been patient with me and helped me to understand the parts of things that I for sure don't understand, and I appreciate it very much. I just want a way to build a webapp/website that is secure and is as fast as possible. I'm a SQL guy, so I speak SQL much better than Object Pascal and Web. I freely admit that.

Big Al