Peter Cooper wrote: >What it does not do is compile the included file into a csp class >so no #()# <script language="cache" etc etc will work
I have not tested <script language=cache>, but as I wrote earlier, #(...)# *does* work, in both versions of include. >I cannot see that serve files is such a big security issue - it's all >controllled server side in the csp app - so if the app does not do >stuff then it wont happen This is not true. If the Serve Files flag is on, anyone with access to the app (logged in or not) can call %CSP.StreamServer directly; e.g.: http://example.com/app/_CSP.StreamServer.cls?FILE=/app/login.csp Note that this retrieves the *source* of login.csp, i.e., no parsing, rendering, or whatever is done. The app has no way to stop this (or even know about it), AFAICS. Although being able to see the CSP source code may not seem a big deal, it can reveal a lot about the workings of an app that an attacker can use. >if you include a <a href="some file.pdf"> then they could hack the >file directly without being logged on Yes. >with serve files="yes" you can put the library in a directory visible >to Cache but invisible to the web I don't know about this. %CSP.StreamServer takes either a FILE= parameter that denotes a file somewhere in the CSP tree, or a stream ID. If this stream ID makes access possible to files outside the CSP tree, the security risk would be even bigger, as I presume a hacker can easily generate such an ID for basically any file. (I haven't tested this, though.) If generated content needs to be protected, I'd use a custom stream server class to access it, and leave the Serve Files setting off. Gertjan. -- Gertjan Klein
