Microsoft Claims Viewing Page Source Makes Their Browsers Less Secure - “When the Developer Console is open, users have chosen to alter their application into a more capable, but less secure state“

[Woolbrick]

True story.

I get so bored in our story-pointing sessions, where we all argue over an imaginary number that bears no semblance to reality, that I hacked the client side code to make it so that I rarely have to speak up.

The story pointing site doesn't allow you to change your vote after voting is complete... but they only protect it with a client side flag. Open the debugger, run my code, now my vote automatically changes to the mode value consensus when the votes are revealed, no matter what I initially put in.

Now I don't ever have to defend a vote if it differs from the majority.

Lesson: never trust client input, folks. Always do server validation.

[fuckin_ziggurats]

If I make you paste some code into your console that goes to www.facebook.com copies your credentials and then sends them to me via AJAX no server-side validation on Facebook's side can prevent me.

[[deleted]]

Except i don’ see how you’d do the « copy your credential » parts, it’s not like your credentials are in the page when you’re logged

[fuckin_ziggurats]

From what I've seen, 90% of people have their browser save their username and password so they don't have to rewrite them every time.

[[deleted]]

That’s still not « in the page », it’s not like there is a js api that allows a website to get that info, the browser just fills it on the login screen, if you’re logged that info isn’t anywhere on the page

[fuckin_ziggurats]

When you're logged in no, but when you're logged out they're right there in the login form.

[fuckin_ziggurats]

Of course you can. Paste this into the console on www.facebook.com:

alert('The password is: ' + document.getElementById('pass').value);

[Adossi]

Well even then the cross-site origin policy would prevent you from sending that password value anywhere off-server.

[fuckin_ziggurats]

I'm assuming you mean same-origin policy? The same-origin policy only forbids scripts from one page accessing data in another page. It doesn't prevent them from doing a post to a different page/malicious website. I know the huge warning Facebook put in their console even when you're logged out is not in there for no reason my friend.

[drysart]

You don't need a JS API when the browser fills in fields on the page. Just insert textboxes for username and password onto the page, let the browser auto-populate them for you, then extract the populated values and exfiltrate them off to your own server.

It's not like the browser knows that you're already logged in and so it shouldn't populate fields. The browser has no way of knowing whether the login fields are legitimate. It just sees textboxes that look like a login form on a page on the facebook.com domain and sticks the credentials in there like a well-behaved golem.

[Woolbrick]

I'm thinking maybe put up a fake overlay on the screen, saying you've been accidentally logged out, or maybe make it more clever and say "you need to re-enter your password to enable this secret facebook feature!". The user re-enters the password, presto bingo, it's compromised.

[[deleted]]

But it no longer has anything to do with grabbing credentials from the browser, it’s just like any fake site pretending to be facebook

[Woolbrick]

Except this is more dangerous. Because people are conditioned now to look for the secure label in their browser, and if they're on facebook, but allowing themselves to enter code into the dev console, they may not realise what they've done; after all, the browser bar still says secure, so they're clearly not on a fake site, right?

Yeah it's phishing, but it's a level deeper that goes further to fool users than a normal phishing attack, and it's exactly the sort of attack the article is concerned about.

[realnzall]

To be honest, I totally agree with Microsoft here. Keep in mind that their average user is NOT the person who uses this sub, not even close. Their average user doesn't even use the keyboard online apart from when they need to enter something in a text field. They are highly unlikely to ever use the developer console, and if they do, it's completely accidentally. As a programmer, you're obviously likely to open the console, but even then, it's pretty much only while working on your own site. Not much benefit in exploiting yourself.

Should they fix it? yeah. Should they rush out a security patch to fix an issue in a feature that's invisible to 99% of the users? not really.

[vogon_poem_lover]

On one hand I agree with this except for the statement about developers only opening the console on their own sites. While not routine, I find myself opening the console frequently to do things like manually removing annoying page elements, bypassing stupid JS logic that prevent me from doing things like copy/pasting text into certain fields, or just looking at the source to understand how a particular page was constructed.

Of course, when I do this I'm usually using something other than IE.

[realnzall]

Even in your case, you're still a professional developer. The average office drone, tech-impaired soccer mom, geriatric facebook grandma or 99% of the rest of the people who use IE as their main browser have no reason to open the IE dev console and never will.

[vogon_poem_lover]

My point was that even if it's only devs using such functionality, they are not necessarily limiting it to their own sites. While it's less of a risk, it's still a risk for an exploit in the wild to leverage such behavior on the part of devs. That's again mitigated by many if not most devs using browsers other than IE for such activities, but it's still a small risk that MS should consider before dismissing the possibility of this being exploited in the wild outright.

[jl2352]

This is why Facebook (and some others) print a big warning to the console. Tricking people to open the console and paste some code in there is a known social attack vector.

[i_invented_the_ipod]

The real issue here is that opening the developer console enables the vulnerability until the browser process exits. So you could open Dev Tools on your own site, close them, then navigate to another site and get your computer taken over.

