[Laszlo-dev] serverless operation

P T Withington ptw at pobox.com
Wed Jan 19 10:04:23 PST 2005


It's only a danger if you do no sanity checking on that data.  A huge 
number of security flaws in Windoze are of this nature:  you have a 
string buffer that you fill with externally supplied data and you don't 
make sure the data fits...

The simplest security expedient for preventing such flaws is to prevent 
you from loading externally supplied data.  Dumb but secure.  Security 
always comes at the expense of usability.

On 19 Jan 2005, at 11:21, Adam Wolff wrote:

> I've never understand the "danger" in loading data from a different 
> domain. Don't write your app to do that if it's a security risk.
>
> A
>
> P T Withington wrote:
>> On 18 Jan 2005, at 17:33, Sarah Allen wrote:
>>> Tucker,
>>>
>>> This approach sounds appealing, but I'm afraid it would be 
>>> confusing.  Its true that the proxied/serverful operation is there 
>>> to make up for limits in the runtime; however, that same limited 
>>> runtime makes for a confusing experience.  For example, to use a 
>>> "serverless" connection to get data from another site, you need to 
>>> make sure there is a cross-domain xml file.  Depending on whether 
>>> you control that other site, you may or may not want to use a 
>>> proxied connection in this case.
>> I don't follow that.  Whether you are proxied or not, you will want 
>> to vet data that you get from 3rd party sites.  If you are proxied, 
>> you can do that in the server.  If you are not, you have to do it in 
>> the client.  In either case, you will have to write the code to vet 
>> the data; just having a proxy doesn't magically make 3rd-party data 
>> safe.
>> Different runtimes are likely to have different rules about whether 
>> an app can access 3rd-party sites.  A proxy can be used to subvert 
>> that policy.  For this reason, I think it is actually dangerous to 
>> have proxied be the default.
>>> I think it would be easier to understand if the normal case is for 
>>> the whole app to be proxied or not.
>>  From a security point of view, I think it is more dangerous to turn 
>> proxying on for all accesses, unless you replicate the security 
>> policy of the runtime in the proxy.  The security principle of least 
>> privilege suggests that only accesses that require proxying should be 
>> proxied -- then you only have to think about the security 
>> implications of those accesses, rather than of all accesses.
>>> Sarah
>>>
>>> At 01:14 PM 1/18/2005, P T Withington wrote:
>>>> Can we step back a minute?
>>>>
>>>> Isn't it the case that the purpose of proxied/serverful operation 
>>>> is to make up for limitations in the current runtime -- operations 
>>>> that the current runtime does not support (rendering png's) or 
>>>> permit (access to other than the originating site) are handled on 
>>>> the server instead?
>>>>
>>>> Is there some advantage to making all your operations be proxied if 
>>>> you just need one?
>>>>
>>>> It seems we already have a switch implemented:  If you are 
>>>> compiling an LZX form that the target runtime does not support, the 
>>>> compiler should compile it to a proxied version (perhaps with a 
>>>> warning) if available, otherwise signal an error.  It seems that 
>>>> the only need for a proxied/unproxied switch is to silence the 
>>>> warning that you used a form that requires a proxy for the target 
>>>> runtime.
>>>>
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> Laszlo-dev at openlaszlo.org
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> Laszlo-dev at openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev



More information about the Laszlo-dev mailing list