HP Application Security Center Community

Web Application Security - Creating Awareness

RafalLos — Tue, 16 Sep 2008 15:08:00 GMT

You can preach.

You can threaten.

You can send links to articles from the Wall Street Journal's front page.

... but until it happens to someone your company is in direct competition with, no one listens. Of course, the minute a data breach happens in a competing company, or someone that's directly in your line-of-business it's drop everything and go protect us from this imminent threat!

Why is that? I've been racking my brain on this for such a long time now that I've all but given up. It's not that your CEO doesn't care about web application security (because he/she doesn't, honestly...) but rather it's not an imminent threat until it happens to someone *you know*. Hrmm.... so then it hit me. We think the exact same way! No one thinks life insurance (there's that parallel again) is important, until your friend or close family member dies suddenly at 35, leaving wife and children flat broke. At that point you'd pretty much buy any life insurance someone throws at you, right? Exactly the same principles guide business.

So, my friends, the trick is to create awareness ahead of the tragedy. Because the big problem is... what is YOU'RE that guy that kicks it at 35 with the wife and kids? Your friends will be motivated but it's too late for you. I've said it before - you can't buy life insurance when you're dead... there are amazing parallels between what we do in security and the insurance industry (particularly life insurance, because of the finality of data breaches). There was a recent article released by SC Magazine from a survey that was conducted...Even though this survey is almost a year old - the same things resonate with us today and I would assert that they're even more real today then they were October 2007. Perhaps the most telling quote from the article is this one -

"Agreeing with the outcome, Joel Camissar ANZ country Agreeing with the outcome, Joel Camissar ANZ country manager for Websense said IT managers are currently taking the fall for security breaches blaming inefficient education at the C-level management." (SC Magazine)

Fascinating that a lack of understanding by the CEO can lead to a loss of your job when things go south. Of course, pointing the finger back at the CEO and saying "See, I told you this would happen" isn't worth anything if you don't have anything to physically back that up. This brings me to the point of this post - creating awareness is crucial.

Creating awareness of web application security issues is absolutely crucial to succeeding, and keeping your job as an Information Security/Risk manager. Your awareness campaign must have a solid foundation, some regulatory basis, and some great sensational news articles to back you up. Write up a very short business-case for your proposal - creating a holistic web application security program. Write it up with the following components - and submit it to upper-management as if it was just another business project. Odds are someone will listen. And while it may not have the CFO throwing money at you right away, at least it'll raise some awareness... hopefully.

Business Need [Why your business needs a web application security program] - Include things like the number of applications being driven over the web. Include metrics and hard numbers of the number of records, types of data, and value of that data that is publicly accessbile [read: hackable]. Provide metrics on who's been hacked, how many records stolen, what it cost them and how it impacted their business - use only business-cases relevant to your company's line-of-business
Regulations & Industry Best-Practice - Yes, dig up those PCI regulations, HIPPA line-items about data protection and other regulations that relate to data protection and information responsibility along with proper risk-management.
Clip Articles - Grab a few articles off the front-page headlines. That always gets management's attention... talk about how a small amount of spend ($200k over 12 months, or whatever) could have saved $120MM in fines, and other balance-sheet losses.

Try it... worst case, start making 3 envelopes.

Top Five Web Application Vulnerabilities 9/2/08 - 9/14/08

mark.painter — Mon, 15 Sep 2008 20:10:00 GMT

1) Joomla! Multiple Remote Vulnerabilities and Weaknesses

Joomla! is susceptible to multiple remote vulnerabilities which are exploitable via a browser. Remote attackers can leverage these issues to conduct phishing attacks, redirect victims to attacker-controlled sites, and send unsolicited spam. Other attacks are also possible. An update which addresses these issues has been released. Contact the vendor for more details.

http://www.securityfocus.com/bid/31103/

2) Google Chrome Remote Denial of Service Vulnerability

Google Chrome is susceptible to a remote denial of service vulnerability because of insufficient sanitization of user supplied input. Attackers can exploit this issue to deny access to legitimate users. An update which addresses this issue has been released. Contact the vendor for further information.

http://www.securityfocus.com/bid/30983

3) @Mail and @Mail WebMail Multiple Cross-Site Scripting Vulnerabilities

@Mail and @Mail WebMail are susceptible to multiple Cross-Site Scripting vulnerabilities. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. Fixes which address these issues have not yet been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/30992

4) Horde Application Framework Forward Slash Insufficient Filtering Cross-Site Scripting Vulnerability

Horde Application Framework is susceptible to a Cross-Site Scripting vulnerability. This vulnerability can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. Updates which address this issue have been released. Contact the vendor for further details.

http://www.securityfocus.com/bid/31107

5) phpAdultSite CMS 'results_per_page' Parameter Cross-Site Scripting Vulnerability

phpAdultSite CMS is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. A fix for this issue has yet to be released. Contact the vendor for more information.

http://www.securityfocus.com/bid/31057

Case Study: Right vs Right Now in a Big Company

RafalLos — Tue, 09 Sep 2008 02:01:00 GMT

As stated in a previous entry, I'm going to break down some of the [nameless] case-studies I've got in my notebook over the last several months.

As a note, if you read one of these and think it's you... feel free to tell me if I've missed a point or two.

A few weeks ago I had the pleasure of talking to a very intelligent security lead for a major us-based company that deals with *a lot* with your personal, credit and medical information. What I found out as we started talking about application security and their approach to it - was that this particular person was very interested in actually securing their web applications whereas the business was just happy to check the PCI and HIPAA boxes and move on. The classic problem ensued - how does this security leader successfully implement a security program when his or her business has absolutely no interest in doing "the right thing" but instead is interested in doing the "right now" thing? I know this isn't really a revalation to anyone because this is a common problem. What makes this case unique to me is the context of this problem, namely - where it's occurring. I wish I could simply tell you the company but that would be almost completely irrelevant.... the only thing that's important here is that this problem exists.

So now we're faced with a problem. IT Security wants to drive better code, no doubt there. Development only cares about release cycles being faster and "more streamlined" so naturally this means that tools aren't an easy sell, and there is a large QA organization that load-tests and moves on. Yikes. Interestingly enough, there is a thing to be learned here, my security lead contact is approaching this brilliantly and I wanted to document this for the benefit for you, the other readers.

