Two aspects of WebView: about quick start of projects and theft of personal data
Hello, Habr!
My name is Eugene, I'm a Full Stack JS developer, the current stack is Node.js + React + React Native. I have been in development for over 10 years. In mobile development I tried different tools from Cordova to React Native. Having gained experience with Cardova, I realized that I would like to create native interfaces, in my opinion WebView should not be the whole application. But this does not mean that it should not be used at all.
At the invitation of colleagues from Sberbank, in this post I want to talk about hybrid mobile applications. With the right approach, this is a great way to quickly implement the idea of a well-functioning product, sufficient for the first launch of your startup.
Source: srishta.com
I’ll also tell you a little about how you can use WebView and how attackers can use it against you. The examples in the article will be shown using the React Native framework, but the same ideas can be implemented without it.
I’ll start with the fundamental differences in launching startups in our country and in the West, I will tell you how WebView can help here, I will give working examples of how web and native elements interact, as well as safety tips when interacting with third-party applications.
As a rule, for a startup to become successful, it needs to start quickly. If you lose time, your competitors will bypass you. This is understood both in our country and in the West. But the Russian approach to launch, as a rule, is much more thorough - in the bad sense of the word.
All unsuccessful Russian startupsstart and develop in approximately the same scenario. The most common mistakes are related to strategic planning of software product development. The management thinks that the launch is possible only after 110% implementation of all the functionality and all the nuances. With this approach, a budget deficit quickly arises, since development costs are high, and there is no income from a startup. The search for additional investments, an endless circle of approvals and revisions takes a lot of time, the product appears at the competitor. That's it, the marathon is lost.
European and American startupsact differently. For starters, they are limited only to the mobile web version with a minimally sufficient functional part. It can be viewed from both desktops and mobile devices. And at this stage the project is ready to launch! After launch, the application is made for mobile devices.
As a rule, the application does not differ in basic features from the web version. It expands the possibilities of interaction with the user, for example, through push notifications. This approach ensures the fulfillment of the main condition - quick start, quick first profit. Revenues from the first stage can be invested in development. In the future, the project can be scaled and developed as desired without a budget deficit, endlessly performing an iterative approach to add new functionality and develop the user interface.
I propose to consider in more detail the stage when there is already a mobile version of the site and you need to develop an application for mobile devices. So, we made a site, which means we were developing the server API, interface and business logic. Two of the three components -
interface and logic - are present in the mobile application. Agree, I do not want to write them again.
There are tools focused on developing native applications. Others are for the web. The advantage of native applications is that they can use the full functional potential of the phone. But developing them compared to web applications is quite difficult. The web provides an easy start, but greatly limits the capabilities of the application.
* to reduce the tautology of web applications, I will call mobile applications, the bulk of the logic and interface of which is implemented on the browser side
Hybrid applications created using the WebView component allow combining all the advantages of native applications and the web. Of course, there are meticulous developers who are categorically against WebView in any of its manifestations. They argue this with the fact that the application should immediately be completely native, so that you can use all the features of a mobile device, as well as provide comfortable user interface performance. But in many cases, when the capabilities of the mobile version of the site are quite enough, you can reduce the time of the first launch by making a hybrid application, and gradually replace it with a native one.
Hybrid applications are not always bad and not extensible. They can be convenient and productive. With proper use, this approach helps to get enough time to develop a quality application, and not to release a native application in haste.
There are several situations in which it is advisable to use hybrid applications. They are good as a temporary stub for a quick start - when we have a mobile version of the site ready, and the mobile application was needed “yesterday”. Such an application can be created in a few hours, run in production. Users will have the opportunity to work with a mobile application, and you will have the opportunity to work on a more complete version in less tight time frames (if necessary).
Here is an example. Recently, colleagues urgently needed a mobile application. In the web version, it had eight menu items, and we displayed them through WebView. And then they replaced one item. It so happened to release the application not in a month or three, but in just a few days. After gradually transferred it to the native.
A hybrid solution is not always temporary. Its capabilities allow you to reuse in the application the code base created earlier for the web version. For example, specific animations already created on Canvas. WebView is also convenient when using some kind of third-party service. Another option is when you have a complex interface that is easier to connect via WebView.
Take a popular script. We want to use the mobile version of the site and the native menu. We create a native application with a menu, but instead of content, we connect the mobile version of the site via WebView (so far without any changes).
On the gif you can see 2 menus. The right menu is part of the site, implemented on the web, on the left is the native menu, implemented inside the mobile application. To get the first approximation to the native application, we just need to hide the menu that is implemented on the web. Here is how much code is needed to display the web version inside the application via WebView:
The next example is about how the native part can interact with the web.
The robot is drawn on Canvas, this is part of the website. And the switch to it is built on the native UI. It will look different on different phones. We can control the movements of the robot using a switch. You can and vice versa - with some elements of the web interface to influence the application. React Native provides for this a special API for interaction between the web and the native part.
Below is the code to use this animation. Layout - all the space. Picker is a native part that can select from the dropdown options for the state of the robot. WebView - a container for displaying the web, inside which a robot is drawn.
Such cases arise often. For example, we made an application for testing and certification of dentists. For each answer in the test, animation was drawn inside the questions, implemented using Canvas on the web. The challenge was to create a mobile application, with this testing. Using WebView, we were able to display animations from the web, while we built the rest of the interface natively. Animation worked fine even on older smartphones.
Until 2013, the Opera browser used its own Presto engine, but then it was transferred to the Blink engine from Google. Many users are very upset. The video “Why Opera Webkit” sheds light on the reasons for this transition . The main culprits are large corporations such as Google or Facebook, which did not test the code of their products in Opera and forbade the display of pages in this browser, citing the fact that it is not popular enough with users.
For example, you go to Gmail through Opera and you see: "JavaScript error." You write to support, you get the answer: "Opera is not supported with us, we will not write code for it." First, Opera hired developers to write injections, a special code that was embedded in Gmail and allowed it to work in Opera. But gradually sites like Gmail got bigger. Opera gave up and changed the engine.
So what am I talking about? Ah yes it's time to talk about injections:
On the gif - an example of an injection that changes the behavior of sites. Suppose we have someone else’s site, and we do an injection of styles - we hide the right menu and the slider that exits to the right. This is an injection of styles. The logic of the site does not change, only the display.
The code written in green is injection. It hides the elements, you cannot click on them, you cannot interact with them. It looks like a completely native application, without web controls.
The next injection is more interesting. Let's say we have a mobile application, and it has a built-in mobile browser.
A person follows the link, and we easily substitute him with the Facebook page in which you need to enter a username and password. If a person enters it, the application intercepts it. Here is the code :
Such code is called logic injection. Usually it is more difficult, but not much. That is, stealing a password is easier than hiding controls.
As you know, many applications have built-in browsers (WebView) - for example, VKontakte, Telegram, Gmail, WhatsApp and so on. We can trust large companies, but WebView is also used by a huge number of applications with a small number of stars and dubious authors - for example, QR readers, file managers, camera shells, etc. ... You install the application, read the code through it, click on the link, enter sensitive data - and the application, as shown in the previous example, has access to it. And then you can’t track where this data flows. Therefore, to open links, use only trusted browsers.
There are sites that request a username and password each time. And there are those who do this rarely - once a month, once a year. Oddly enough, the second option is safer in terms of data leakage through WebView. For example, you enter the site from some left browser. The site requires a username and password, and it does not seem strange to you - it always does that. And in the case when authorization is rarely required, it will make you wary.
Interestingly, two-factor authentication does not protect against such an attack - only from password theft. The fact is that after confirmation, a token is returned in response to you, which, in turn, does not already have two-factor authorization, and it is easy to intercept it. That is, if you entered the login and code from SMS once, the browser receives a token, which can be used repeatedly. With this confirmed token, he can do what he wants, for the time while the token remains relevant. In general, do not trust the built-in browsers too much.
You can get acquainted with examples from this post through demo applications. On Android OS you need to download Expo Project - a tool for working with JavaScript and React Native. After installing Expo, you only need to read the QR code:
It is more difficult with iOS devices: Applebanned distributing applications in this way. So the curious will have to build the application from the source on GitHub. Thanks for attention!
My name is Eugene, I'm a Full Stack JS developer, the current stack is Node.js + React + React Native. I have been in development for over 10 years. In mobile development I tried different tools from Cordova to React Native. Having gained experience with Cardova, I realized that I would like to create native interfaces, in my opinion WebView should not be the whole application. But this does not mean that it should not be used at all.
At the invitation of colleagues from Sberbank, in this post I want to talk about hybrid mobile applications. With the right approach, this is a great way to quickly implement the idea of a well-functioning product, sufficient for the first launch of your startup.
Source: srishta.com
I’ll also tell you a little about how you can use WebView and how attackers can use it against you. The examples in the article will be shown using the React Native framework, but the same ideas can be implemented without it.
A bit about startups
I’ll start with the fundamental differences in launching startups in our country and in the West, I will tell you how WebView can help here, I will give working examples of how web and native elements interact, as well as safety tips when interacting with third-party applications.
As a rule, for a startup to become successful, it needs to start quickly. If you lose time, your competitors will bypass you. This is understood both in our country and in the West. But the Russian approach to launch, as a rule, is much more thorough - in the bad sense of the word.
All unsuccessful Russian startupsstart and develop in approximately the same scenario. The most common mistakes are related to strategic planning of software product development. The management thinks that the launch is possible only after 110% implementation of all the functionality and all the nuances. With this approach, a budget deficit quickly arises, since development costs are high, and there is no income from a startup. The search for additional investments, an endless circle of approvals and revisions takes a lot of time, the product appears at the competitor. That's it, the marathon is lost.
European and American startupsact differently. For starters, they are limited only to the mobile web version with a minimally sufficient functional part. It can be viewed from both desktops and mobile devices. And at this stage the project is ready to launch! After launch, the application is made for mobile devices.
As a rule, the application does not differ in basic features from the web version. It expands the possibilities of interaction with the user, for example, through push notifications. This approach ensures the fulfillment of the main condition - quick start, quick first profit. Revenues from the first stage can be invested in development. In the future, the project can be scaled and developed as desired without a budget deficit, endlessly performing an iterative approach to add new functionality and develop the user interface.
I propose to consider in more detail the stage when there is already a mobile version of the site and you need to develop an application for mobile devices. So, we made a site, which means we were developing the server API, interface and business logic. Two of the three components -
interface and logic - are present in the mobile application. Agree, I do not want to write them again.
Combining the best of native and web applications
There are tools focused on developing native applications. Others are for the web. The advantage of native applications is that they can use the full functional potential of the phone. But developing them compared to web applications is quite difficult. The web provides an easy start, but greatly limits the capabilities of the application.
* to reduce the tautology of web applications, I will call mobile applications, the bulk of the logic and interface of which is implemented on the browser side
Hybrid applications created using the WebView component allow combining all the advantages of native applications and the web. Of course, there are meticulous developers who are categorically against WebView in any of its manifestations. They argue this with the fact that the application should immediately be completely native, so that you can use all the features of a mobile device, as well as provide comfortable user interface performance. But in many cases, when the capabilities of the mobile version of the site are quite enough, you can reduce the time of the first launch by making a hybrid application, and gradually replace it with a native one.
Hybrid applications are not always bad and not extensible. They can be convenient and productive. With proper use, this approach helps to get enough time to develop a quality application, and not to release a native application in haste.
There are several situations in which it is advisable to use hybrid applications. They are good as a temporary stub for a quick start - when we have a mobile version of the site ready, and the mobile application was needed “yesterday”. Such an application can be created in a few hours, run in production. Users will have the opportunity to work with a mobile application, and you will have the opportunity to work on a more complete version in less tight time frames (if necessary).
Here is an example. Recently, colleagues urgently needed a mobile application. In the web version, it had eight menu items, and we displayed them through WebView. And then they replaced one item. It so happened to release the application not in a month or three, but in just a few days. After gradually transferred it to the native.
A hybrid solution is not always temporary. Its capabilities allow you to reuse in the application the code base created earlier for the web version. For example, specific animations already created on Canvas. WebView is also convenient when using some kind of third-party service. Another option is when you have a complex interface that is easier to connect via WebView.
How to use webview
Take a popular script. We want to use the mobile version of the site and the native menu. We create a native application with a menu, but instead of content, we connect the mobile version of the site via WebView (so far without any changes).
On the gif you can see 2 menus. The right menu is part of the site, implemented on the web, on the left is the native menu, implemented inside the mobile application. To get the first approximation to the native application, we just need to hide the menu that is implemented on the web. Here is how much code is needed to display the web version inside the application via WebView:
export default (props) => (
https://provincehotels.ru/'}} style={{flex:1}} />
);The next example is about how the native part can interact with the web.
The robot is drawn on Canvas, this is part of the website. And the switch to it is built on the native UI. It will look different on different phones. We can control the movements of the robot using a switch. You can and vice versa - with some elements of the web interface to influence the application. React Native provides for this a special API for interaction between the web and the native part.
Below is the code to use this animation. Layout - all the space. Picker is a native part that can select from the dropdown options for the state of the robot. WebView - a container for displaying the web, inside which a robot is drawn.
const states = [ 'Idle', 'Walking', 'Running', 'Dance', 'Death', 'Sitting', 'Standing' ];
const uri = 'https://artexoid.ru/181212/example2/';
export default class Example2 extends React.Component {
myWebView = React.createRef();
state = {
robot: states[0]
};
render() {
return (
{
this.setState({robot: item});
this.myWebView.current.postMessage(item);
}}
>
{states.map((item => ))}
);
}
}Such cases arise often. For example, we made an application for testing and certification of dentists. For each answer in the test, animation was drawn inside the questions, implemented using Canvas on the web. The challenge was to create a mobile application, with this testing. Using WebView, we were able to display animations from the web, while we built the rest of the interface natively. Animation worked fine even on older smartphones.
How are injections made?
Until 2013, the Opera browser used its own Presto engine, but then it was transferred to the Blink engine from Google. Many users are very upset. The video “Why Opera Webkit” sheds light on the reasons for this transition . The main culprits are large corporations such as Google or Facebook, which did not test the code of their products in Opera and forbade the display of pages in this browser, citing the fact that it is not popular enough with users.
For example, you go to Gmail through Opera and you see: "JavaScript error." You write to support, you get the answer: "Opera is not supported with us, we will not write code for it." First, Opera hired developers to write injections, a special code that was embedded in Gmail and allowed it to work in Opera. But gradually sites like Gmail got bigger. Opera gave up and changed the engine.
So what am I talking about? Ah yes it's time to talk about injections:
On the gif - an example of an injection that changes the behavior of sites. Suppose we have someone else’s site, and we do an injection of styles - we hide the right menu and the slider that exits to the right. This is an injection of styles. The logic of the site does not change, only the display.
const addStyles=`
const newCSS = 'div[class*=svgHamburger],div[class*=drawerPanel] { display: none !important; }'
head = document.head || document.getElementsByTagName('head')[0],
style = document.createElement('style');
style.type = 'text/css';
style.appendChild(document.createTextNode(newCSS));
head.appendChild(style);
`;
const uri = 'https://provincehotels.ru/';
export default (props) => (
);The code written in green is injection. It hides the elements, you cannot click on them, you cannot interact with them. It looks like a completely native application, without web controls.
The next injection is more interesting. Let's say we have a mobile application, and it has a built-in mobile browser.
A person follows the link, and we easily substitute him with the Facebook page in which you need to enter a username and password. If a person enters it, the application intercepts it. Here is the code :
const addScripts=`
document
.querySelector('input[type=password]')
.addEventListener("change", (event) => alert(event.target.value));
`;
const uri = 'https://www.facebook.com/';
export default (props) => (
);Such code is called logic injection. Usually it is more difficult, but not much. That is, stealing a password is easier than hiding controls.
Minute of paranoia: browsers embedded in applications
As you know, many applications have built-in browsers (WebView) - for example, VKontakte, Telegram, Gmail, WhatsApp and so on. We can trust large companies, but WebView is also used by a huge number of applications with a small number of stars and dubious authors - for example, QR readers, file managers, camera shells, etc. ... You install the application, read the code through it, click on the link, enter sensitive data - and the application, as shown in the previous example, has access to it. And then you can’t track where this data flows. Therefore, to open links, use only trusted browsers.
There are sites that request a username and password each time. And there are those who do this rarely - once a month, once a year. Oddly enough, the second option is safer in terms of data leakage through WebView. For example, you enter the site from some left browser. The site requires a username and password, and it does not seem strange to you - it always does that. And in the case when authorization is rarely required, it will make you wary.
Interestingly, two-factor authentication does not protect against such an attack - only from password theft. The fact is that after confirmation, a token is returned in response to you, which, in turn, does not already have two-factor authorization, and it is easy to intercept it. That is, if you entered the login and code from SMS once, the browser receives a token, which can be used repeatedly. With this confirmed token, he can do what he wants, for the time while the token remains relevant. In general, do not trust the built-in browsers too much.
You can get acquainted with examples from this post through demo applications. On Android OS you need to download Expo Project - a tool for working with JavaScript and React Native. After installing Expo, you only need to read the QR code:
It is more difficult with iOS devices: Applebanned distributing applications in this way. So the curious will have to build the application from the source on GitHub. Thanks for attention!