I'm developing an app in which i need to fetch the URL's that are accessed by the user. I've successfully fetched the URL's from android's default browser. I know that some browsers are protective towards this act. But i need to know whether there's any work around that could succeed this objective. Mainly from opera and dolphin browser
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I want to create a captive portal, first for a Windows hotspot, then for mobile-hotspots and all wifi-networks in general. So I want to understand how captive portals work under the hood, then how can I develop one in Java. I know Java socket programming
What is a captive portal?
It's an authentication screen is displayed when a wireless client isn't authorized to access the network resources. The authentication page is called a captive portal login.
A Captive Portal can be triggered on the client device in 2 ways
DNS Redirection
Splash page
DNS redirection works as the simple DNS hijacking where all the user DNS requests are hijacked and resolved to the captive portal login page. But, after widespread use of HSTS header implementation, DNS redirection hits a low success ratio providing no better service to the users.
Whereas, a Splash Page works in a little different fashion. It also uses DNS redirections but, it responds to the requests acc. to the operating systems which trick the O.S in believing there is a captive portal login in place and forcing the O.S to automatically trigger the login page to the user.
What is the splash page?
When a client device is connected to the WiFi, If unauthorized to access the Internet, A screen automatically pops up to display the captive portal.
A Splash page not only bypasses HSTS implementations on most websites but also gives you the flexibility of showing O.S specific login pages.
The only difference in the regular captive portal and splash page is that the splash page pulls up the captive portal login page automatically. Whereas, the DNS redirection based method requires a user to manually open up a website.
Imagine if a user is using a mobile app only, how would a user know he needs to log in? If you are a hacker you will lose your victim because the device will automatically disconnect upon no Internet access. So, this leads us to the much better and flexible option for triggering the captive portal login page, the Splash Screen.
As a business operator, you can show different kinds of services to different client devices, whereas as an attacker you can identify victim machines automatically and serve the payload accordingly. I’ll showcase its crux, and leave implementation upon your creativity and requirement.
Different Client Behaviours:
Every operating system has its own different way of detecting Internet access.
The mechanism is this basically:
GET/POST http://foo.ir/bar.html
If bar.html == [expected content] > Open Internet
If bar.html != [expected content] > Captive Portal
If bar.html[status] != SUCCESS > No Network
If a Captive Portal is not in place, the result will match the expected one and the OS will know that there is full access to the Internet.
If the URL returns a result other than the expected one, then the OS will detect that there is a Captive Portal in place and that it’s needed to proceed with authentication in order to get full access to the Internet: In this case, the OS will open the Splash Page automatically.
All client devices use the above-described strategy to find out if they are behind a captive portal, but the URL might vary depending on the specific model of smartphone, tablet, laptop and depending on the specific OS version. In the following, you can find the list of domains that are contacted by each model in order to detect the captive portal.
Each device, also Android different manufactures, behaves differently. For example, look at this list:
xperia z5:
connectivitycheck.gstatic.com:80
clients3.google.com:80
---------------------
galaxy j3 2016:
172.217.21.14:80
connectivitycheck.android.com
---------------------
galaxy j7 2015:
172.16.98.10:80
connectivitycheck.gstatic.com:80
---------------------
galaxy note4:
nothing!
---------------------
ios 11:
captive.apple.com/hotspot-detect.html
---------------------
windows 10:
www.msftconnecttest.com
This list show my tests on different devices. However, different versions of android devices, Windows operating systems, iOS versions, would be different on your tests, in this case.
Source
I am trying to implement app links into my app to make sure that other malicious apps cannot register for my URL.
I read the guide on app links here https://developer.android.com/training/app-links/verify-site-associations.html and I have mostly understood it. But one thing which is not clear to me is how can I prevent malicious apps from receiving my domain links if my app is not installed.
Consider this scenario.
1. My app is not installed on the user's device
2. Some malicious app is and it knows the URL that my app handles
Wouldn't this launch the malicious app and it can intercept my URL if the user selects that app from the disambiguation dialog? Is there any way to prevent it?
I understand that android:autoVerify="true" will trigger the domain verification when the app is installed, but what if the app is not installed?
Whether the user has the app installed or not, the "illegal" app won't be able to handle your links since it has not access to your domain in order to save there the needed JSON file. Am I clear?
There is a JSON file that is required during App Link configuration, that has to be uploaded to your server (that includes your app ID), through which your web-app basically says to the Android OS 'this is my counterpart on Android devices, I authorise it to handle these URLs'. Since app IDs are unique, there is no way another app can meet those conditions.
To quote the docs:
An Android App Link is a deep link based on your website URL that has
been verified to belong to your website.
So, although an app may register an <intent-filter> it ALSO has to be verified by the website whose URL it's trying to handle. And this happens on the server, so, out of the reach of a mobile client.
See also HERE for a more detailed explanation.
Is there any way to detect which browsers are installed on customer's machine after customers clicks on a URL. Usecase is below :
We are hosting a redirect server and URL for this redirect server would be provided to customers. On click of this URL , as customer lands on the redirect server servlet, we will fetch his user agent and detect from which browser he is coming. But if the browser he is using is an unsupported version for our application , I want to detect if he has any other supported browser versions installed on his machine and open that URL in that browser.
I am aware that this is something we can not do server side but is this something we can do on client side may be by using JS or something ?
Let me know. Thanks!
This is not going to be possible in the general case; JavaScript APIs are sandboxed to prevent malicious scripts from stealing confidential information from clients. You could theoretically make this work with some sort of client-side plugin, such as a Java applet, but such an approach would be very platform-dependent and almost certainly not worth the trouble.
You can only detect the browser being used, not the browsers installed. Detecting the browsers installed would require the ability to snoop on the user's machine and look through their files. What browser do you think is going to implement such functionality to allow you to do that? None, unless they want to get sued into oblivion.
In a servlet I'm running on GAE, I'm trying to get the screen width in pixels of the device being used so that I can dynamically redirect the user to either the desktop or mobile jsp page. I first tried using the java.awt.Toolkit.getDefaultToolkit().getScreenSize() but receieved the error message: java.awt.Toolkit is not supported by Google App Engine's Java runtime environment. For now, I'm running the screen check in a jsp page using javascript but I'd like to move it to the servlets.
You can't move it to the servlets. The server is not aware of the user's screen or any details besides user-agent and what Javascript provides. You'll need to use Javascript and pass around the screen size in a cookie or in the requests.
java.awt.Toolkit.getDefaultToolkit().getScreenSize()
being run on GAE is not applicable as we don't care about GAE's screen which is nonexistent anyway.
I'm remote controlling a Java application on a PC through an Android phone, and I needed my application to open a browser at the phones command, chrome in this case. I created a "Process" for chrome, opening a certain address. However, I need to be able to give tools on the Android phone for controlling the web page, such as scrolling. Can I programmatically send a command for chrome to scroll from my PC application containing the Process?
Sorry, it may have been unclear, but the only connection the android phone has to the program is through a socket. It is only used as a remote control for another Java application on a PC, which has its own screen.
I do not think that clean solution exists.
But I can suggest the following directions:
(1) try to investigate the native chrome API. If it has such ability call it with JNI.
(2) Try to use class java.awt.Robot. It allows to simulate user's activity, e.g. mouse clicks. Unfortunately it does not allow you to find any window outside your application, so it is a problem to decide where to perform the click.
(3) You can create proxy server and make browser you open to go to the target URL through the proxy. The proxy server will insert into the page your javascript that will communicate with server. The application that opens browser will send commands to server. The javascript that you inserted will receive these commands using AJAX and perform them. JavaScript can scroll browser window, so theoretically you can implement this.
If you can target the tab you want to control and edit the address bar you could send the command 'javascript:scrollTo(x, y)'. I just tested it on this page and it seems to work fine, replacing what I typed with the original address of the page.
Can I programmatically send a command for chrome to scroll from my PC
application containing the Process?
Not directly. What you could do is make some sort of web service that sits between the Android client and page that the Android client can send commands to and the page can periodically poll via AJAX calls to see what the client wants. That would be a clean DIY way that would work on other browsers besides Chrome.
You can use vnc viewer applications for that.
http://code.google.com/p/android-vnc-viewer/