The WHATWG URL parsing algorithm [1] used by browsers says that for
"special" URL schemes (which is basically all commonly-used
hierarchical schemes, including http, https, ftp, and file), the host
portion ends if a \ character is seen, whereas this class previously
continued to consider characters part of the hostname. This meant
that a malicious URL could be seen as having a "safe" host when viewed
by an app but navigate to a different host when passed to a browser.
[1] https://url.spec.whatwg.org/#host-state
Bug: 71360761
Test: vogar frameworks/base/core/tests/coretests/src/android/net/UriTest.java (on NYC branch)
Test: cts -m CtsNetTestCases (on NYC branch)
Change-Id: Id53f7054d1be8d59bbcc7e219159e59a2425106e
Malformed authority segments can currently cause the parser to produce
a hostname that doesn't match the hostname produced by the WHATWG URL
parsing algorithm* used by browsers, which means that a URL could be seen
as having a "safe" host when checked by an Android app but actually visit
a different host when passed to a browser. The WHATWG URL parsing
algorithm always produces a hostname based on the last @ in the authority
segment, so we do the same.
* https://url.spec.whatwg.org/#authority-state resets the "buffer", which
is being used to build up the host name, each time an @ is found, so it
has the effect of using the content between the final @ and the end
of the authority section as the hostname.
Bug: 68341964
Test: vogar android.net.UriTest (on NYC branch)
Test: cts -m CtsNetTestCases (on NYC branch)
Change-Id: Idca79f35a886de042c94d6ab66787c2e98ac8376
The URL path could contain credentials that apps don't want exposed
to a potentially malicious PAC script.
Bug: 27593919
Change-Id: I4bb0362fc91f70ad47c4c7453d77d6f9a1e8eeed
This fixes the crash that occurs when getAllValidScorers() is invoked by
a non-primary user when a scorer is active.
BUG: 23040221
Change-Id: I42c9e18d74389be3191258ca5626f2c433ca7cc7
(cherry picked from commit 5b294b45d0)
This fixes the crash that occurs when getAllValidScorers() is invoked by
a non-primary user when a scorer is active.
BUG: 23040221
Change-Id: I42c9e18d74389be3191258ca5626f2c433ca7cc7
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
In rare cases, we might have created a network policy before an IMSI
was available. Because this policy is persisted, and we incorrectly
think that it always applies, we end up annoying the user when data
usage goes over the 2GB default warning threshold.
This patch fixes the network matching logic to ignore these empty
network policies when present.
Bug: 24972775
Change-Id: Id26499b6716121dddf0f2c05b848b0bed5995e72
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
getActiveNetworkInfo() and friends already know how to augment their
results to help apps detect when network access is blocked. This
change wires up the new app-idle and device-idle firewall rules to
be reported through these APIs.
This also causes other platform tools like DownloadManager and
SyncManager to respect these new policies.
Bug: 24050462
Change-Id: Id9517b0b70be7e3ca2ab27bed8049db916e4d829
* commit '017223acda5bfe16cb87d0a33d72dd28d2fccd3b':
Require the new PACKET_KEEPALIVE_OFFLOAD permission.
Add an error code for generic hardware error.
Fix bugs and crashes in PacketKeepalive API.
Add tests for the PacketKeepalive API.
Add a PACKET_KEEPALIVE_OFFLOAD permission.
Use a CountDownLatch instead of sleep() in NetworkFactory tests.
Get rid of shortSleep() in ConnectivityServiceTest.
Make ConnectivityServiceTest a bit more readable.
This is necessary because currently the wifi code just returns
whatever hardware-specific integer it gets back from the HAL,
which is bad because that will be interpreted by the caller as
one of the error codes defined in this class.
In parallel we'll also modify the wifi code to return this new
error code if the hardware returns an error.
Bug: 21405946
Change-Id: Ic9fa1193ced69a4e7ff543e397221c89b10a5a13