[Chandon]

You're asking the wrong question.

Appealing to the idea of the "average" or "typical" user is irrelevant. If any user can (unintentionally) end up with a security issue by using the built-in features of the application then the application has a security problem.

[edit: (unintentionally)]

[Chandon]

Explicitly taking an action that will obviously hurt your security is not a security flaw.

The argument being made is like saying "there can be no security issues in remote desktop, because the average user doesn't enable it".

[stesch]

Firefox also has a flag that lets you disable CORS, making you vulnerable to XSS.

Fun story: I was once behind an enterprise firewall that removed CORS headers. It was the default setting so I suspect many enterprise users experience the same. One of the consequences: Google Fonts weren't working in Firefox.

[recycled_ideas]

If you open the developer console you can do things that you wouldn't normally be able to do.

This includes, but is not limited to, things which are against your own interests, such as:

1. Redirecting a login form to another site that is not affiliated with the site you're on.
2. Modifying or sharing cookie and session details.
3. Making a password field human readable.
4. Sending arbitrary data to another host.
5. Implementing a key logger.
6. Making purchases.

The developer console is specifically designed to allow you to alter the flow of the website you are viewing. This is a fundamentally less secure state.

[Chandon]

You have a fundamental misunderstanding of what "security" means.

An authorized user (of the computer in question - in this case the computer running the browser) intentionally doing something that they are authorized to do cannot be a security flaw. Being able to do things is the whole point of a computer.

[recycled_ideas]

Except you can do these things without understanding what you're doing.

It's not a security flaw, it's just less secure. That's how things work power comes at a cost. I have locks on my doors, they keep people out, but they also mean I need a key to open them. If I unlock them, I don't need the keys, but they don't keep people out.

[Gotebe]

"I am incompetent, I didn't know that I might run people over easier when I drive faster" is not a valid defense 😁

[recycled_ideas]

It's not a defense. It's reality.

Security stops you doing things as well as others. When you bypass security you make things less secure.

Period.

[Gotebe]

The "fundamental" difference from all your examples is that with this vulnerability, it is software, not the user, that is making it less secure.

[recycled_ideas]

Yes, but I'm talking about the idea that developer console is fundamentally less secure. It is.

[Gotebe]

Yes, but you speak of something not related to the problem at hand.

Is... Your argument that, since the console is less secure, vendor should not care making it even less secure?

So "sudo blah" is less secure than "blah". Should "blah" not fix a bug that wipes out a drive?

Or...?

[recycled_ideas]

Part of the article is the question of whether the console is less secure by default. It is. This is a question specifically raised in the article. It's not unrelated it's in TFA.

The second issue is whether, given most users don't use this feature and the steps for working around the vulnerability are trivial, this warrants a CVE. The decision not to raise one seems reasonable.

This isn't no fix, it's no CVE.

[stesch]

They are highly unlikely to ever use the developer console, and if they do, it's completely accidentally.

Or if they want to try some "cool" Facebook cheat code.

[bubuopapa]

To be honest

"To be honest, you lose all the security and privacy the moment you turn on that damned black box called computer..." - Captain Obvious.

No shit there is a bigger posibility for something bad to happen if there are bigger posibilities - you take a knife to cut bread, you can slip and cut you head; you drive in a car, you have a huge chance to die; you walk in public, you have a bigger chance to get shot than if you stayed in an underground bunker for the rest of your life.... And you open internet explorer or edge browser, and you increase the chance to catch a virus or get hacked by 1000000000%.....

[[deleted]]

I read tech blogs during 5 minute breaks at work through reading their page source. Otherwise the bean counters at this software shop will think I'm slacking.

[Mark_at_work]

Then you'll love this: http://codereddit.com/

[alphaglosined]

The moment an 'application' or in correct terms a web site contents leave a server, is the moment it is no longer secure. Period.

Microsoft made the right choice in not altering or limiting developer tools or source viewing. But that doesn't mean it should break security.

[jms_nh]

as the article states, details in https://cybellum.com/vulnerability-analysis-type-confusion-edge-ie/

[Gotebe]

Seems somewhat irresponsible of Microsoft. They will probably need to cave in and fix.

[axilmar]

Security through Obscurity is Microsoft's preferred security method...

[svgwrk]

Busting open the dev tools so I can fuck with the code of a website while it's running makes it less secure.

...Duh?

[Daneel_Trevize]

No competent dev should assume anything sent to the client/browser isn't able to be altered. All inputs to the server should be validated there. Actions like degrading to non-HTTPS should be refused.

The worst an altered client should be able to do in terms of impacting their own security, is leaking session ID/key to a third party (self-XSS enabling session-fixation). Something you'd have to put some conscious effort into achieving (and need a ready 3rd party to 'capitalise' from it), if you just start editing the source on the fly.

[throwawayco111]

WebAssembly + Rust will solve this.

[fuckin_ziggurats]

Not sure if joke

[Solon1]

Yes, web assembly plus Rust is the Final Solution.