From MozillaWiki
Jump to: navigation, search

Items to be reviewed: SourceMap - Agenda:

Introduce Feature

The premise of the project is that most JavaScript goes through some type of compilation step before being deployed. Generally, that compilation step is minification, but increasingly it is also cross language compilation steps like CoffeeScript, ParenScript, or Google Web Toolkit. In both both cases, you have your original source(s) that you wrote, and then the generated source which is produced in an automated fashion by some compilation step. When there is a bug or uncaught exception in the generated source, it is a pain to debug because you are not familiar with that code because you didn't write it yourself. Source maps come in to save the day by mapping a generated line and column information back to the original source(s), original line, and original column. It is a JSON file, with the actual mappings encoded in a base 64 variant. Developer tools can then take advantage of the presence of these source map files by displaying the original position of things like logged messages and uncaught errors, or by allowing developers to set break points in their original sources rather than the generated ones as they step through a script's execution in the debugger. There is a core library which will be shared across developer tools in Firefox, compiler tools generating source maps, and even non-Firefox developer tools. It only deals with the source maps directly, and knows nothing about where they came from, how to get them, where to put them, etc. This work is pretty much complete, although there are some minor licensing issues that need to be dealt with before it can land. The first developer tool in Firefox which will take advantage of source maps is the webconsole. It will map logged messages and uncaught errors back to their original sources. This work is in progress and the bulk of it is done, but there are a few patches that need to land that this work is dependent upon. Here are some links with more information:

Threat Brainstorming

  • Attacks using the JSON data blob
    • using JSON.parse
    • restricted to basic types, non-functions
    • I don't see any problems regarding JSON itself, if it is parsed by the JS functionality. Any such attack could be conducted directly through JS as well.
    • Attacks on binary blob format inside the JSON blob
      • Not a problem if the interpreting code is JS itself, but future implementations might want to use C for perf reasons. In that case, another review will be required.
  • Code is running with Chrome Privileges
    • Does the code take any actions based on the source map information that could be useful?
      • File/URL specification in the format? Allows local files and other protocols
        • Can any information (file content, presence of files) leak back to the content (cross zones)?
          • Timing attacks?
      • SourceMap code needs to whitelist http/https (preferably) as the only allowed schemes when loading source maps and source files. Second best would be calling CheckLoadURIWithPrincipal() with the original documents principal. Otherwise you allow javascript:<evilcode> in a Chrome context, or can call custom add-on protocols (make toll Skype calls? Send IM's?).
  • source file names, what are they used for
    • used if genereated file is made of multiple files to find the true source
    • there is no restriction of where the URL can be on the web
    • no code running in content can access the sourcemap library, thus preventing data exfil from other locations

Conclusions / Action Items

  • [decoder] Penetration testing for information leakage and code injection
  • Documentation needs to cover security implications with regards to making a source map public (MDN Doc)