Gotta have standards? Security boffins not API about bloated browsers

W3C, are you listening?

+Comment The W3C introduces API standards that end up mostly unused, doing nothing more than loading up the code base with vulnerabilities.

That's the conclusion of a paper by University of Illinois, Chicago researchers to be presented next week at the ACM's Conference on Computer and Communications Security in Dallas.

Chrome 56 quietly added Bluetooth snitch API

READ MORE

While the research – "Most Websites Don't Need to Vibrate: A Cost-Benefit Approach to Improving Browser Security" – which you can find here at arXiv, focuses on Firefox, its findings are relevant across the board.

Graduate computer science student Peter Snyder and colleagues Cynthia Taylor and Chris Kanich structure the paper as a cost-benefit analysis of having 74 APIs with which browser authors need contend. On the benefit side, they measured the proportion of websites that use a feature (thereby making browser support important); on the cost side, they tried to measure the security exposure a feature created.

The “cost” side takes a couple of characteristics into account, including the number of historical CVEs associated with a feature (since that hints that it's hard to code to the API securely); and the number of API entry points and lines of code that are associated with a feature, since that indicates more complex code.

Their headline finding should chill browser authors:

“Blocking 15 of the 74 standards avoids 52.0 per cent of code paths related to previous CVEs, and 50.0 per cent of implementation code identified by our metric, without affecting the functionality of 94.7 per cent of measured websites.”

A search of the Mitre CVE (Common Vulnerabilities and Exposures) database yielded 1,554 CVEs for Firefox since 2010, a decent enough sample (Chrome has had 1,523 in the same period), and 175 of those related to implementations of 39 Web APIs, with 13 related to multiple standards.

The researchers crafted a browser extension to block APIs based on the risk measurement, and this is how things turned out:

Blocking vulnerable APIs

Blocking risky APIs breaks hardly any websites,
but makes the user more secure.

+Comment

The results come as little surprise to Vulture South, since over the last couple of years, we've taken a growing interest in the privacy implications of APIs that serve little purpose but to profile users for advertisers.

shutterstock_215940778

Apple, Mozilla kill API to deplete W3C battery-snitching standard

READ MORE

Examples include the Web Battery API, dropped by Apple and Mozilla over privacy fears; the Bluetooth API; a motion sensor API that a smart cookie used to snoop on phones' unlock codes; a risky ambient light sensing API, and so on (for most of these, we're indebted to security researcher Lukasz Olejnik).

It's yet another reason the W3C needs to take a leaf out of the Internet Architecture Board's book, and make user protection part of its mission, instead of an afterthought. ®

Sponsored: Minds Mastering Machines - Call for papers now open




Biting the hand that feeds IT © 1998–2018