3 ms·

> There are just some things that a web browser should not do. Exposing things that previously required escape from sandbox attacks is one of them. Why is it a

by untog 11y ago

> There are just some things that a web browser should not do. Exposing things that previously required escape from sandbox attacks is one of them. Why is it any different from an app doing it, though? There will be the same permission prompts etc.

kec 11y ago
I visit far more websites in a day than I use strange new apps. Apps also don't suffer from XSS.
- Guvante 11y ago
  > I visit far more websites in a day than I use strange new apps. From the article you have to "install" the web application for any of these features to be available. > Apps also don't suffer from XSS. From websites sure, but they do from other apps.
  - ryao 11y ago
    > From the article you have to "install" the web application for any of these features to be available. As far as the article is concerned, rendering a webpage as if it were an app takes away functionality (mainly, the ability to interact with the address bar). It does not discuss the security of web 2.0 features and it certainly does not claim that these features are only available when the webpage is pretending to be an app. > From websites sure, but they do from other apps. iOS uses capsiculum to isolate applications while Android uses SELinux. They aren't executing each others' code.
    - Guvante 11y ago
      > iOS uses capsiculum to isolate applications while Android uses SELinux. They aren't executing each others' code. XSS isn't about executing other people's code, it is about performing commands that you shouldn't be performing. There are a ton of instances in the pass where cross application communications have lead to privilege escalation in the same way that XSS does.
- intrasight 11y ago
  Apps suffer from MUCH bigger security issues than XSS. And most modern browsers are immune to XSS.
  - ryao 11y ago
    > Apps suffer from MUCH bigger security issues than XSS. It depends on the attack surface. However, something like WebBlueTooth has only one-click/tap authorization protecting it at best against software that is already downloaded and executing. Mis-taps/clicks are trivial. You do not have that with a new application that a website wants you to download. You also tend not to have installed software updated without your consent after you first obtained it (with the trend to use Javascript to add functionality to iOS apps being the glaring exception), but websites can be updated at any time, by both the web developer and by black hats who hack into it.
ryao 11y ago
A malicious app must be installed before it can run and is likely vetted by the maintainers of a package manager or App Store. A webpage running JavaScript simply runs with no inspection from anyone. Also, a malicious party usually cannot inject code into an installed app. Injecting it into a webpage you visit is far easier. Ad/tracking networks have been used for that. There is the possibility of a MITM attack if all parts of the page are not protected by HTTPS. There is also the potential for cross site scripting. The web is not a place where I would want access to everything an installed application can access to be possible by design.
- takno 11y ago
  The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service. If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing.
  - ryao 11y ago
    > The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service. If you are going through an app store, the app has been vetted. If that misses something and it is later found, it gets pulled. There is the possibility that you will never encounter the bad app by virtue of being one of the ones who would have installed it using it after it was pulled. On iOS, there is the possibility of signature revocation providing protection to disable it after it is downloaded. With a website, there is no such protection. Plus, web servers are rarely patched and often exploited. Anyone who allows a website to use WebBluetooth effectively opens themselves to the poor security practices of the other end. Even without that risk, there is also the risk that an ad/tracking network is not used in a cross site scripting attack to gain access. > If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing. If all users thought the way I did, WebBluetooth would never have been proposed. The reason being that WebBluetooth could be used to exploit other things even if the web browser's implementation has no exploitable bugs. If WebBluetooth becomes widely used, Black hats will have a field day with the users who do not know. They need not even compromise a web server of a site that has a legitimate application for it. They might just ask users of some other site that they trust to enable it as few users ever say no to such prompts (or prompts in general).
peyton 11y ago
Browsers are a huge attack vector. And Mobile Safari can mark data pages as executable, while apps cannot.

by untog 11y ago

kec 11y ago

I visit far more websites in a day than I use strange new apps. Apps also don't suffer from XSS.

Guvante 11y ago
> I visit far more websites in a day than I use strange new apps. From the article you have to "install" the web application for any of these features to be available. > Apps also don't suffer from XSS. From websites sure, but they do from other apps.
- ryao 11y ago
  > From the article you have to "install" the web application for any of these features to be available. As far as the article is concerned, rendering a webpage as if it were an app takes away functionality (mainly, the ability to interact with the address bar). It does not discuss the security of web 2.0 features and it certainly does not claim that these features are only available when the webpage is pretending to be an app. > From websites sure, but they do from other apps. iOS uses capsiculum to isolate applications while Android uses SELinux. They aren't executing each others' code.
  - Guvante 11y ago
    > iOS uses capsiculum to isolate applications while Android uses SELinux. They aren't executing each others' code. XSS isn't about executing other people's code, it is about performing commands that you shouldn't be performing. There are a ton of instances in the pass where cross application communications have lead to privilege escalation in the same way that XSS does.
intrasight 11y ago
Apps suffer from MUCH bigger security issues than XSS. And most modern browsers are immune to XSS.
- ryao 11y ago
  > Apps suffer from MUCH bigger security issues than XSS. It depends on the attack surface. However, something like WebBlueTooth has only one-click/tap authorization protecting it at best against software that is already downloaded and executing. Mis-taps/clicks are trivial. You do not have that with a new application that a website wants you to download. You also tend not to have installed software updated without your consent after you first obtained it (with the trend to use Javascript to add functionality to iOS apps being the glaring exception), but websites can be updated at any time, by both the web developer and by black hats who hack into it.

ryao 11y ago

A malicious app must be installed before it can run and is likely vetted by the maintainers of a package manager or App Store. A webpage running JavaScript simply runs with no inspection from anyone. Also, a malicious party usually cannot inject code into an installed app. Injecting it into a webpage you visit is far easier. Ad/tracking networks have been used for that. There is the possibility of a MITM attack if all parts of the page are not protected by HTTPS. There is also the potential for cross site scripting. The web is not a place where I would want access to everything an installed application can access to be possible by design.

takno 11y ago
The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service. If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing.
- ryao 11y ago
  > The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service. If you are going through an app store, the app has been vetted. If that misses something and it is later found, it gets pulled. There is the possibility that you will never encounter the bad app by virtue of being one of the ones who would have installed it using it after it was pulled. On iOS, there is the possibility of signature revocation providing protection to disable it after it is downloaded. With a website, there is no such protection. Plus, web servers are rarely patched and often exploited. Anyone who allows a website to use WebBluetooth effectively opens themselves to the poor security practices of the other end. Even without that risk, there is also the risk that an ad/tracking network is not used in a cross site scripting attack to gain access. > If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing. If all users thought the way I did, WebBluetooth would never have been proposed. The reason being that WebBluetooth could be used to exploit other things even if the web browser's implementation has no exploitable bugs. If WebBluetooth becomes widely used, Black hats will have a field day with the users who do not know. They need not even compromise a web server of a site that has a legitimate application for it. They might just ask users of some other site that they trust to enable it as few users ever say no to such prompts (or prompts in general).

peyton 11y ago

Browsers are a huge attack vector. And Mobile Safari can mark data pages as executable, while apps cannot.