RE: XSS security vulnerability - anyone found a workaround yet?

[Richard Hauer]

Hi Kelly,

 

While I’m sure there are myriad vulnerabilities in the CMS I’m not sure why it matters.  The CMS is an internal-use tool – it is protected by your corporate firewalls and policies; it is not public-facing as is de rigueur with many CMS these days.  Therefore, it is at minimum risk of attack, since it would have to have come from inside the corporate network.  One might think that if one could compromise the internal network there would be bigger prizes than the CMS or the website, no?

 

Or have I entirely missed the point??

 

Rgds,

Richard H.

 

From: reddot-c...@googlegroups.com [mailto:reddot-c...@googlegroups.com] On Behalf Of Kelly Burns
Sent: Tuesday, 18 September 2012 12:35 AM
To: reddot-c...@googlegroups.com
Subject: XSS security vulnerability - anyone found a workaround yet?

 

Hi guys - I am sure somebody has run into this before; but I am at a complete "dead end" here and need to resolve before our upcoming IT Audit. :(

 

Our IT Audit firm found our Web Site Management Server 10.1 SP2 (with SQL 2008 db) poses a "significant security risk", in that it allows cross site scripting (aka "XSS") to occur in the classic ASP portions of the app.   Obviously I need to correct this before our *next* audit (next month). 

 

Last September, when the audit found this info, I submitted this as a ticket for resolution to OpenText Support. They said they would forward the issue to development for analysis (this was a year ago).    I realized I'd not heard back from them on this issue & checked back on it this week.  The response was:

 

"This ticket was linked to a BUG ID: WSGMS-8216 currently there is no resolution or much analysis on the issue, but it is now tracked by OpenText and you can always use the aforementioned ID to track its status."

 

I searched all over OpenText KB for the bug, but it is not even listed anyplace that I could find. I was hoping that surely somebody has had the same issue and posted a workaround somewhere by now.  :-( Well if it exists, I still haven't found it! 

 

Has anyone else dealt with this??  If what if anything did you do to secure RedDot properly?

 

Thanks in Advance!

Kelly

 

 

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/reddot-cms-users/-/oc1eLUNtT2UJ.
To post to this group, send email to reddot-c...@googlegroups.com.
To unsubscribe from this group, send email to reddot-cms-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.

[Kelly Burns]

Hi Richard -I'm replying back via email to explain.  Thanks, Kelly

[Jian Huang]

Hi Kelly,

Most part of Management would first validate the current user session before allowing additional functions.  However, there might be areas that do not verify that.

There is something a system administrator can do in IIS by only granting access to certain page should the request comes from localhost (127.0.0.1), which is initiated from an asp page that verifies login session.

http://support.microsoft.com/kb/324066

For example:

addfile.asp calls uploadfile.asp

uploadfile.asp is vulnerable to XSS should the correct parameter be provided.

Locked down uploadfile.asp via IIS by only grant it access should request comes from 127.0.0.1.

Since addfile.asp validates user session, then user would have to be able to login in order to use the functionality.

Besides, it takes 7 to 8 specifically named parameters to correctly invoke any .asp pages in CMS.

-Jian

[Kelly Burns]

Thanks Jian!  I'm going to pass this to my boss and see what he says. 

Thanks again!
Kelly

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/reddot-cms-users/-/yQ34iuPHUtoJ.

[Kelly Burns]

Hi again Jian - The boss said to let it slide; he'd rather fix it with a patch update.   So I'll keep my eyes on this board for whenever an update comes through that corrects the XSS issue (hopefully soon tho!)

Thanks again!
Kelly

Kelly Burns

Associate Director

Web Applications / IT Dept.

Alzheimer's Association

T:  (312) 335-5209

F: (888) 869-1439

E: kbu...@alz.org

On Mon, Sep 17, 2012 at 12:55 PM, Jian Huang <jhuangs...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.

[Boris Crismancich]

Hi Kelly,

I'd like to stress what richard said about a lot more security vulnerabilities. If a security specialist takes a closer look at the system, he will find a lot of different ways for acessing or even manipulating Data. In my opinion there's two most important rules: 1st: Secure the system against illegal acces. Put the system into a DMZ and use Firewall rules, IIS and maybe Proxy capabilities for securing the system. I remember there's a KB article regarding ports. 2nd: If necessary, protect the system against the most severe attacks from registered users. In previous times, the Windows user used as identity for processes started by CMS, was member of the admin group and had full access to the sever. You can limit this user's rights, so that only the files relevant for cms can be executed, deleted or changed where necessary. Hteres a KB article about that, too. Look for "windows user". In this case, IIS rights should be secured following common IIS security concepts, too. Doing that, you can prevent illegal access or manipulation of data via Script injection (asp, CGI or other Script Code). In my eyes, it is not possible to achieve a fully secure system though.

Kind regards,

Boris

[Joel Kinzel]

I have to back up everyone else here. Security cannot lie entirely on the application. It takes both application and server security measure to have a "secure" environment. If you're not willing to make adjustments in server settings to secure an application, then that is something you've made a conscious not to do, and are therefor assuming the risk of an exploit happening. As a developer I can write an application that is really secure, but if the server isn't set up properly to compliment the security provided by the application, then there isn't much more I can do. I would strongly encourage you to re-think and consider Jian's suggestion if you are truly worried about this. 

[Tim D]

Any customer can ask support for updates at any time. I see these are to be fixed in these patches:

 

MS 11.0 SP1 HF1, MS 10.1 SP2 HF18