On 7 Dec 2018, at 16:44, Gregor Riepl onitake@gmail.com 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-identif... 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 swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog