On Fri, Oct 24, 2008 at 3:13 AM, Tim Wintle <[EMAIL PROTECTED]>wrote:
> 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. By default the proxy can access anything served under http(s). Adding a blacklist (or whitelist) is pretty trivial if you want to implement a custom HttpFetcher, for instance. Paul Lindner had a really good example of this using the apache commons HTTP client for the java implementation. The reason why this isn't baked in is that it's hard to say what's considered acceptable for any arbitrary deployment. > > > 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) > > > > > > > > > > > > > > > > > > > >
