Thanks John, Two more questions
(1) what protocols will the proxy work for? i.e. will it only proxy http/https requests or would it work for other protocols if the server supports them? For example, http://gadgetserver/gadgets/proxy/?url=file:///var/log/httpd-access.log Gives a blank 200 response (thankfully), but it does take a significantly long time to load (it takes 30 seconds of cpu time to hadle the response on our development server) - could a malicious user use such a feature to perform a DOS attack by hitting a file that is known to be large (logs etc.)? Two requests a minute could tie up one core. we don't do much PHP or Java here, so I haven't even tried finding the relevant code. (2) is the proxy prevented from hitting local addresses like localhost or should I configure rewrite conditions against such an address (to prevent access to server status pages etc) - haven't really got anything to test against on this box. Thanks, Tim Wintle On Thu, 2008-10-23 at 17:32 -0700, John Hjelmstad wrote: > Tim: > I'll try to give a high-level summary of issues here - feel free to dive > deeper on any. > > First off, as you intuited, the open proxy is essentially a requirement for > gadget hosting, irrespective which server you use, due to the same-domain > browser security policy, enforced on virtually all current browsers. > > The proxy is limited (locked-down) in a few ways: > 1. Most importantly, the proxy only serves content from the host(s) that the > gadget renderer does, which must be domain-isolated from those serving > privileged content. eg. foo.gmodules.com rather than foo.google.com, or > foo.hi5modules.com rather than foo.hi5.com. > > 2. Content served by it is served with a Content-Disposition:attachment; > header. This helps prevent phishing attacks primarily as well as "gadget > XSS" when rendering gadgets on locked domains. > > 3. Content size is limited to 1MM bytes. > > 4. JS responses are prepended with unparseable cruft to for instance prevent > <script src> attacks. > > 5. Some installations may choose to apply additional Referer checks to proxy > requests. > > In addition to these, many sites have general-purpose systems for detecting > overuse by given referers, IP (range)s, etc. But those aren't part of > Shindig. > > Anyone on the list, please feel free to add more if I've missed anything. > > --John > > > On Thu, Oct 23, 2008 at 3:45 PM, Tim Wintle <[EMAIL PROTECTED]>wrote: > > > Hi, I've got a question regarding security issues: > > > > The proxy features obviously expose an open proxy on the server. > > The config files just say: > > > > // Note: /proxy is an open proxy. Be careful how you expose this! > > > > What does this comment mean - surely this is required for gadgets.io, so > > what can we do to lock this down? On the other hand, I don't feel > > comfortable letting an open proxy live on our servers. > > > > Am I missing something? > > > > (I've decided to use the php server for the time being) > > > > > > > > > > > >
