Is there a way to secure either the ISAPI filter or the other components, without modifying the code?
What I'm looking for is a scoped construct that looks something like this:
<sec:security xmlns:sec='http://xplusplus.sourceforge.net/security/1.0'>
<sec:assert id='system/database/select'/>
<sec:assert id='system/database/update'/>
<sec:refuse id='system/database/delete'/>
<xpp xmlns='http://xplusplus.sourceforge.net/core/1.0'>
<!-- secured code lives here -->
</xpp>
</sec:security>
Initially, a security XML fragment is constructed from a file with the system-wide security policy. This is probably actually a folder with multiple files, so that extension libaries can copy in default policies without having to edit the contents of the master policy.
Each time a security block is entered, the current working copy is pushed onto the stack. Each time a security block is left, the current working copy is popped from the stack.
Assert runs an XPath query against the security document. If the selected node indicates the permission should be allowed, execution continues. Else, execution is aborted.
Refuse updates the node(s) indicated by the XPath and disables the appropriate right(s).
Because a namespace is used to encapsulate the extension, existing parsers/interpreters will continue to run the script (albeit at full permissions). Interpreters that know about the namespace will be able to process the extension's semantics.
The issue with not having this comes from multiple trust levels. Take an XML document that is using XLink to embed part of a common XML library on internet for use with Xpp.
There needs to be a way for the server to say "these are the maximum permissions that I will give you." The first tier, local scripts, need to be able to further restrict these permissions for possible calls to code not residing on the local server. In turn, those calls need to be able to further restrict the access.
There should not be any capability to activate rights -- you can only disable rights as you move down the tree.
When a new right is defined in user code, it should be defaulted to granted. The code can then take that right away. In no case should a user code be allowed to reside under the same tree that the system code resides in, if that makes sense.
It sounds like a real pain, I know, but right now, if I install this, anyone on Internet can send a script to my server, which could reference any number of other scripts on internet, which could reference any number of other scripts on internet, and that seems like an open invitation for a security-based attack.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also just a quick note -- in my mind, it would be better to have code like:
<db:connection xmlns:db='http://xplusplus.sourceforge.net/database/1.0"/>
Than:
<dbconnection/>
The advantage to using the namespace is that a plug in system can use reflection to determine the namespace that the plug in wants to handle, and a simple STL map can map namespaces to handlers.
When you want to upgrade the core from version 1 to version 2, you write a plug in to handle the new changes, put it where it belongs, and by virtue of the reflection the system can locate it, and process it.
It isn't the only way to handle things, but it makes extensions, etc., pretty easy and if you encourage people to use a valid URL for the namespace identifier, and to have that URL identify the extension, it makes it much easier to locate the documentation for a particular extension or extension(s).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a way to secure either the ISAPI filter or the other components, without modifying the code?
What I'm looking for is a scoped construct that looks something like this:
<sec:security xmlns:sec='http://xplusplus.sourceforge.net/security/1.0'>
<sec:assert id='system/database/select'/>
<sec:assert id='system/database/update'/>
<sec:refuse id='system/database/delete'/>
<xpp xmlns='http://xplusplus.sourceforge.net/core/1.0'>
<!-- secured code lives here -->
</xpp>
</sec:security>
Initially, a security XML fragment is constructed from a file with the system-wide security policy. This is probably actually a folder with multiple files, so that extension libaries can copy in default policies without having to edit the contents of the master policy.
Each time a security block is entered, the current working copy is pushed onto the stack. Each time a security block is left, the current working copy is popped from the stack.
Assert runs an XPath query against the security document. If the selected node indicates the permission should be allowed, execution continues. Else, execution is aborted.
Refuse updates the node(s) indicated by the XPath and disables the appropriate right(s).
Because a namespace is used to encapsulate the extension, existing parsers/interpreters will continue to run the script (albeit at full permissions). Interpreters that know about the namespace will be able to process the extension's semantics.
The issue with not having this comes from multiple trust levels. Take an XML document that is using XLink to embed part of a common XML library on internet for use with Xpp.
There needs to be a way for the server to say "these are the maximum permissions that I will give you." The first tier, local scripts, need to be able to further restrict these permissions for possible calls to code not residing on the local server. In turn, those calls need to be able to further restrict the access.
There should not be any capability to activate rights -- you can only disable rights as you move down the tree.
When a new right is defined in user code, it should be defaulted to granted. The code can then take that right away. In no case should a user code be allowed to reside under the same tree that the system code resides in, if that makes sense.
It sounds like a real pain, I know, but right now, if I install this, anyone on Internet can send a script to my server, which could reference any number of other scripts on internet, which could reference any number of other scripts on internet, and that seems like an open invitation for a security-based attack.
Also just a quick note -- in my mind, it would be better to have code like:
<db:connection xmlns:db='http://xplusplus.sourceforge.net/database/1.0"/>
Than:
<dbconnection/>
The advantage to using the namespace is that a plug in system can use reflection to determine the namespace that the plug in wants to handle, and a simple STL map can map namespaces to handlers.
When you want to upgrade the core from version 1 to version 2, you write a plug in to handle the new changes, put it where it belongs, and by virtue of the reflection the system can locate it, and process it.
It isn't the only way to handle things, but it makes extensions, etc., pretty easy and if you encourage people to use a valid URL for the namespace identifier, and to have that URL identify the extension, it makes it much easier to locate the documentation for a particular extension or extension(s).