We've all heard someone say (and if you've been to a seminar of mine, you've heard me say it) that a security program isn't just implementing tools and checking a box. While I whole-heartedly agree with that, there are approaches where someone who is strapped for cash, manpower, and security intelligence can kick-start their security program by implementing some basic SDLC [Software Development LifeCycle] -integrated security tools. This is one of those approaches, I'd love to hear your comments either privately or via this blog.

Organizational Situation

The organizational structure is quite unique... the Security lead currently does not report to the head of IT, instead he or she reports under the legal/compliance branch of the company. Interesting situation wouldn't you say? That pretty much absolves the security team of operational duties and challenges... you would think. Not so much but there's definitely leverage to be gained there, I assure you. The security team is leading the charge on application security as a result of a PCI initiative (shocking) which is driving "check-the-box" exercise to implement some tool or process and move on. These are challenges a large number of the readers of this blog can sympathize with.

Tactical Component

In order to get things going, this organization has chosen to work with a "kick-start" type approach which builds a security program starting with what would appear to be the blunt end of the security stick. By implementing an enterprise "scanning" tool (in our case, AMP + WebInspect) to identify the *immediate needs* which exist in the production environment among the mission-critical web applications, they are goingn to use those metrics to demonstrate the need for a larger-scale approach to security web applications (there is much more to this, but this is the simple version). Using a combination of tools and professional application assessment services to demonstrate the immediate need the security leader can then use "right now" money which comes from the PCI Compliance budget to accomplish a basic check-mark for PCI and demonstrate a need for a long-term, SDLC-integrated security program. Collecting data and turning it into security intelligence (read: information) will make this component of the approach successful. The side-effect of this approach is that it uses money slated for a short-term fix to accomplish that plus plant a seed which will hopefully sprout into a full-scale enterprise security program in the future.

Strategic Component

As part of the initial purchase of licenses (tools, just tools) the security leader is also purchasing other pieces which further integrate into the enterprise SDLC, and plan the seeds of security among the different departments (development and QA) which traditionally have no interest in security. While it's in their best-interest to produce secure code (development) and identify security defects (QA), departments outside security don't traditionally think "security"... so these tools can demonstrate how simple it can be to produce secure code with minimal effort.

Executive Summary - Prognosis

Voila! Long-term strategy... which then starts to sprout policy, process, and education to create a real enterprise-grade web application security program. The program is *not based* on tools, but is built off of a foundation that bootstraps from some tools to get the initial gears moving. Like I've said all along, the program won't be built around tools - but the tools can be used to help kick-start a program that otherwise would have little chance of getting off the ground. I feel very confident that this particular security leader's approach will be successful, and may even get him or her promoted :)

* This is a specific case-study. If you'd like to hear more about how this potentially applies to your company, or how you can get help kick-starting a security program within your security-agnostic organization... pop me an email directly and I'll be happy to open a discussion.

Top Five Web Application Vulnerabilities 8/18/08 - 9/1/08

mark.painter — Thu, 04 Sep 2008 19:50:00 GMT

1) Novell Forum TCL Command Injection Vulnerability

Novell Forum is susceptible to a command injection vulnerability. Remote attackers can exploit this vulnerability via URL modification to execute TCL commands, possibly leading to compromise of the application and underlying web server. A fix has been released. Contact Novell for more information.

http://secunia.com/advisories/31578/

2) IBM WebSphere Application Server for z/OS HTTP Server mod_proxy_ftp Cross-Site Scripting Vulnerability

IBM WebSphere Application Server for z/OS HTTP contains a Cross-Site Scripting vulnerability. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. A fix has been released. Contact IBM for additional details.

http://secunia.com/advisories/31673/

3) Novell IDM Cross-Site Scripting and Script Insertion

Novell IDM is susceptible to an instance of Cross-Site Scripting. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. Field patches which resolve these issues have been released. Contact Novell for further information.

http://secunia.com/advisories/31678/

4) IBM Lotus Quickr Multiple Cross-Site Scripting Vulnerabilities

IBM Lotus Quickr is susceptible to multiple Cross-Site Scripting vulnerabilities. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. Fixes have been released. Contact IBM for more details.

http://secunia.com/advisories/31634/

5) IBM WebSphere Portal Server Authentication Bypass

IBM WebSphere Portal is susceptible to a server authentication bypass vulnerability. This vulnerability can be exploited to perform certain administrative actions via a specially crafted HTTP request without proper authentication. A fix has been released. Contact IBM for further details.

http://secunia.com/advisories/31443/

Attention App Sec Professionals in Ottawa and Montreal, Canada!

RafalLos — Thu, 04 Sep 2008 04:28:00 GMT

... we've got a workshop coming to Ottawa and Montreal coming in September. You read it right... I'll be up in Ottawa, CA on Sept. 22nd, and Montreal, CA on Sept. 23rd giving 2 feature-packed workshops that you can't afford to miss if you have a stake in the web application security space. I've included some of the details below, obviously please contact me or Luc Laforest (see below) directly to get going and sign up... hope to see you there!

[ Workshop Brief ] Are you interested in Web Application Security? Have you ever wondered how the "black hats" break into web applications so easily? These topics and more will be covered when we take a trip down the rabbit hole, and dig deep into the many sides of web application security. We'll cover everything from attack methodology, security best-practices, defense in-depth, and yes... some real-world hacking! I will also talk you through building a holistic web application security program with tips from real-world successes aimed at helping you accomplish your goals. Come join us, bring your questions, concerns and curiosity - you won't be disappointed!

[ Topics Covered ]

Latest hacking techniques from "the real world"
News, commentary and Information from the world of web application security
Defensive coding techniques to avoid being tomorrow's news
Business-level thinking on building a holistic web application security program
Benefits of integrated security tools as part of a complete SDLC [Software Development LifeCycle]

[ How to Register ] Send an email to Luc Laforest (luc.laforest@hp.com) with the date you'd like to attend, and some of your business-card information and we'll get you signed up! These events are at NO COST to you, zero, zip, zilch, nada, niet, nic.

[ Who Should Attend ] Security professionals, developers, IT managers responsible for web applications and IT Security professionals. Basically - if you have an interest in securing web applications, you need to be here.

