3 ms·
as the day SSH became vulnerable to CSS cross-domain exploits :)
by gcb 14y ago
as the day SSH became vulnerable to CSS cross-domain exploits :)
- adgar 14y agoAny input receivable by OpenSSH, regardless of whether it is valid user input or malicious input being delivered by a cross-domain attacker, mustn't result in exploit. If so, it's a bug in OpenSSH, not the fault of the developer who integrating the existing OpenSSH code into a new environment. Unless, of course, the developer integrating the existing OpenSSH code did so in a way that's not the formal OpenSSH interface. Like if he had to do some kind of dirty hack. But he shouldn't have to for this project.
- jsight 14y agoI don't see how the OpenSSH code is expected to automagically insure that keystrokes sent from Google Chrome came from intentional user generated actions. Any XSS type vulnerabilities in this are likely the result of issues with the extension itself rather than OpenSSH, IMO.
- rginda 14y agoThe app opts-in to a strict Content Security Policy <http://www.w3.org/TR/CSP/> http://www.w3.org/TR/CSP/>, which disallows 'eval' entirely. It also severely restricts where and how JS can be loaded with the script tag, setTimeout/setInterval, and event attrbites. It's essentially intended to make sure that only the JS that shipped with the extension can be executed. There may be undiscovered exploits, of course, but CSP severely reduces the chances.