Hi, apologies for the question, but I’m struggling to find anything on google thats specific to what I want.
I want to know how you can ensure that only client side javascript gets actioned on a page.
The example is a jsfiddle style page.
Can anyone supply any links or recommend any books that might give me a basic overview of how to ensure that any javascript run is only client side.
Or am I asking the wrong question…
Is there a particular problem that you are wanting to prevent?
@Paul_Wilkins Malicious injection of code effectively.
Basically I’m making a sandbox like jsfiddle mainly for myself but I may open it out at a later date to other people. I would like to do what I can to ensure that the code that’s executed from that Form / iframe is client side only to stop (as much as is possible) the security flaws inherent from doing such a thing. I read that the way some sites do this is by ensuring that only client side javascript is run therefore server side is “somewhat” safe?
I realise that its not going to be easy to secure this kind of thing completely, but I would like to do what little I can initially to segregate the two sides of the coin if you understand me
I believe that if you load the script in to a sandboxed iframe, that will do a good job of protecting you.
Some details about this can be found in How to Safeguard Your Site with HTML5 Sandbox
@Paul_Wilkins Interesting reading, though this seems to block some of the things I need and javascript seems to be on or off as oppose to being local only.
I will read up a bit more on it, thanks for the link.
The sandbox attribute can be configured to allow JS while blocking cross-frame access (so the iframe document can’t access the parent page).
But it sounds to me like you want something to stop Ajax requests, is that what you’re getting at?
In which case, you might be able to just override the function:
window.XMLHttpRequest = function(){ return null; };
Or maybe set it to undefined:
window.XMLHttpRequest = undefined;
Or even delete it:
delete window.XMLHttpRequest;
Not sure if that would work, you’d have to try it. Check Safari and IE particularly which might not be happy with overriding native objects.
Hmm no its not ajax specifically. I think the problem is I don’t know what I need to do 
its basically a jsfiddle sandbox. I just know that if I open this up ‘as is’, it would be a security hole the size of the moon. Currently its ‘same domain’, ‘javascript allowed’ and is dynamically updating an iframe (by JS, i.e. $('#iframe').contents().find('body').html(html);). I think the only way I am going to be able to secure this is make it cross domain, which means the dynamic updating of the html will break (in its current form). I think I understand now why that functionality isn’t in a lot of these sandbox type tools 
However I could then try and do this by ajax I suppose. I am going to have to do some more research, but I thank you for your help.
iframe sandboxing does seem like a good option though, actually … I wonder if this does even block it 2 way. I will give this a try tonight … it might be “cross fingers” that the sandbox option only blocks child to parent on same domain … that would be ideal.
The sandbox attribute will block all cross-frame communication, irrespective of domain. It effectively implements the cross-domain security policy for all domains, as though the iframe page were on a different one.
For the application you’re talking about, that’s not gonna be any good – if each “window” within the fiddle is a different iframe, then you need cross-frame access to make it work at all.
I think the first thing you need to do is identify exactly what the security risks are. It sounds like you don’t have a clear idea of what you’re trying to prevent, just a general sense that security risks exist. If you could establish a better sense of exactly what you want to allow and what you want to block, then you’ll have a good starting point for working out how to do it.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.