[[ Ottawa, CA ]]

September 22nd, 2008
Hotel Indigo Ottawa
Indigo Room
123 Metcalfe Street, Ottawa, ON K1P 5L9
(613)231-6555
http://www.ottawadowntownhotel.com/
Lunch and Registration 12:00-12:30
Presentation 12:30-2:00
Break 2:00-2:15
Presentation 2:15-3:30
Q & A 3:30-4:00

[[ Montreal, CA ]]
September 23rd, 2008
Hotel Place D'Armes
St. Jaques Room
55 St-Jacques Street
West Old Montreal, Quebec H2Y 3X2
http://www.hotelplacedarmes.com/
Breakfast and Registration 8:30-9:00am
Presentation 9:00-10:15am
Break 10:15-10:30am
Presentation 10:30-11:30am
Q & A 11:30-12:00

Obstacles to Building a Successful Security Program [part 1]

RafalLos — Thu, 04 Sep 2008 03:04:00 GMT

Since February, I've been traveling and meeting with IT Security leaders, CISOs, Program Managers and other folks in charge of application security for their business and a few themes have recurred. I'm fascinated by the differing scenarios and situations that security leaders are placed in but it's even more interesting to know that many of you are in the same boat.

It's clearly *not* that security leaders don't want to build well-integrated, holistic application security programs, that much is certain. The problem is no one that these security leaders report to *cares*. It's just baffling how many of you are faced with a compliance exercise, client requirement, or some internal need for "proof that application security is done" but have so little power to actually do anything more than the bare minimum.

I guess it's telling of the times we live in, and perhaps also indicative of the state of the world economy when we are asked to forgo the "strategic" and chase the "tactical" solutions. None of you will argue that the tactical solutions [one-time code reviews, single point-solution tools, etc] is a good idea but this is what you're required to execute on, and then move on to the next fire-drill item. It's enough to drive a person mad.

Well... I know of at least a few of you [and hats off to you, you know who you are] that are finding ways of making the long-term, strategic and holistic programs work in your business. It clearly takes some creativity and guts - but you're doing it. I'm going to, over the course of the coming days, document some of your endeavors, the struggles, the failures and successes - names will be left out to protect the innocent, of course. Now would be a good time to pay attention folks... there are some real lessons to be learned here, and maybe you can use something and take it back to your business or career and build off these stories. Until next time...

Passive Scan Policy Available for Download via SmartUpdate

mark.painter — Tue, 19 Aug 2008 20:40:00 GMT

The HP Web Security Research Group has released a new policy geared towards "passive" scanning of an application. Passive scanning of an application means that no actual exploits will be attempted, making the assessment safe to perform against production servers. Vulnerabilities detected by this policy include issues of path disclosure, error messages, and others of a similar nature. To download the policy, simply click Smart Update in WebInspect.

Top Five Web Application Vulnerabilities 8/04/08 - 8/17/08

mark.painter — Mon, 18 Aug 2008 18:25:00 GMT

1) Alcatel-Lucent OmniSwitch Products HTTP Header Remote Buffer Overflow Vulnerability

Alcatel-Lucent OmniSwitch products are susceptible to a remote buffer overflow vulnerability. An attacker can leverage this issue to execute arbitrary code within the context of the affected application. Failed exploits will likely result in a denial of service condition. Fixes which address these issues have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30652

2) Multiple WebmasterSite Products Remote Command Execution Vulnerability

Multiple WebmasterSite products are susceptible to a remote command execution vulnerability. Remote attackers can exploit this vulnerability to execute arbitrary commands within the context of the affected application, possibly leading to compromise of the application and the underlying web server. Fixes have not yet been released. Contact the vendor for further details.

http://www.securityfocus.com/bid/30572

3) Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting Vulnerability

The Apache 'mod_proxy_ftp' module is susceptible to a Cross-Site Scripting vulnerability. Cross-Site Scripting is caused by insufficient filtration of user supplied input, and can be used to steal cookie based authentication credentials and conduct other attacks. Fixes are available in the SVN repository. Contact the vendor for more details.

http://www.securityfocus.com/bid/30560

4) Adobe Presenter Multiple Cross-Site Scripting Vulnerabilities

Adobe Presenter is susceptible to multiple Cross-Site Scripting vulnerabilities. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. An advisory which addresses these issues have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30615

5) JBoss Enterprise Application Platform Information Disclosure Vulnerability

JBoss Enterprise Application Platform is susceptible to a remote information disclosure vulnerability. Information obtained from successful exploitation may aid in further attacks. Updates which address this issue have been released. Contact the vendor for further information.

http://www.securityfocus.com/bid/30540

Top Five Web Application Vulnerabilities 7/21/08 - 8/03/08

mark.painter — Mon, 04 Aug 2008 18:34:00 GMT

1) Sun Java System Web Server 7.0 Plugin for Sun N1SPS Remote Authentication Bypass Vulnerability

Sun Java System Web Sever 7.0 plugin for Sun N1 Service Provisioning System (N1SPS) is susceptible to a remote authentication bypass vulnerability. An attacker who leverages this vulnerability could gain unauthorized administrative access to the web server. A fix and advisory which addresses this issue has been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30451

2) EMC Centera Universal Access 'username' Parameter SQL Injection Vulnerability

EMC Centera Universal Access (CUA) is susceptible to a SQL Injection vulnerability. SQL Injection can allow an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. A patch which addresses this issue has been released. Contact the vendor for more information.

http://www.securityfocus.com/bid/30358/

3) Panasonic Network Cameras Error Page Multiple Cross-Site Scripting Vulnerabilities

Panasonic Network Cameras are susceptible to multiple Cross-Site Scripting vulnerabilities. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. Updates which resolve these issues have been released. Contact the vendor for further details.

http://www.securityfocus.com/bid/30460

4) Multiple Century System XR Routers Cross-Site Request Forgery Vulnerability

Multiple Century System XR routers are susceptible to a Cross-Site Request Forgery vulnerability. Cross-Site Request Forgery leverages the trust a web application places in a user to make authenticated requests that appear completely legitimate, and can be used to abuse any type of functionality the web application contains. Updates which resolve this issue have been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/30344

5) Mobius Web Publishing Software Multiple SQL Injection Vulnerabilities

