Icon View Thread

The following is the text of the current message along with any replies.
Messages 21 to 25 of 25 total
Thread Obfuscate JS output
Wed, Jul 12 2017 9:06 PMPermanent Link

Big Al



Tim Young [Elevate Software] wrote:
>>



>>Are you using the EWB Web Server or something else ?

Tim, if I was using the ewb server is the username/password passed in the header such that it would be encrypted via ssl?

Big Al
Wed, Jul 12 2017 9:32 PMPermanent Link

Raul

Team Elevate Team Elevate

On 7/12/2017 8:02 PM, Big Al wrote:
> That's the part I'm missing.... If I pass the username/password on the URL, then a person could see it, though they would only see their own since that's the only way I believe they would have a valid username/password.
> But that exactly url could be saved and used at a later time again?? Maybe there is some way I could stop that from happening. If the URL was used to insert or update data, then running it again would insert or update data.
> Maybe I'm just not thinking it thru but that seems like that might be an issue.

Yes however assuming you use TLS now we're only talking about a valid
user of your app and only during that session (once they close the
browser all of this is generally gone).

So you have reduced your vulnerability significantly.

Even then they only get the URLs using F12 browser tools - web request
URLs in EWB app do not get saved in browser so one cannot just start the
browser later and look at history for example

Valid user of your app with full API access will always be a problem -
for this you need to make sure you limit web service API. For example
never send actual SQL commands from EWb app to server but rather write
web service so it surfaces needed operations only and keep control on
server side. Also good idea is to hide your database structure behind
api. This all depends on your app and users and could be as simple as
writing any delete/update operations to backup table first and
generating server side audit trails or lot more complex.

In terms of hiding the URL there are few simple things you can do

1. use server request headers instead of URL. It's still possible for
valid user to view these but it's more pain to use later.

2. use POST instead of GET - this is as simple as setting the
tserverrequest method to post and populating RequestContent (see
loginclient example for example). Again valid user can access this but
url is clean and they musty use browser debug tools.

3. if you were to use the idea of sessionid then that could be easily
invalidated by server after fixed time or whenever user logs out. Then
somebody would have to catch the 1 event when you got the session id
since rest of the URLs would be not usable without valid sesion. It's
still vulnerable but it's now more limited.

4. oauth2 or such would be another way to do session id - again valid
user would still be able to get in if they get the intitial user/password.

5. if you want to be super secure then send user a 1-time password thru
some other means on login (email or sms message) and have them enter
this into the app and use it as enryption password. This gets very
complex quickly though ...


> If I got a session ID, I don't really have sessioning on the web service side, but could implement something like that without too much trouble. Again, if someone grabs the URL , could they update data later if it's soon so the same session might be active?

Idea would be to use random session ids (guid for example) and really
limit lifetime - as soon as user logs out you invalidate session id on
server. You can set auto-expiry on session (x minutes) so user has to
re-authenticate or web service again just invalidates it.

There are other things you can do as well like linking session ID to
remote IP so your web service can say "this session is coming from wrong
ip now" - depends on your users and whether their IPs change during app
usage session etc

Your app has to handle all of this gracefully though.

Raul
Thu, Jul 13 2017 4:10 AMPermanent Link

Matthew Jones

Big Al wrote:

> My web service is being used to select, update, delete and insert data from my database.
>
> I need it to be secure so only my app under app control can update the database.

Not sure that you answered the question. But I've asked a better one just now, so let's stay over there...

I'll just say that fundamentally if you put a server on the internet, anyone with the correct access can talk to it. Whether they are likely to care is another matter of course. But the server needs to validate any request, and that the user is allowed to do the operation. Authentication is all. (And of course if someone can steal a login, they have it all.)

--

Matthew Jones
Thu, Jul 13 2017 5:32 AMPermanent Link

Big Al

>>"Matthew Jones" wrote:


>>I'll just say that fundamentally if you put a server on the internet, anyone with the correct access can talk to it. >>Whether they are likely to care is another matter of course. But the server needs to validate any request, and that >>the user is allowed to do the operation. Authentication is all. (And of course if someone can steal a login, they >>have it all.)

Thanks, I think I have my direction if I want to continue with the php script so I am going to set it up and see how it works.

Thanks again everyone for your input

Big Al
Thu, Jul 13 2017 11:13 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

<< Tim, if I was using the ewb server is the username/password passed in the header such that it would be encrypted via ssl? >>

Yep:

https://stackoverflow.com/questions/187655/are-https-headers-encrypted

But, again, this doesn't solve the "public computer" issue.  If a user uses your service on a public computer, then everything they do could be cached/accessed in the browser that they're using unless the browser itself is designed to clear its cache automatically on each use.

Tim Young
Elevate Software
www.elevatesoft.com
« Previous PagePage 3 of 3
Jump to Page:  1 2 3
Image