Identity Shield question

By default WSA doesn't protect regular HTTP sessions via Identity Shield thoroughly (tampering with browsers modules/code injection is allowed, no "padlock" is present).

Let's imagine this situation (focusing solely on Identity Shield)- malware X is present on system, it waits for the user to launch browser, when browser is loaded user navigates HTTP links (i.e (most of) Identity Shield/padlock not active), while user is on HTTP links malware x injects persistent .dll module in browser memory which has the ability to modify webpages and intercept user data (MITB basically) without any additional communication with other components of malware x (.dll is standalone).
Within the same browser session (browser memory compromised) user enters HTTPS site, with the Identity Shield/padlock now active and protecting the browser.

Would WSA perform a retroactive integrity check of browser memory to see if there are any unknown modules already running in such cases?

When I tested it, it didn't seem to unload the injected 3rd party .dll, however I don't know if that .dll is known/trusted by WSA and thus not unloaded or if WSA just doesn't perform such checks...

 

It should be "jamming" the data indipendently from injections as it is designed to prevent keylogging and screengrabbing in presence of running malware.

 

If so, it's commendable that WSA can isolate untrusted modules running inside the browser from getting data and not "jam" the entire browser itself in the process.

 

I have the feeling that what you ask is something else (i.e. different ways to protect the browser). It requires a re-design of the mechanism and its objectives. Isolation, blockage is what you commonly find in most security tools from security suites to sandbox software.

The objective of ID is not to purely isolate or block but to feed with obfuscated data or null data anything in-between reading the screen or monitoring the keyboard. The end result is the same but the means not

I think we are going too much into technical details of the protection and before I talk too much "bullsh..." PREVXHELP should chime in.

 

If the user starts with an HTTP website and later changes to an HTTPS website, WSA's protection is still equally strong. It won't unload DLLs entirely but it will prevent them from intercepting data or stealing information, so, no matter which sequence you used to log in, you'll be protected