Mobius Web Publishing Software is susceptible to multiple instances of SQL Injection. Successful exploitation could give an attacker the means to access or modify backend database contents, or in some circumstances be utilized to take control of the server hosting the database. A fix has not yet been released. Contact the vendor for more details.

http://www.securityfocus.com/bid/30382

Building a Web Application Security Program Without a Budget

RafalLos — Tue, 29 Jul 2008 20:12:00 GMT

As promised, I'm writing up the first segment of implementing a web application security program without having to spend (or add spend to) your own budget. The current economic conditions are stiffling technology investments and security programs aren't much better off than they were this time last year. In fact... security's budgets have shrunk. I know, no one reading this is shocked.

What I am going to give you some support no here in this first piece is gathering the information you need not to have to spend anything. This is quite simple, but rarely done I assure you.

First thing you should do is infiltrate the opposition. In case you haven't noticed, critical business functions rarely get their budgets cut so in order to get the same type of treatment you have to learn what they're doing differently than you. Follow these simple steps, and you'll be one step closer to program success.

Identify the heads of each of the following departments within your organization:

Fraud
Risk
Legal
Compliance

Ask them for their list of initiatives for next year and beyond
Ask them to identify which of those initiatives have a "Web application" component
Sit with them in their office at least once to understand their priorities, and reasoning behind those priorities
Provide feedback for each web application-related component to identify "security needs"
Confer with the owner/sponsor (person whom you sat with) to ensure those needs are "baked into" their budget estimates
Add each of those projects identified in #6 to *your budget* with a dollar-amount of zero (insert reference to #6 above for clarity)

Alright. There you have it. These are the steps that I've personally successfully used in the past, and I know that this works a good majority of the time across a wide range of companies and industries.

Now that you've got this gameplan ahead of you... you may need some coaching on how to position your requirements to the various department heads for step #6 in the process. I'll detail some of those tricks next.

File Upload Vulnerabilities (it's your own fault)

RafalLos — Tue, 22 Jul 2008 05:56:00 GMT

Hi folks, I've been reading a lot on the c99madshell, and have come to a very simple conclusion. Scripts that take over your server and make it do inappropriate things can be often avoided by simply appropriately managing your file-upload capabilities within your web application.

That being said, here are a few pointers for you web-masters and requirements gatherers when it comes to file-upload capabilities. Heed the warning, lest ye become like this Princeton site:

Are file-upload capabilities absolutely necessary on your site or web application?
If yes - then create a white-list of file types you want to upload (xls, doc, gif, etc)
Avoid allowing uploads of server-file-types (such as .jsp, .php, .html, etc)
Always save files uploaded outside the document root of a directory so they can't be immediately browsed (easily)
Virus-scan uploaded file content (think trojaned .gif files, or poisoned .pdf files)

There you have it. A white-list combined with a black-list, some requirements-gathering intelligence added in for flavor, and plain old webmaster know-how, and you'll be invulnerable to most of thse drive-by file-upload-and-hack scripts like c99madshell and many, many others. Now if your servers were all patched...

Top Five Web Application Vulnerabilities 7/7/08 - 7/20/08

mark.painter — Mon, 21 Jul 2008 20:03:00 GMT

1) Microsoft Outlook Web Access for Exchange Server Email Field Cross-Site Scripting Vulnerability

Microsoft Outlook Web Access (OWA) for Exchange Server is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. An advisory and updates which address this issue have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30130

2) Xerox CentreWare Web Multiple SQL Injection and Cross-Site Scripting Vulnerabilities

Xerox CentreWare Web is susceptible to multiple SQL Injection and Cross-Site Scripting vulnerabilities. If exploited, these vulnerabilities could lead to compromise of the application, the theft of confidential information and authentication credentials, or be utilized in conducting additional database attacks. A fix has been released. Contact the vendor for further details.

http://www.securityfocus.com/bid/30151

3) Sun Java Web Start Multiple Vulnerabilities

Sun Java Web Start is susceptible to multiple vulnerabilities including buffer overflows, privilege escalation and information disclosure issues. The user must first visit a malicious page before these vulnerabilities can be exploited. An attacker who leverages these issues could execute arbitrary code, or read, write, and execute arbitrary local files in the context of the user running a malicious Web Start application. This could result in a compromise of the underlying system. Information obtained from the information disclosure vulnerabilities would also likely be utilized in orchestrating further attacks. Fixes which address this issue have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30148

4) IBM Maximo 'debug.jsp' HTML Injection And Information Disclosure Vulnerabilities

IBM Maximo is susceptible to an HTML Injection and information disclosure vulnerabilities. HTML Injection is used to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. Information obtained from the information disclosure vulnerabilities may aid in further attacks. A fix has not yet been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/30180

5) Adobe RoboHelp Server Help Errors Log SQL-Injection Vulnerability

Adobe RoboHelp Server is susceptible to a SQL Injection vulnerability. SQL Injection can allow an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. A fix which addresses this issue has been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/30137

St. Louis, MO - Web Application Security Workshop

RafalLos — Thu, 17 Jul 2008 05:21:00 GMT

7.17.08, 12:38am CDT...
Airport delays are a horrible way to finish out a business trip... just puts such a bummer on everything. As you can tell if you're reading this, it's after midnight and I just got home and unwound. My flight was supposed to leave St. Louis, MO at 6:46pm... suffice it to say we never left on time because of an O'Hare "ground stop"... which was due to heavy storms rolling throug the area. Well, when all the waiting, and uncertainty, and sitting on the tarmac and waiting and in-flight turbulence was over and we landed... wouldn't you have guessed it - not a drop of rain to be found at O'Hare... lovely.

I'd like to extend a very hearty thank you to everyone who participated in Wednesday's workshop in St. Louis, MO. It was a pleasure having everyone there, and getting so much participation from the audience. It really makes the flight delays and prep time well worthwhile when you all provide a 2-way conversation rather than me just speaking and showing powerpoint slides. I welcome feedback, questions, comments and requests for follow-up - I do these for groups large (like Wednesday) and small (in a more intimate setting with your company) and we always manage to have a good time and maybe on occassion learn something.

So once again - thanks for coming, thanks for staying over an hour extra to hear about all the exciting stuff we here at the Application Security Center [HP ASC] have going on.

