The safety net
Thursday, 4 February 2010
I was thinking about how to prevent a user being exploited lately by whatever method. One thing most attacks have in common is that a user generally needs to initiate the attack by clicking on a email or web site link from a social network. There’s a obvious pattern here. Granted some attacks are conducted on the application itself an XSS worm or network worm for example but these aren’t as common as the majority of attacks that require some form of initiation.
My solution? The safety net! When your average joe clicks on a link from twitter, they usually want to watch a funny video or something. Using this to it’s advantage the safety net detects when this happens, it is aware of the context of a email for example or that this particular social network is quite popular. When a user clicks a link from that context the browser doesn’t need to send any cookie related information from anywhere whilst in the “Safety net”.
It acts as a sandbox for the user protecting them from bad stuff, the user should be aware that they’re in it and should not be able to browse like normal unless they open a new window in the traditional means. It could also work for phishing, prompting the user not to enter any confidential information or maybe disabling form input completely except for whitelisted sources. Corporations could configure their safety net to be more restrictive, a policy for disabling javascript for example or maybe only allowing Flash to play video and not execute actionscript.
If anyone thinks this idea isn’t too crazy and decides to implement it here are a couple of suggestions I’ll refer to the Safety net as SN:-
1. Whilst in the SN any executed javascript or other code should always remain in the SN.
2. New windows or frames should not be allowed in the SN.
3. The browser should look different in the SN to inform the user that they are in a more restrictive browsing experience.
4. Closing the SN should be the only way out of it and the user must be clear that is what is happening.
5. Form input could be restricted in the SN.
6. Session data or cookies should not be transferred from/to the SN.
7. ANY form of download should not be permitted in the SN.
8. Third party plugins should only be allowed in restricted mode for example a PDF file should have a restricted mode which many features are disabled like javascript. Only if this mode is enabled would the PDF be allowed to execute.
9. Full screen mode should be prevented.
10. In the SN it is equivalent of opening the browser for the first time.
Additionally I suggest a meta tag to identify social networks:-
<meta name="identify" content="Social Network" />
No. 1 — February 15th, 2010 at 5:32 am
This is exactly what the web needs, I dare say I have thought of something of this kind myself, however there is the question of how this would fit the kind of old “new trend” of having the user manipulating their own data ( or data of their friends / etc .. ) from one application inside another ?
Therefore, there should be an ability to have a list of outside inputs or URL-s which are “trusted” and “accepted” sources in the context of any concrete safety net.
No. 2 — February 15th, 2010 at 8:07 am
@Robert
The idea would be to only enable the SN when a specific action is taken like clicking on a link that takes you to a external web site, the SN is decided depending on the meta or http header of the parent site. For example twitter should have a meta identify as Social Network.
This would allow sites to function as normal but prevent exploitation by limiting the user’s “first click”