Content Server
NOTE: This only applies to sites hosted directly off of Site Studio; meaning, not published via the Site Studio Publishing Utility (SSPU).
If you don't know how content is secured within Site Studio, expand this:
In my experience, many places have a poorly designed security and metadata model (not to mention an un-normalized one). As a result, I have seen many implementations give the anonymous user (R)ead access to ALL security groups and the #all account. In my opinion, there is no chance that 100% of your content is "web ready" and insensitive by nature. Is it possible? Sure, but I'm more likely to be the Redskins' quarterback next year, so why expose your web site and content server unnecessarily?
What's my point in all this?
What if I were to say that I could obtain copies of your entire fragment libraries, along with your layout pages, and also know the names and email addresses of those who edited them?
How?
Anyone who has worked with Oracle UCM knows of idc services. Well, what's preventing them from executing a service call off YOUR content server as the anonymous user? Many services only need (R)ead access to be called, which the anonymous user has. Take a look at these snapshots off Oracle.com:
If you're not careful, your fragments and layout pages can also be at risk of being downloaded - there is such a thing as proprietary code, right? And no, setting "Allow get copy for user with read privilege" to false will NOT suffice.
There may also be instances when the anonymous user requires (W)rite access to the content server, such as calling the SUBMIT_HTML_FORM service. Allowing this kind of functionality means you have to be aware of anonymous users calling idc services that require (W)rite access! Sorry, no screenshot :)
So, are there ways to prevent all this? Absolutely, but it first falls on your security and metadata model. Afterwards, you can look to install the ExtranetLook component and also redirect unauthorized service calls. I've even implemented my own adhoc security solution, but I don't know what overhead there would be on high-traffic sites.
After reading this, you can argue that this is a "flaw" with the content server itself. That's true, but your content server probably isn't sitting within a DMZ and subjected to outside attack if you're not using Site Studio. So, how "secure" is your Site Studio site?
I certainly can't be the only one to have thought of this... right?
If you don't know how content is secured within Site Studio, expand this:
In my experience, many places have a poorly designed security and metadata model (not to mention an un-normalized one). As a result, I have seen many implementations give the anonymous user (R)ead access to ALL security groups and the #all account. In my opinion, there is no chance that 100% of your content is "web ready" and insensitive by nature. Is it possible? Sure, but I'm more likely to be the Redskins' quarterback next year, so why expose your web site and content server unnecessarily?
What's my point in all this?
What if I were to say that I could obtain copies of your entire fragment libraries, along with your layout pages, and also know the names and email addresses of those who edited them?
How?
Anyone who has worked with Oracle UCM knows of idc services. Well, what's preventing them from executing a service call off YOUR content server as the anonymous user? Many services only need (R)ead access to be called, which the anonymous user has. Take a look at these snapshots off Oracle.com:
If you're not careful, your fragments and layout pages can also be at risk of being downloaded - there is such a thing as proprietary code, right? And no, setting "Allow get copy for user with read privilege" to false will NOT suffice.
There may also be instances when the anonymous user requires (W)rite access to the content server, such as calling the SUBMIT_HTML_FORM service. Allowing this kind of functionality means you have to be aware of anonymous users calling idc services that require (W)rite access! Sorry, no screenshot :)
So, are there ways to prevent all this? Absolutely, but it first falls on your security and metadata model. Afterwards, you can look to install the ExtranetLook component and also redirect unauthorized service calls. I've even implemented my own adhoc security solution, but I don't know what overhead there would be on high-traffic sites.
After reading this, you can argue that this is a "flaw" with the content server itself. That's true, but your content server probably isn't sitting within a DMZ and subjected to outside attack if you're not using Site Studio. So, how "secure" is your Site Studio site?
I certainly can't be the only one to have thought of this... right?
No comments:
Post a Comment