Cheers & safe travels.

/Rafal

Security Program vs. Shrinking Budget - Part 1

RafalLos — Sun, 13 Jul 2008 06:25:00 GMT

Greetings readers, it's been a while since I wrote up an article - but I've been busy I assure you. I've been gathering up information for the series you're about to read over the coming weeks.

As I travel and speak to large enterprises at the starting stages of implementing web application security programs, I've noticed a trend in the types of challenges CISOs and security program leaders face. While the questions are asked slightly differently from place to place, the enterprise profiles are different, the applications are different - everyone is asking the same thing. CISOs and web application security program leaders are desperate to know how they can implement their fledgling programs with little or no budget.

I know, you're reading this thinking - "we have the same exact problem"... and I'd like to say that I have an answer for you. While it's not going to work 100% of the time, and there is still some work for you to do - I do have the answer.

Think of it- what if you could build a program that has the PPT (People, Processes, Tools) you wanted, without any of the budgetary requirements. What if you could do it without putting a single additional penny into your budget?

Stay tuned. I'll show you how.

Top Five Web Application Vulnerabilities 6/23/08 - 7/06/08

mark.painter — Mon, 07 Jul 2008 20:43:00 GMT

1) Novell Groupwise WebAccess Simple Interface Cross-Site Scripting

Novell Groupwise WebAccess is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. A patch which addresses this issue has been released. Contact the vendor for additional details.

http://secunia.com/advisories/30839

2) HP System Management Homepage (SMH) for Linux and Windows Cross-Site Scripting Vulnerability

HP System Management Homepage (SMH) is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Fixes which address this issue have been released. Contact the vendor for further details.

http://www.securityfocus.com/bid/30029

3) phpMyAdmin Cross-Site Scripting Vulnerabilities

phpMyAdmin is susceptible to multiple Cross-Site Scripting vulnerabilities. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. A fix for these issues has been released. Contact the vendor for more information.

http://secunia.com/advisories/30813

4) Drupal Taxonomy Autotagger SQL Injection and Script Insertion

The Taxonomy Autotagger module for Drupal is susceptible to SQL Injection and Cross-Site Scripting vulnerabilities. If exploited, these vulnerabilities could lead to compromise of the application, the theft of confidential information and authentication credentials, or be utilized in conducting additional database attacks. A fix for these issues has been released. Contact the vendor for further details.

http://secunia.com/advisories/30933

5) Academic Web Tools SQL Injection and Cross-Site Scripting

Academic Web Tools is susceptible to SQL Injection and Cross-Site Scripting attacks. SQL Injection can allow an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. The Cross-Site Scripting vulnerability can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. Fixes which address these issues have not yet been released. Contact the vendor for more details.

http://secunia.com/advisories/30763

Input Validation Strategy - Black vs. White -listing

RafalLos — Thu, 26 Jun 2008 17:00:00 GMT

[This post is a little lengthy, but necessarily so. Get a beverage, sit back, and learn something]

I've recently spent some time in front of a group of development-oriented professionals and the talk I gave broke down at a certain point, and I felt like I needed to write this one up. What happened was not entirely unexpected but I was a little surprised at the tenacity of the group in their arguments. At one point I felt like I was going to be chased into the windmill by the villagers and burned... The good news is these developers were willing to listen which is all I ask for.

The debate over whether to default-deny or default-allow is one that extends well beyond the web application security world. In fact, this is a principle that's applied to the real-world all over the place. Night clubs, airport [in]security (*chuckle*), and many other examples of this type of methodology abound. Perhaps the quintessential example of default-deny (white-listing) is the operation of 99% of the world's firewalls. When we all started building networks we would block the bad stuff and allow everything. Over time (and quite quickly) we security folks realized we were getting beaten, badly, as the bad guys could come up with attacks faster than we could close off ports, so we changed our approach. The new approach was to default-deny everything and only allow what we knew was OK or supposedly semi-trusted. Over time this became the standard and now I feel it's time for the Web Application Development comunity to start thinking of this or face the harsh lessons (or continue to face those harsh lessons) like we firewall jockeys did back in the day. Let's first address the concepts, just to make sure everyone has the same baseline. The two main concepts at odds are white vs. black-listing for input validation and sanitization. A quick explanation of the two works like this:

Black-listing: Allow anything, and create a list (blacklist) of disallowed characters, or character combinations (typically done through a Regular Expression RegExpr)
White-listing: Disallow everything except for specifically identified character sets and combinations (typically done through a Regular Expression RegExpr)

Now that you have the basics down let’s cover the question of which is appropriate. Of course, everyone has their personal take on this topic but I honestly do feel like there is a right answer here. I’ll present the facts and will reserve my personal comment and recommendation for the end. Since most web applications are built with maximum user operability and compatibility in mind, blacklisting generally sounds like the immediate better idea. Immediately when validation is brought up to developers the question of complexity rears its ugly head. Why not just allow everything and have some “security device” (software, hardware, whatever) do the security checking? The simple answer to that question is this – if you rely on a 3^rd party “bandaid” device you’re in trouble from the start. Security must be done at the heart, in the belly of the beast, inside the application – where else does full knowledge of application content and context live? Having addressed complexity, and taking it as a given (some complexity addition is inherently necessary) we have to address the requirements of the application to figure out which method of validation is feasible. At the end of the day there is no one-size-fits-all solution to this problem. Each individual application must be analyzed and addressed page by page, form by form, field by field. The general rules still govern the task of validation though – simplicity is preferred. Always remember the KISS (Keep It Simple Stupid) principle when coding… or building anything for that matter. There are issues here which very realistically can make either option viable such as the need to input free-form text fields where a tolerance needs to be added (requires the characters < and > which are known to be used in XSS or Cross-Site Scripting) and when a name field will be accommodating Seamus O’Malley (the ‘ is a great SQL injection attack staple) comes up.

