Warning:
This wiki has been archived and is now read-only.

Security Issues

From Web Commerce Interest Group
Jump to: navigation, search

W3C Security Gaps (Erik Anderson, Bloomberg)

  • Security
  • Security needs to be factored into every decision made at the W3C.
  • How is W3C addressing security decisions in non-secure groups? It shouldn't be purely the responsibility of the Security Working Groups. Please provide documentation and links.
  • It shouldn't be purely the responsibility of the Security Working Groups.
  • Security is everyone's problem but few understand it
  • Known issues
  • The JavaScript global object
  • Description: The JavaScript global object -- or the window object as it's called in the browsers -- gives every scrap of script the same set of powerful capabilities
  • Problem: There's no way a page can defend itself from any other script that happens to get into that page. Untrusted code shouldnt be given the same powerful capabilities
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address this security issue:
  • The server should never trusted the browser to enforce policies.
  • Description: The browser should never be trusted. Never trust the browser. The browser cannot and will not protect your interests. You must properly filter and validate everything that comes from the browser.
  • Problem: How can the browser be properly utilized to filter and validate prior to being sent to the server. Native Applications do exactly this.
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address this security issue:
  • A malicious party can exploit coding conventions to inject malicious code.
  • Description: A malicious party can exploit any JavaScript object to inject its own malicious code.
  • Example:
Array.prototype.push=(function(){
    var original = Array.prototype.push;
    return function() {
        //Send data to hacker website
        return original.apply(this,arguments);
    };
})();
  • Problem: Any code can do whatever it wants in the browser. It can override an array method and send all data to a 3rd party web service.
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address this security issue:
  • Malicious code gets all the same permissions as the site
  • Description: Any code downloaded in into the browser has the same permissions as the site itself
  • Problem: Not all code should be trusted. The principle of least authority - Any unit of software should be given just the capabilities it needs to do its work, and no more. Problem with browser gives capabilities to all of the scripts. Objects should be granted capabilities on a need-to-do basis.
  • Examples of what a hacker can do that injects code
  • The attacker can request additional scripts from any server in the world. Once it gets a foothold -- and it only needs a tiny amount of code to do that -- it can obtain all the additional scripts it wants from the most evil websites in the world. The browser has the same origin policy that limits the ability of a page to interact with other sites, but it in no way limits the ability of an attacker to get more script to run on your page.
  • An attacker can read the document. The attacker can see everything the user can see and a lot of the things the user can't see. It can see hidden fields, comments, cookies, all sorts of stuff which is invisible on the page.
  • The attacker can make requests of your server, and your server cannot detect that the requests did not originate from your application. Now, you should be using SSL to secure your connections, but if you do, it doesn't help you here because the attacker gets access to your secure connections. You should be authenticating your requests from the browser with a special token, sometimes called a crumb .. that doesn't help. The attacker has access to that as well.
  • If your server accepts SQL queries then the attacker gets direct access to your database, and can do anything that SQL will allow them to do. Now, if your server application is creating SQL queries by concatenating together pieces of material that it gets from the browser, then you probably gave access to the attacker to your database, because SQL was optimized for SQL injection attacks.
  • The attacker has control over the display and can request additional information from the user, and the user cannot detect that the request did not originate from your application. The browsers all have anti-phishing chrome in them now. The problem with it is that the users don't pay any attention to it. If they did, the chrome would be saying this is a legit request, go ahead and give it. Because what the browser is looking for is where the HTML came from, not where the script came from, and it's the script that's evil here.
  • Some sites, whenever something scary is about the happen, think okay, let's make sure that the user is still on board, so let's ask for their password again. That doesn't help you in this case because the attacker has control of the screen, so he can go to the user and say what's your password, and everything tells the user that this is a legitimate request: give it up. In fact, if your site routinely asks the user to give up their password at unlikely times, what you're doing is training the users to give up the password any time an attacker asks for it.
  • The attacker can then send the information that it obtained by talking to your servers or scraping the page or talking to the user and send it to any server in the world. Again, there's the same origin policy in the browser, which does not limit the ability of the attacker to send this information to the most evil site on the planet.
  • The above types of attacks are called XSS (Cross site scripting). Cross site scripting attacks were invented in 1995 yet we havent made any progress on the fundamental problem since then.
  • The browser does not prevent any of these, and web standards require these weaknesses. If your browser does not expose your site and your users to all of these problems, it is not standards compliant. There's something deeply wrong in the W3C standards. To make the browser secure means breaking those W3C standards and that's going against the 'standards politicians'.
  • Instead of trying to guess if code can do something bad, try granting it a safe capability. Most code should never be granted access to Window, Document, or innerHTML.
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address this security issue:
  • Who's interest does the Browser represent?
  • Description: The browser represents the interest of the website its showing.
  • Problem: Lets use Web Payments as an example. As it turns out there are more interests involved than the users and the sites. It needs to represent a third party as well, the payment provider. A malicious party can exploit code conventions to inject malicious code onto the page, and that code gets all of the rights of the site. This can compromise the site and the user.
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address this security issue:

Regulatory and liability concerns

  • Who's liable?
  • Description: Basic principle of liability: The entity in the best position to deter fraud will bear the losses for fraudulent payments. This principle of assigning liability to the control point best suited to prevent fraud provides strong incentive to detect and deter fraud in a cost-effective manner.
  • Problem: Statutory rules allow this applies to the developers of emerging technologies, writers of emerging standards, and adopters of these systems.
  • Example: Parties knowingly publish a standard a technology solution with knowing flawed implementations will be liable for fraudulent transactions utilizing that environment.
  • Case study: EMC Corporation was liable for all of RSA's lawsuites.
  • Date Identified: Over 10 years ago
  • ETA:
  • Links and documentation to W3C efforts to address their potential liability of developing a payment initiating standard/environment with n-number of existing flaws.
  • NOTE: Most users dont know how to protect their home computer against the plethora of malware that comes in through the browser. The end users are not in a position to best protect themselves against the malware that infects personal computers with key loggers that harvest online banking credentials, which are then used to generate fraudulent wire, check, credit card, bitcoin, or ACH payments. If the enhanced security is added to the browser all PC's, Mac's, Mobile devices, laptops, and tablets get the enhanced security. A simple hardware token could be used as an unlocking mechanism to protect the sensitive data even AFTER the data has been relayed to fraudsters. Home users are protected from themselves and everyone benefits. Browser enabled security protocols would effect a system-wide approach to payment security and be further enhanced by immediate acceleration of public & private efforts not even related to payments. This will further push payment participants to adopt effective identity and security protocols.
  • Anti-fraud solutions
  • Description: Countries that adopted chip-n-pin carts have noticed that fraudsters shifted their efforts to identity fraud, taking over or creating new accounts, and IMOTO (Internet and Mail Order and Telephone Order) causing a dramatic rise in associated fraud losses.
  • Problem: History shows that new payment instruments & technologies lack adequate protective measures, such as the Internet, causing a major influx of fraudsters. Adopting chin&pin in the US will have unintended consequences such as flocking to internet based payment mechanisms.
  • Date Identified: Recently due to W3C Web Payments efforts
  • ETA:
  • Links and documentation to W3C efforts to address this concern

Conclusions

  • Paypal is successful because its an application written around the insecurities. How to deliver Paypal features on a public browser when the the current web stack is too complicated as a trusted payments initiation environment.
  • W3C (or someone) must document all known security issues. Failure to do this and launch a payments specification into the financial world without documentation of "preexisting issues/risks" will result in finger pointing liability issues in event of a security compromise that leads to fraud.
  • W3C must provide " Links and documentation to W3C efforts...". We can use this to start laying out a roadmap.
  • Many of these issues are over 10 years old. Please provide a roadmap that addresses each issue.
  • Most users don't know how to protect their home computer against the plethora of malware that comes in through the browser.
  • The end users are not in a position to best protect themselves against the malware that infects personal computers with key loggers that harvest online banking credentials, which are then used to generate fraudulent wire, check, credit card, bitcoin, or ACH payments.
  • If enhanced security measures are added to the browser all PC's, Mac's, Mobile devices, laptops, and tablets get the enhanced security.
  • A simple hardware token could be used as an unlocking mechanism to protect the sensitive data even AFTER the data has been relayed to fraudsters.
  • Home users are protected from themselves and everyone benefits.
  • Browser enabled security protocols would effect a system-wide approach to payment security and be further enhanced by immediate acceleration of public & private efforts not even related to payments.
  • This will further push payment participants to adopt effective identity and security protocols.
  • To keep the costs low and not boil the oceans, the optimal control point should use a least-cost method to enhance security. Enhanced security must start at the browser.
  • Financial services considers the web = "the cloud". Payment systems were not designed with the internet in mind. Financial institutions are not moving to the cloud anytime soon. Major Financial Institutions will not engage the W3C until they "feel more comfortable with the direction things are going".
  • However:
  • enhanced browser security will accelerate migration to the could
  • enhanced browser security will increase confidence and financial utility of the web align financial institutions interests with that of the W3C
  • enhanced browser security will help align interests between those of financial institutions and that of the W3C
  • enhanced browser security will reduce losses resulting from fraud and the costs associated with running a fraud prevention unit
  • enhanced browser security will invite financial institutions to transact using the web (Inter-ledger or web based settlements)

A few recommendations from a company that has implemented a more secure web interface

  • Dont expose the window or document object to everyone. These 2 objects are the source of most insecurity.
  • Dont iterate the window and document object's to expose its members as globals that any JavaScript can get at.
  • Make a JavaScript classing system that uses closures to protect private members inside of closures. Very much like C++ private, protected, and public members. Use the private to protect access.
  • All HTML elements on the page must be protected against direct accessibility as well. If you grab a reference to any HTML element you can walk that element back to the document and window parents.
  • Use a 'shadow document' or 'shadow window' object. Only expose the bare functionality required.
  • Use Object.freeze(myObject); to prevent existing JavaScript objects from being hijacked for malicious intent.
  • Create a separate JavaScript context and load all trusted JavaScript that is allowed access to insecure interfaces like window, document, HTML5 interfaces like file access, sockets, etc.
  • Asynchronous module loading, like require() is dangerous.
  • Use a native version require() that allows you to enforce the use of a manifest system to ensure only authorized dependencies are loaded.
  • All dependencies are loaded at loadtime not runtime. Any require() that is done at runtime only returns the reference to the existing loaded module. If the module wasnt loaded before this point an exception is thrown.
  • Manifest should utilize a SHA2 hash to verify the loaded modules are the correct intended files.
  • Native require() should never allow a fully qualified domain name to be specified. FQDN are only specified in the manifest.
  • Decouple the merchant shopping session from the payments initiation session. The payments initiation session must have all untrusted browser capabilities removed. This would be most easily accomplished via browser extension (pure JavaScript)