Hello All,
I have a question with regard to how can I block the requests from the mobile webview on my server side. In Android, requests from WebViews get a header HTTP_X_REQUESTED_WITH which is set to the package name of the application. Although this can be overridden, so it would be possible to hide to the server that we are making request using a WebView. I don't know any other default way to make this.
Any recommendation ?
please read this article Amir Sharif
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
Moataz Samy thanks for sharing this article. I already read the aforementioned article, which described the movement from the Webview to External Browser/ Custom Tab. I know what is the story behind of the movement, what I asked is more about the technology that could be used to detect if the request is coming from the webview to deny it on the server side.
simple block contacts from android and enable your security firewalls as well.
Adnan Majeed , I don't want to fully block all requests from the android devices, what I need to do is to check if the request is coming from the Android embedded web view, if the App on the phone is using the External Browser or Custom-Tab, it is fine.
Amir Sharif dear you can used the internal software of your android device , even you can download third party software from google play store.
Adnan Majeed dear maybe I am not clear with what I mean. I am very curious about the techniques that are used by facebook and Google that block the HTTP requests from the Android webview in Single Sign-On procedure as it is mentioned for google very briefly here:
https://stackoverflow.com/questions/41801836/how-can-google-detect-a-request-is-from-a-webview
but as it is mentioned in the answers, these are probably some guesses.
Amir Sharif dear its internal google security barriers . in Android development you can borrow google API to secure your applications
When requesting pages, webviews send User-Agent headers, just like regular browsers. The User-Agent string can be changed by the app. This is important, because it means we can differentiate between the webview traffic and browser traffic, and between the webview traffic from different apps.
Shanmuganathan Chandrasekaran , Yes, that is true, but a developer can intentionally change the User-Agent script to fool the server side in order to bypass some restrictions. so, In general I was wondered about possible countermeasures, but by the way I got the answer from the OAuth WG that I enclosed it to this comment:
"All methods can be bypassed by an attacker that has control of the app in question, it’s just a matter of effort. I believe many AS’s use client side javascript to provide a harder to bypass implementation.
Your aim here is probably mainly to prevent naive developers “accidentally” (or with good but misplaced intentions) using an embedded user agent.
In general the real state of the art would be for the party that owns the AS to have an associated first-party native mobile app, as that improves the user experience and greatly reduces the associated risks. I wrote about the pattern for doing this here:
https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authorisation.html
That said all the choices and risks here are very complex and interact with each other - from the information given I definitely can’t say whether app2app is a good approach in your use case."
- Badges
- Science topic
- Similar topics
- Filing