But think of it this way – pretend you own a night club (work with me here). You, the owner, hire a bouncer and tell him to monitor carefully who gets into your club. You start by saying no one in shorts and a T-shirt only to later find people on your dance floor wearing ball caps. You then add ball caps to the disallowed list only to notice sandal-clad patrons. You then add sandals to find cut-off jeans… and on and on. Finally you get annoyed and create a new policy, only people wearing formal dress-clothes are allowed in, everyone else stays out… this is a much healthier approach than trying to continually keep up with what the next unwanted trend is. This is identical in the development of web applications. You don’t want to spend your days and weeks into eternity trying to continually update your “blacklist file” with all the things that are disallowed, and building regular expressions to disallow them. You’re never going to be done, and there will always be some permutation of an attack that will slip past you.

By now the benefits of white-listing should be apparent – but what if you run into cases where a simple white-list isn’t appropriate? What if you do have to allow most-characters in the English character set? Are there cases where the only real and viable approach is to build black-lists? The answer to this last question is an emphatic yes. Just doing one or the other often either entirely fails, or becomes very difficult to work with. For example, if you have to include the greater-than (>) and less-than (<) characters – you should write regular expressions to make sure that those characters aren’t part of a script tag … right? My point is this – you’re never going to win trying to keep up with the hackers by building a black-list. I can personally guarantee you this. If you’re extremely lucky – and very good at security/programming – you may be able to hit a 30% effectiveness with black-listing. That’s still overwhelmingly poor… I would hope you understand that. But… in conjunction with a white-list that is well defined this could make your application not only safe today – but also future-proof your code. If Cross-Site Scripting (XSS) is what you’re worried about… then you can feel pretty safe is your server-side validator throws out any non numeric characters [0-9]. You can build code that is resilient to future attacks (not 100% future-proof, mind you).

So there you have it…the low-down on validation based on white/black-listing. Which is appropriate for your application? Only you and your security team will be able to determine that based on specification, functional requirements, and security need.

Finding SQL Injection with Scrawlr

erik.peterson — Tue, 24 Jun 2008 13:00:00 GMT

You have likely been tracking the mass SQL Injections that are currently sweeping through the net. Just last night I was shopping on www.ihomeaudio.com when I noticed they had been injected (they have since fixed their site). HP started to observe these attacks in January. They spread to over 500,000 sites by April before calming down and then picking up again in May. Most of the sites hit were initally Microsoft IIS ASP applications, causing many security companies to mistake this for some sort of new vulnerability in IIS and leading Microsoft to research the possibility, but alas, it's just our old friend, SQL Injection. Indeed we now see this attack hitting ASP and PHP sites and thanks to Google, it's easy to see just which sites out there have been hit.

While we were closely following the situation, the nice folks at Microsoft contacted us to see if we could work together to help people identify and cope with this issue. Together we quickly developed an action plan. The Microsoft Security Response Center (MSRC) was in a tough spot, hundreds of thousands of ASP sites were getting hacked, yet the vulnerability wasn't something Microsoft could release a patch for. SQL Injection is an issue that occurs because of poorly written web code interfacing with the web sites backend database and the solution was much more complicated than a simple patch. Developers were going to have to learn about security and were going to have to patch their code if they were going to solve this. Microsoft's Security Vulnerability Research & Defense has a blog about this problem as well where they share Microsoft's recomendations for this problem.

Now if you are no stranger to web security, you might be saying "well duh" right about now. Unfortunately to at least 500,000 sites on the Internet this concept is still pretty new and if you are one of the folks who are just now learning what SQL Injection is, I highly recomend you read HP's Web Security Research Group white papers on verbose and blind SQL injection located in our HP application security resource library.

Introducing HP Scrawlr

When Microsoft contacted us, they asked us to equip their customers with the tools necessary to quickly find SQL Injection vulnerabilities in their sites. HP's application security software, DevInspect, QAInspect and WebInspect all find SQL Injection and countless other security vulnerabilities. DevInspect can even inspect your source code for SQL Injection as well and guide developers through the process of fixing their code. But what if you need to just quickly look for SQL Injection before you decide how you are going handle the issue? We needed something quick, highly accurate and easy to download and install.

Scrawlr, developed by the HP Web Security Research Group in coordination with the MSRC, is short for SQL Injector and Crawler. Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr is lightning fast and uses our intelligent engine technology to dynamically craft SQL Injection attacks on the fly. It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!

Technical details for Scrawlr

Identify Verbose SQL Injection vulnerabilities in URL parameters
Can be configured to use a Proxy to access the web site
Will identify the type of SQL server in use
Will extract table names (verbose only) to guarantee no false positives

Scrawlr does have some limitations versus our professional solutions and our fully functional SQL Injector tool

Will only crawls up to 1500 pages
Does not support sites requiring authentication
Does not perform Blind SQL injection
Cannot retrieve database contents
Does not support JavaScript or flash parsing
Will not test forms for SQL Injection (POST Parameters)

Download Scrawlr

You can download Scrawlr by visiting the following link: https://download.spidynamics.com/products/scrawlr/

Scrawlr is offered as-is and is not a supported product. Assistance may be available from other Scrawlr users in our online Scrawlr forum located at http://www.communities.hp.com/securitysoftware/forums/198.aspx

You can learn more about the HP Web Application Security Group and the HP Application Security Center by visiting our Security Community site at www.communities.hp.com/securitysoftware/ or by visiting our product information page at www.hp.com/go/securitysoftware/

Top Five Web Application Vulnerabilities 6/09/08 - 6/22/08

mark.painter — Mon, 23 Jun 2008 20:15:00 GMT

1) IBM Workplace Unspecified Cross-Site Scripting Vulnerability IBM Workplace for Business Controls and Reporting and IBM Workplace Web Content Management are susceptible to an unspecified instance of Cross-Site Scripting. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. A fix has not yet been released. Contact the vendor for additional information. http://www.securityfocus.com/bid/29625

2) PHP 5 'posix_access()' Function 'safe_mode' Bypass Directory Traversal Vulnerability PHP is susceptible to a directory traversal vulnerability. Attackers can leverage this vulnerability to bypass ‘safe mode’ security restrictions and access data outside of the web root, possibly gaining access to sensitive information which could lead to more dangerous attacks. A fix has not yet been released. Contact the vendor for further details. http://www.securityfocus.com/bid/29797 3) Xerox WorkCentre Webserver Unspecified HTML Injection Vulnerability Xerox WorkCentre Webserver is susceptible to an unspecified HTML Injection vulnerability. HTML Injection is used to add content into a web server’s response, which can then be used to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. Updates which address this issue have been released. Contact the vendor for more details. http://www.securityfocus.com/bid/29689

