Hacker News Reader

Comment by rwaldron | Hacker News Reader

If Facebook made use of smart OCAP practices, none of that would be possible. Use of object identity as a "security key" would prevent code that doesn't have access to the "key" object from being successful.

View on HN

What? What's OCAP? Object identity? How does that have to do with XSS? Links, references, sources?

The developer console has access to everything the origin does. If the user can do it, the console can do it.

Not necessarily, because you can limit how certain values can be accessed due to your scope. For JavaScript, if a key is saved in a variable inside an anonymous function, it's inaccessible for somebody who has a console that sits at the root of the document.

    document.getElementsByTagName('script')[0].innerText

.innerText is an MSIE extension, .textContent is a DOM standard property.

    > fn = function(){ var key = "shhhhh" }
    > fn.toString()
    'function (){ var key = "shhhhh" }'

Nothing is sacred in JS.

A very nifty trick!

But it requires that the value is hardcoded inside the function. If it was given to an unreachable scope by some async action (like an ajax request) this trick wouldn't work.

One could possibly also wrap the function in an native .bind call to change the output of toString() to [native code]

I wonder if even that's feasibly secure though, when you have stuff like http://esprima.org that can let you fully parse the entirety of the JS on the page.

It's better to assume the console has 100% root (client-side) privileges.

But the enemy here isn't necessarily the console, it's the social attack against the console. Making it harder for the user to screw himself over is a worthwhile endeavor, and not merely "security by obscurity".

It would be harder, but the developer console has access to closures as well:

http://stackoverflow.com/a/16048707/73681

You need to explain this further because I don't see how that would prevent anything.

Reply on news.ycombinator.com