41

Exceptions/Errors in many other programming languages (say java, ruby) always provide stacktrace/backtrace information.

In JavaScript unhandled Errors get caught by window.onError.

Although that function does not get the Error object, so we have no access to the object's stack property.

Is there any reliable source of information about when will there be any change on that?

Dimitris Zorbas
  • 5,187
  • 3
  • 27
  • 33
  • hopefully never, that's a major security issue. – dandavis Jul 16 '13 at 22:52
  • 8
    @dandavis how would it be a security issue? the user can step into javascript code with browser tools all day long. with enough effort they could obtain the stack trace – Kip Jul 25 '13 at 17:07
  • because if full errors were reported, you could load any HTML page as a script[src], and the error message would revel the HTML contents in the syntax error message, violating the SOP. – dandavis Jul 25 '13 at 18:19
  • 5
    @dandavis That doesn't make sense. Allowing a client to load your HTML page as a script has nothing to do with the onerror arguments. See more http://www.w3.org/TR/cors/#cross-origin-request – Dimitris Zorbas Jul 25 '13 at 21:13
  • 2
    @dandavis Most browsers already don't give *any* detail about script errors, even the error message (which is just reported as "Script error" by Chrome and Firefox in this case), if the script is loaded from another domain and wasn't served with appropriate CORS headers. The vulnerability you're describing could potentially be just as serious even if it only applied to real scripts, or even if only the error message and not the traceback was revealed - but it's a moot point because browsers already protect against the attack you're imagining. – Mark Amery Dec 20 '13 at 14:54
  • i'm not imagining anything, it's historically been a problem. as recent as E4X's release there were these sorts of vulnerabilities. That's why the messages are restricted the way they are today. live and learn. – dandavis Dec 20 '13 at 20:58
  • 2
    @dandavis If the hacker wants to get the stack trace, all they have to do is put a break point where the error is being thrown. Your security is flawed, same idea as thinking that obfuscation is security. Real security is making sure the client doesn't have access to data it shouldn't, instead of passing the data to the client and making the client hide it, then you would have a security hole, and preventing stack traces does not really mitigate this... Now, stack traces **from the server** should never be displayed in a production environment because they main contain sensitive data. – Ruan Mendes Feb 13 '14 at 17:49
  • my security is flawed? I have no clue what you're referring to, or how your points relate to anything i've said. how does one put a JS breakpoint in HTML? That doesn't make sense... I pointed out that back in the day, maybe before you got into JS, adding a script tag pointing to "http://google.com/" would throw a syntax error containing the HTML of the url as part of the error message/properties. This allowed, for example, grabbing the tag from about any site. That was fixed a long time ago (before cors or chrome) as i, and for some reason others, have repeatedly pointed out... – dandavis Feb 13 '14 at 18:25

2 Answers2

41

The error object, which would contain a "sanitized" stack trace, is now being passed in as the fifth parameter to onerror in Chrome. You can read about it here: https://code.google.com/p/chromium/issues/detail?id=147127

At the time of this writing it's in Canary and should be pushed out to the stable Chrome release sometime later this month. If you're running Canary you can test it like so:

window.onerror = function (message, file, line, column, errorObj) {
    if(errorObj !== undefined) //so it won't blow up in the rest of the browsers
        console.log('Error: ' + errorObj.stack);
}

You can see as per the spec that they've also added the column number which IE 10 has also implemented.

You can also checkout the Mozilla discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=355430

Brandon Pugh
  • 1,567
  • 1
  • 13
  • 18
12

It seems that the error object itself will be the fifth parameter supplied to onerror. http://html5.org/tools/web-apps-tracker?from=8085&to=8086
http://www.whatwg.org/specs/web-apps/current-work/ - section 7.1.6.1

Dimitris Zorbas
  • 5,187
  • 3
  • 27
  • 33
  • 1
    This is not true in all browsers. IE10 returns args as errorMessage, scriptFile, scriptLineNumber, scriptColumnNumber – Kip Jul 26 '13 at 15:43
  • 1
    According to [http://msdn.microsoft.com/en-us/library/ie/cc197053.aspx](http://msdn.microsoft.com/en-us/library/ie/cc197053.aspx) (last updated 7/22/2013) what you say is not true. Can you please provide some piece of documentation that says so? – Dimitris Zorbas Jul 26 '13 at 19:44
  • 1
    the documentation doesn't say that there is a fourth argument. but if you actually try it (just try it, i tried it yesterday) you'll see the fourth arg is the column number. it may be an undocumented "feature" that doesn't conform to standards, but it certainly doesn't return the original error object – Kip Jul 28 '13 at 02:12
  • is there a way to get angular.js to provide a stack trace instead of relying on the browser? – FutuToad Mar 10 '14 at 17:35