4) Novell eDirectory iMonitor Unspecified Cross-Site Scripting Vulnerability The Novell eDirectory server iMonitor is susceptible to a instance of Cross-Site Scripting. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. Updates which address this issue have been released. Contact the vendor for additional information. http://www.securityfocus.com/bid/29782

5) DotNetNuke Prior to 4.8.4 Multiple HTML Injection and Cross-Site Scripting Vulnerabilities DotNetNuke is susceptible to multiple vulnerabilities including HTML Injection and Cross-Site Scripting. Successful exploitation of these vulnerabilities could be used to alter how the site appears, steal authentication credentials, or execute malicious scripts in the browsers of unsuspecting users. Updates which resolve these issues have been released. Contact the vendor for further details. http://www.securityfocus.com/bid/29686

Wrong Message, Wrong Audience

RafalLos — Tue, 17 Jun 2008 03:26:00 GMT

You're delivering the wrong message, to the wrong audience.

Don't believe me? Let's look at the attendance of workshops and conferences - now look at the message that's being delivered. I'm speaking of course specifically on web application security here. A recent article on Jeremiah Grossman's blog made me think, what do we (as security professionals, and industry "experts", do?) I feel like it's our responsibility to educate and bring the correct message to the people who will really benefit. Interestingly enough, I feel like we're failing to do this to any beneficial degree.

It's one thing to want to deliver software security as a message but an entirely different thing to deliver it to the right people who will actually benefit from the message. I honestly feel like I can't stress this enough.

I think it's wonderful that security is being preached at conferences all over the place, from quality to engineering of software to process management - but the real shortcoming is in who is hearing specifically which message. As a speaker I can tell you that if I deliver the same message to every audience it will be lost more often than it is understood. Tailoring the message is so important. "The message" can be what ever you're delivering on - for me it's mostly how to build better web-based applications resilient to subversion (otherwise known as "hacking") but again - this can be whatever you specifically are trying to convey.

In order to understand how better to deliver a talk with some punch the key is to understand the audience... I've taken my notes from the past several months of conference speaking and will deconstruct the audience for your benefit here...

Management - Of course managers to go conferences, workshops, and talks because every once in a while they feel the need to stay relevant. I can say this without reserve because I was there, and I know for a fact that most managers are so busy trying to make sure their teams are delivering that they often have very little time to do much else - and by the time they look up from their desks technology has passed them by and they are relics. The answer to this is to hit a conference every once in a while and hear what the topics of the day are - a wise choice indeed. The manager as a target audience is very complex but can be simply deconstructed as follows:

Goals: Understand the high-level message being delivered, the current topic and how it applies to their daily life as a steward of the business
Challenges: Unfortunately, being that few managers are really current on technical speak it's very easy to lose a mangement audience in the details, while they want to hear your message don't over-complicate it
Win-Win: Present the topic in a way that can both delivers your point without losing meaning while at the same time making it relevant to the manager's everyday work-life... a tricky thing, I know!

Developers - Developers are a rare gem at conferences where security professionals are speaking, sadly. Developers are keen on making stuff run faster, better, and making their lives less complicated. Notice that I didn't necessarily mention security in the stuff developers are keen on - it's our job as security folks to get them excited about writing secure code and getting them to come to conferences and workshops is a great start but the issue then becomes the way in which we deliver the message. I'll deconstruct developers here:

Goals: Learn the hot new "hacks" and cool code ninja skills which make them more marketable and give them greater ability to innovate and build something truly incredible with their code skills. Developers want to be able to write cool code, faster, and with less effort, period.
Challenges: As I've already pointed out, security doesn't often factor into the mind of a developer. We've been trying for years to change that and to some degree it's working but the percentage of security-conscious developers is still very, very low.
Win-Win: Developers aren't necessarily purposefully ignorant of security, just call it...agnostic. If we can find a way to make writing secure code less painful, and more... developer-centric they'll adopt our principles and everyone wins.

Security Professionals - Preaching to the choir, althoughit's often the choir which hasn't heard the message. I can't tell you how many times I've been in front of a security-oriented group presenting and they're looking at me like I'm a talking Polar Bear... seriously. Security professionals have a hard time keeping up with the technologies they support - it goes with the job - and so hearing something that's a niche piece is often intriguing but we have to find a way to make the message stick! Let's deconstruct a security audience...

Goals: Hear the message, learn the "cool hack" they can take back to their team/manager to feel like they're abreast of security. In security it's all about staying relevant and up-to-date and niche presentations attract security people like flies to honey.
Challenges: Quite simply put - the challenge with preaching to your own audience is that they see things in black and white. Security peers tend to see web application security in a binary fashion; secure or not. This creates a problem some of the time as if we deliver a strong message, say on a new AJAX vulnerabiltiy, the security staff can miss the forest (in this case the 'big picture' of security) for the trees (the specific new "hack") and actually do some reputational damage to themselves within the realm of corporate IT
Win-Win: IF we can provide the right amount of guidance with relevant knowledge we can spur security professionals to make better policies and serve their business better. The goal for us as speakers is to blend technology with intelligence to help mold the perfect security professional - one that is business savvy and security smart

"Engineers" - This is the catch-all category, as far as I'm concerned. These are the other people who don't necessarily fit into the stack above. You've got a mixed bag with this, and it's a challange to make it work, but I'll deconstruct this audience type thus:

