> On 7 Dec 2018, at 16:44, Gregor Riepl <[email protected]> wrote:
>
>
>> And I have sniffed the traffic between my swisscom mobile Samsung
>> Mobile and my Website, but can't find any of the additional headers
>> disclosing my phone number.
This is operator specific. It might not work on Swisscom mobile for example.
Also another identifier might be there which can be translated by a service
from the operator.
Also some cheap mobile phone might leak an identifier while big brands might
not.
>
> TLS would effectively defeat any attempt at injecting headers into HTTPS
> traffic - unless the network operator controls a browser-trusted CA and uses
> it to break TLS for man-in-the-middle traffic manipulation.
>
> Also: It doesn't matter if the connection is direct or goes through a proxy.
>
>> Is there a trick to make a mobile phone disclose it's phone number
>> while connected via the mobile network's operator network?
>
> I found this, but I'm not sure if it's implemented in any common mobile
> browser: https://wiki.mozilla.org/WebAPI/MobileIdentity
>
>> How can 'website payment' operator like 'obligo' get the phone number
>> associated with a visitor? Obligo states they got the phone number
>> to bill 'from the service operator'.
>
> I suspect some network operators provide an API for obtaining subscriber
> information. You should confront your network operator if you're sure you
> didn't agree to disclosing private information via such a service.
>
> See here for an example:
> https://developer.att.com/technical-library/device-technologies/user-identification
> Seems like a legacy from the WAP age to me.
>
> I'm pretty sure that such an API would not be public, and there would be
> adequate access protection. It's possible that 'obligo' has an agreement with
> network operators to access such information.
>
>> Would it be possible, that a fraudster injects such headers from a
>> client to make obligo bill the wrong number?
>
> If the service uses a local API like MobileIdentity and the service provider
> trusts that information, then sure.
> If it uses strong transport layer security and the information is obtained via
> a secondary channel (like a provider API), then no. Well, unless the attacker
> hijacks the provider API, of course...
>
>
> _______________________________________________
> swinog mailing list
> [email protected]
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
