Jump to content


Photo

User data on toggling server

login

  • Please log in to reply
11 replies to this topic

#1 EduardoSantos OFFLINE  

EduardoSantos

    Advanced Member

  • Members
  • 386 posts
  • Local time: 12:13 PM

Posted 17 October 2019 - 03:59 PM

Hi,

 

New to the AndroidTV app. Very good work, good ideas and some very beautiful screens. My regards to developers.
Is there a means to snapshot from Emby's the current screen? That would make it a lot easier to post issues here...

 

Anyway, this issue relates to the toggling server mechanism.

I do not use Emby Connect so this is about direct connections.

When toggling from one server to another the app seems to forget user data (name/password) already provided.

I have to re-enter it on each and every toggling to already known servers.

 

Also, but seems of least importance, on the toggling screen servers are presented with their name (url) but with the LAN IP address below.
This is kind of akward when some servers are remote.

I tried to set LAN parms on server configuration but it the app still shows the LAN IP.

Though that does not prevent actual connections it could be a security issue...



#2 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 47685 posts
  • Local time: 10:13 AM

Posted 18 October 2019 - 11:23 AM

Hi.  The LAN IP would only be accessible on  your LAN.  That's why we show that and not the remote one.  That is displayed only as a "clue" as to which server it is.  It is purely informational.

 

As for remembering credentials between logins, you could accomplish this with Connect or, if local, then you could not require passwords on your LAN.



#3 EduardoSantos OFFLINE  

EduardoSantos

    Advanced Member

  • Members
  • 386 posts
  • Local time: 12:13 PM

Posted 19 October 2019 - 08:02 AM

Scenario is one local server and some remote,
I understand Emby Connect could circumvent the problem and will give it a shot. 
 
Just reported as a means to get it to work on a future release.
It does not have real impact to me.
But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. Don't remember seeing this elsewhere.
 
@pir8radio may have some input.


#4 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 47685 posts
  • Local time: 10:13 AM

Posted 19 October 2019 - 10:15 AM

But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. 

 

How so?  We can consider removing it but I fear people will complain about us removing things :).



#5 EduardoSantos OFFLINE  

EduardoSantos

    Advanced Member

  • Members
  • 386 posts
  • Local time: 12:13 PM

Posted 19 October 2019 - 10:42 AM

Well...

 

For remote servers app could present just the URL and, maybe, the external valid IP below it.

 

Once this external valid IP is the real connection parm, it has an additional value to the end user as a means to check to what IP address the app resolved the URL.

To my point of view, internal routing from the external IP to the actual Emby server is server's admin responsability.

 

Humbly suggesting



#6 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 47685 posts
  • Local time: 10:13 AM

Posted 19 October 2019 - 05:20 PM

Displaying the external IP address could be a potential security risk as people post screen shots or just walk by your screen/device so that's why we show the internal one.

 

Again it is just a clue to further identify a server.  An argument can be made that it isn't really necessary (until we take it out and someone says they were using it to identify a server :)).



#7 pir8radio OFFLINE  

pir8radio

    NGINX

  • Members
  • 2927 posts
  • Local time: 09:13 AM
  • LocationChicago

Posted 20 October 2019 - 01:48 PM

 

Scenario is one local server and some remote,
I understand Emby Connect could circumvent the problem and will give it a shot. 
 
Just reported as a means to get it to work on a future release.
It does not have real impact to me.
But I must say exposing an internal/invalid remote address on another LAN really seems a security issue. Don't remember seeing this elsewhere.
 
@pir8radio may have some input.

 

 

 

Guess I don't follow the issue...   When you list the "remote" servers in the android app it shows the LAN ip of the remote server?     Pretty sure you can bind the server to 127.0.0.1 and it will hide the LAN address from the remote clients.       But exposing a LAN address isn't really a security issue unless they can get through your firewall, but then a quick scan will show all of the LAN addresses in that case anyway.      You are more than welcome to test my server on your android device, just click my avatar.     See what "lan" ip you see....   you shouldn't see one.  

 

You can test by going to your server ip/domain name    yourserver.com/emby/system/info/public



#8 EduardoSantos OFFLINE  

EduardoSantos

    Advanced Member

  • Members
  • 386 posts
  • Local time: 12:13 PM

Posted 21 October 2019 - 01:38 PM

Well, I did not know that "yourserver.com/emby/system/info/public" would provide specific info on internal IP addressing.

 

That seems very awkward to my understanding of security policies and I agree exposing it on the interface will bring no additional harm.

 

I really though all internal re-routing from incoming packages should rely on router and it's NAT policies.

Binding to 127.0.0.1 seems a very good practice but it will only circumvent a security weakness that should not exist.

 

I may be wrong on considering exposure of an internal IP to be a risk. I will try to learn more on this.



#9 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 140578 posts
  • Local time: 10:13 AM

Posted 21 October 2019 - 01:53 PM

We'll eventually be removing that information, but keep in mind, you have to already know the address to get there in the first place.



#10 EduardoSantos OFFLINE  

EduardoSantos

    Advanced Member

  • Members
  • 386 posts
  • Local time: 12:13 PM

Posted 21 October 2019 - 04:33 PM

We'll eventually be removing that information, but keep in mind, you have to already know the address to get there in the first place.

 

Sorry but that does not seem to be true.
This info is about internal LAN addressing.

 

External app does not need to know it in order to connect to the server.

It will connect using just server's port and the URL/name (or external valid IP).

As promised I will gather info on this but now it really seems a big risk exposure.

Never heard about a server publicizing it's internal LAN IP address.



#11 pir8radio OFFLINE  

pir8radio

    NGINX

  • Members
  • 2927 posts
  • Local time: 09:13 AM
  • LocationChicago

Posted 21 October 2019 - 10:05 PM

Sorry but that does not seem to be true.
This info is about internal LAN addressing.

 

External app does not need to know it in order to connect to the server.

It will connect using just server's port and the URL/name (or external valid IP).

As promised I will gather info on this but now it really seems a big risk exposure.

Never heard about a server publicizing it's internal LAN IP address.

 

 

I still dont think its a security risk, there are only so many lan subnets, and if you were in a position to reach any of them a quick scan would show all of the active addresses...      Like I know your server is either in 192.168.x.x  10.x.x.x or 172.x.x.x   a quick scan of those three networks will populate your network.     

 

anyway i think the original use for the /public is to allow any connecting app, no matter how its attempting to connect, to try the local address first to see if its reachable so that you can stream without transcoding using less server resources.     

 

THIS IS REALLY NO BIG DEAL IF YOU HAVE A FIREWALL...   YOUR CURRENT BROWSER PROBABLY GIVES OUT YOUR LOCAL LAN ADDRESS:  https://www.whatismy...ocal-ip-address



#12 ebr ONLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 47685 posts
  • Local time: 10:13 AM

Posted 22 October 2019 - 09:16 AM

It isn't a security risk but, since it can appear to be, we will just remove it.

 

Thanks.







Also tagged with one or more of these keywords: login

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users