Goals: Learn something, take it back and apply it to work - maybe, if it's relevant and applicable. (The secret is since we're talking security it's always applicable)
Challenges: Making security a relevant topic. How do you make web application security relevant to a generic group of IT people? Blend the right amount of technology (so as not to go over anyone's head) with the aspects of IT that make it important to just about everyone - make security "real" with examples from all different sources
Win-Win: The best-case scenario here is to make an impression on someone so that the next time someone says security - they flash back to your talk and recall the message you gave, and as a bonus attempt to apply that (or at least know where to get more information, and point someone there).

There you have it. I hope this has been helpful - so that the next time you're standing there in front of your audience you've got the right mindset and the right goals, challenges, and winning strategy.

Good luck!

WebInspect 7.7.869 Now Available

joe.yeager — Thu, 12 Jun 2008 11:00:00 GMT

An update for WebInspect is now available via SmartUpdate. The update includes some great changes which have been detailed below. Enjoy!

Improvements to the Regular Expression Editor
Optimized some functions for improved performance (language syntax application, syntax evaluation triggering points, etc).
Disabled match tree updates on match fill. Refactored control that contains text to test and disabled painting while highlighting. Improved test for validity of request/response templates.

Enhancements to the Cross-Site Scripting (XSS) Engine
Improved detection of Cross-Site Scripting vulnerabilities and improved consistency in stored Cross-Site Scripting detection. Improved accuracy of Cross-Site Scripting against Domino HTTP headers, as well as when filters are used to remove "alert" from the query string, in Header Injection, and in chain drop-down sites.

Significant SQL Injection Engine Improvements
Improved "diffing" technology for blind SQL Injection. Implemented data extraction for proving confirmed SQL Injection. Improved vulnerability categorization, and created a new check that is flagged when SQL Injection is confirmed but data extraction is not possible because of some limitations such as database not supported, database version does not support data extraction, et cetera.

Enhancements to the JavaScript Parser
Fixed a recurring error when parsing script out-of-process and enhanced the detection of forms in JavaScript so that more forms are found.

Improved Results for Web Brute
Integrated DiffEngine changes into Web Brute for improved results.

Stability Enhancements
Significant work was put towards closing a large number of outstanding issues. See the release notes for more details.

Miscellaneous Improvements
Additional enhancements include better handling of Proxy PAC files, Firefox Proxy support, and improved Oracle application support. Additionally, the "Manage Existing Scans" dialog now remembers its window size and position.

For additional details and a full list of issues resolved, check out the release notes.

- Joe

Misunderstanding the Purpose of Automated Tools

RafalLos — Wed, 11 Jun 2008 02:29:00 GMT

Let's get this out in the open - there is a misunderstood purpose of automated tools in web application security. Based on my personal experiences in front of both management and engineering teams in the last few months, I feel this needs to be addressed, and addressed now.

I know that as a vendor of tools, we would like everyone to use our wares to find and mitigate their web application security vulnerabilities - but no one here is dilusional. No one here in the HP ASC will ever tell you that buying/implementing our tools will give you total security for your web applications. No one here will ever advocate our tools as the sole solution to an enterprise web application security strategy.

So why do other vendors do it? More to the point - why is it that I am often asked the question... "So can you tell me if we implement (the HP ASC Security Suite, or some subset thereof) we will have secure web applications?" Still scarrier - why do people get upset at me when I answer them with a stout "No... our tools are but one part of a holistic strategy". Before you think that this can't possibly be anyone you know, or any manager you work for... think again. The list of places and teams that have posed this question starts in government, leads to the education sector and trails into large enterprises just the same.

I know there is some level of education that has to happen, and to some degree vendors are to blame for trying to sell "Magic Bullet" solutions at times to make the sale but the reality is no one piece of software will fix your web security woes holistically. Let me elaborate, and explain my case.

First, tools are just one piece of the security pyramid (People - Process - Tools). I've had that slide in my presentations as far back as I can remember presenting, and it's served me well but I do think it's time to preach that a little more emphatically. People and Process are the other two key factors to a successful web-app-sec strategy - without them the tools are of very little use. It's like having a 500Hp sports car with a nice manual gearbox and not being able to drive a manual and having no gas in the tank. Building a successful practice takes all 3 pieces of the pyramid to be well-established in order to function. While the *people* are the foundation of the whole pyramid, the processes and tools keep the pyramid from collapsing on itself. Without the other 2, no one piece can stand alone...

I'm writing a piece on the P-P-T (People/Process/Tools), but in the mean time ... this should give you something to think about. Let's just be clear one more time... no "tools" can solve the web application security problem holistically... but I will continue to argue that HP's ASC Suite provides the most comprehensive, most complete lifecycle solution out there, bar-none.

Top Five Web Application Vulnerabilities 5/26/08 - 6/08/08

mark.painter — Tue, 10 Jun 2008 14:13:00 GMT

1) Apache Tomcat Host Manager Cross-Site Scripting Vulnerability

Apache Tomcat Host Manager is susceptible to Cross-Site Scripting. If exploited, this vulnerability could give an attacker the means to perform account hijacking, execute malicious scripts, or steal proprietary information. A fix is available in the SVN repository. Contact the vendor for more information.

http://www.securityfocus.com/bid/29502

2) Sun Java System Web Server Advanced Search Mechanism Cross-Site Scripting Vulnerability

Sun Java System Web Server is susceptible to Cross-Site Scripting. An attacker can leverage this issue to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Fixes which resolve this issue have been released. Contact the vendor for additional information.

http://www.securityfocus.com/bid/29355

3) Xerox DocuShare Multiple Cross-Site Scripting Vulnerabilities

Xerox DocuShare is susceptible to multiple instances of Cross-Site Scripting. If successfully exploited, these vulnerabilities could allow an attacker to steal confidential information and cookie-based authentication credentials, and possibly lead to execution of arbitrary code in the browser of an unsuspecting user. A vendor-supplied patch has not yet been released. Contact the vendor for additional details.

http://www.securityfocus.com/bid/29430

4) Mambo Multiple Vulnerabilities

Mambo (prior to 4.6.4) is susceptible to multiple vulnerabilities including SQL Injection and HTTP Response Splitting. SQL Injection can give an attacker full access to a backend database, and in certain circumstances can be utilized to take complete control of a system. HTTP Response splitting can be used to break responses into multiple parts and conduct other types of attacks including Cross-Site Scripting and web cache poisoning. These issues have been resolved in Mambo 4.6.4. Contact the vendor for more details.

http://www.securityfocus.com/bid/29373

5) Sun Java ASP Server Multiple Directory Traversal Vulnerabilities

Sun Java ASP Server is susceptible to multiple directory traversal vulnerabilities. Successful exploitation would give an attacker the means to view or delete arbitrary files with the privileges of the web server process. Information gained through these methods would likely lead to more damaging attacks. Fixes which resolve these vulnerabilities have been released. Contact the vendor for more details.

http://www.securityfocus.com/bid/29538