5 ms·

> WebBluetooth (yup, talking to bluetooth devices from JS on a webpage) This sounds like a great new attack vector for the black hats of tommorrow. There are

by ryao 11y ago

> WebBluetooth (yup, talking to bluetooth devices from JS on a webpage) This sounds like a great new attack vector for the black hats of tommorrow. 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.

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.
chromakode 11y ago
The user experience is similar to webcam/microphone access: nothing works without a prompt and browser-mediated pairing process, and only on secure origins (e.g. https). The spec goes into detail about security/privacy considerations, and includes a blacklist of problematic targets. https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy https://webbluetoothcg.github.io/web-bluetooth/#security-and... Access through web browsers could expose issues in the user's kernel bluetooth stack, but that risk exists with any binding. There should be time to explore this possibility while the feature is still behind a flag.
- ryao 11y ago
  > The user experience is similar to webcam/microphone access What happens behind the scenes is not. The microphone and webcam are far easier to secure because they just provide data streams if authorized and the web browser can provide a visual cue when it is in use. Some webcams even have a light to indicate when they are I use. Although that might not be perfect, it is far better than things like browser plugins. Bluetooth is another story. With WebBluetooth, you are effectively providing access to an Advanced Persistent Threat attack vector. That takes things to a whole different level for black hats. If it is widely adopted, someone somewhere will find a way to target it as compromising the firmware of paired Bluetooth devices should be easier than typical escape from sandbox attacks. How long it takes for us to hear about it is another story. > Access through web browsers could expose issues in the user's kernel bluetooth stack, but that risk exists with any binding. There should be time to explore this possibility while the feature is still behind a flag Whether WebBluetooth can attack the Bluetooth stack directly is irrelevant. What matters is the embedded device's Bluetooth stack. Allowing a web site to dictate the contents of an otherwise legitimate communication with an embedded device's Bluetooth stack allows it to compromised with no compromise of the machine required. Running exploits against the embedded device should just requires gaining control of a webserver hosting a site that the browser permits to use webbluetooth or injecting code through a XSS attack. If the embedded device allows firmware updates over bluetooth, getting malicious code onto it is easy. If not, the embedded code that communicates with a paired device should have been written under the assumption that the other end would not try anything malicious and consequently, it should have vulnerabilities. Regardless of how a blackhat gets into a paired bluetooth device, once they are inside, they have code execution on the opposite side of the surface typically attacked on modern computers.
eckza 11y ago
Paging twitter.com/internetofshit

by ryao 11y ago

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.

chromakode 11y ago

The user experience is similar to webcam/microphone access: nothing works without a prompt and browser-mediated pairing process, and only on secure origins (e.g. https). The spec goes into detail about security/privacy considerations, and includes a blacklist of problematic targets. https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy https://webbluetoothcg.github.io/web-bluetooth/#security-and... Access through web browsers could expose issues in the user's kernel bluetooth stack, but that risk exists with any binding. There should be time to explore this possibility while the feature is still behind a flag.

ryao 11y ago
> The user experience is similar to webcam/microphone access What happens behind the scenes is not. The microphone and webcam are far easier to secure because they just provide data streams if authorized and the web browser can provide a visual cue when it is in use. Some webcams even have a light to indicate when they are I use. Although that might not be perfect, it is far better than things like browser plugins. Bluetooth is another story. With WebBluetooth, you are effectively providing access to an Advanced Persistent Threat attack vector. That takes things to a whole different level for black hats. If it is widely adopted, someone somewhere will find a way to target it as compromising the firmware of paired Bluetooth devices should be easier than typical escape from sandbox attacks. How long it takes for us to hear about it is another story. > Access through web browsers could expose issues in the user's kernel bluetooth stack, but that risk exists with any binding. There should be time to explore this possibility while the feature is still behind a flag Whether WebBluetooth can attack the Bluetooth stack directly is irrelevant. What matters is the embedded device's Bluetooth stack. Allowing a web site to dictate the contents of an otherwise legitimate communication with an embedded device's Bluetooth stack allows it to compromised with no compromise of the machine required. Running exploits against the embedded device should just requires gaining control of a webserver hosting a site that the browser permits to use webbluetooth or injecting code through a XSS attack. If the embedded device allows firmware updates over bluetooth, getting malicious code onto it is easy. If not, the embedded code that communicates with a paired device should have been written under the assumption that the other end would not try anything malicious and consequently, it should have vulnerabilities. Regardless of how a blackhat gets into a paired bluetooth device, once they are inside, they have code execution on the opposite side of the surface typically attacked on modern computers.

eckza 11y ago

Paging twitter.com/internetofshit