HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Displaying articles for: February 2011

Top Ten Web Application Vulnerabilities 1/31/2011 - 2/21/2011

1) IBM Lotus Domino iCalendar Meeting Request Parsing Remote Stack Buffer Overflow Vulnerability


IBM Lotus Domino is susceptible to a remote stack buffer overflow because of a failure of the application to properly validate user-supplied input. Successful exploitation can give an attacker the means to execute arbitrary code with SYSTEM-level privileges, possibly leading to a complete compromise of the affected computer. Failed attempts will likely lead to a denial-of-service condition.  As of this writing, a fix has not yet been released. Contact the vendor for further details.




2) HP OpenView Performance Insight Server 'doPost()' Remote Arbitrary Code Execution Vulnerability


HP OpenView Performance Insight Server is susceptible to a remote code execution vulnerability. If successfully exploited, an attacker can execute arbitrary code with SYSTEM-level privileges and completely compromise the vulnerable system.  Updates which resolve this issue are available. Contact the vendor for additional information.




3) Xerox WorkCentre Webserver Unspecified Remote Command Execution Vulnerability


Xerox WorkCentre is susceptible to a remote command execution vulnerability because of a failure of the application to properly sanitize user-supplied input.  An attacker can leverage this vulnerability to execute arbitrary commands with the privilege of the web server. Updates which resolve this vulnerability are available. Contact the vendor for further details.




4) Ruby on Rails Multiple Vulnerabilities


Ruby on Rails is susceptible to multiple vulnerabilities including Cross-Site Scripting, Cross-Site Request Forgery, SQL Injection, and HTTP Header Injection. Cross-Site Scripting can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. 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. Cross-Site Request Forgery relies on a browser to retrieve and execute an attack. It includes a link or script in a page that connects to a site that the user may have recently used. The script then conducts seemingly authorized yet malicious actions on the user’s behalf. HTTP Header Injection can be used to insert arbitrary data into the affected HTTP header field, possibly leading to HTML Injection, ross-Site Request Forgery, Cross-Site Scripting, and other attacks. Updates which resolve these vulnerabilities are available. Contact the vendor for further information.




5) Adobe ColdFusion Multiple Vulnerabilities


Adobe ColdFusion is susceptible to multiple vulnerabilities including Cross-Site Scripting, session fixation, and CRLF Injection.  If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Victims who are enticed into visiting a malicious URI can have their session hijacked and give an attacker unauthorized access to the application. CRLF Injection can be used to  add arbitrary headers to a web page, possibly leading to more damaging attacks. Updates which resolve these vulnerabilities are available. Contact the vendor for more details.




6) Hitachi Tuning Manager Unspecified Cross-Site Scripting Vulnerability


Hitachi Tuning Manager is susceptible to a Cross-Site Scripting vulnerability. Arbitrary script code can be executed in context of the affected site in the browsers of unsuspecting users if this vulnerability is successfully exploited.  Updates which resolve this vulnerability are available. Contact the vendor for further details.




7) IBM Rational Build Forge 'fullcontrol/' Cross-Site Scripting Vulnerability


IBM Rational Build Forge is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage Cross-Site Scripting 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. Updates which resolve this vulnerability are available. Contact the vendor for additional information.




8) Apache Tomcat HTML Manager Interface HTML Injection Vulnerability


Apache Tomcat is susceptible to an 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 resolve this vulnerability are available. Contact the vendor for further details.




9) IBM Rational Team Concert 'Report Name' Field HTML Injection Vulnerability


IBM Rational Team Concert is susceptible to an HTML Injection vulnerability.  This can be leveraged by an attacker to retrieve cookie-based authentication information, deface the site, or execute arbitrary code in context of the site.  Updates which resolve this vulnerability are available. Contact the vendor for more details.




10)Bugzilla Multiple Vulnerabilities


Bugzilla is susceptible to multiple vulnerabilities including several instances of Cross-Site Scripting and Cross-Site Request Forgery. Cross-Site Scripting can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. Cross-Site Request Forgery leverages the trust a web application places in a user to make authenticated requests to a target site for which the user is logged in, and can be used to abuse any type of functionality the target web application contains. Updates which resolve these vulnerabilities are available. Contact the vendor for further information.



WebInspect checks for Java and PHP 'mark of the beast' Denial of Service attacks

It was recently disclosed that PHP was susceptible to Denial of Service (DoS) attacks because of the way certain numerical values that contain a large number of decimal places were being handled (specifically, the way they were being converted to a double-precision binary floating-point caused the application to freeze). Colorfully labeled the 'mark of the beast,' PHP architects fixed the vulnerability within roughly 48 hours of its disclosure. That's not too shabby.


It turned out, though, that a similar bug also exists in Oracle's Java programming framework. Considering how many web applications rely on Java, this bug is particularly nasty in that it can cause a web site to crash with minimal effort on the part of an attacker.  Normal DoS attacks involve overflowing a buffer, or sending an inordinate number of requests that effectively clog the server to the point of unresponsiveness. Neither of those scenarios is remotely as easy as submitting a numeric value with a specific number of decimal places in a field in an application (what OWASP calls an ‘application level DoS attack’). Both Java's runtime and compiler are prone to these attacks.  While this issue isn't technically new, it has drawn a huge amount of attention. It's almost a certainty that we'll see a rise in the number of these attacks. Oracle has already released a patch, but it will likely be some time before it is widely deployed.


Luckily, WebInspect now tests for the presence of both the PHP and Java versions of this vulnerability. Simply SmartUpdate to receive the new checks. While detecting these vulnerabilities is a good start, it's also not enough if you haven't yet applied the fixes. In that case, considering utilizing HP Fortify's Real-Time Analyzer (RTA) tool to block any potential attacks. It can reside on a .NET or Java server and block any potential attack via its specific signature (and already includes signatures for these attacks). While the 'mark of the beast' attacks are simple and effective, that also makes them easy to counter when you have the right strategy in place.


For more information on Fortify's response, read their blog post, Java Double-precision Parsing Denial of Service.


For more information on these vulnerabilities, visit Java Hangs When Converting 2.2250738585072012e-308.


Note: Since these are Denial of Service attacks and could potentially cause harm to production systems, by default they are not included in WebInspect’s Standard scanning policy. The Assault and All Checks policies are among the WebInspect policies that contain these checks. You can also manually add each check to a custom policy via the Policy Manager. The information for each check follows:


10988 - Java Double-precision Parsing Denial of Service

11200 - PHP Double-precision Parsing Denial of Service

Fortify on Demand...now with WebInspect

Security is hard.  It takes dedicated professionals to get it right, and many organizations have unfortunately learned this the hard way. That's not saying developers or QA professionals can't learn application security, and be effective at it. It is saying that it's almost impossible to do everything you have to do to be successful at application security when it's your secondary area of focus. There's just too much to learn. Be assured, hackers live and breathe security, and so do the best application security professionals.


This is one of the main reasons there has been explosive growth in the Software as a Service (SaaS) security approach. For a lot of organizations who don't have the resources to do it right, it offers the most effective and beneficial solution. If you can't do it in-house, why not hire the best to do it for you?


While on that topic, there's a new SaaS security offering poised to take it to the next level. Fortify on Demand now combines the two best complimentary technologies on the market...Fortify's static code analysis and WebInspect's dynamic run-time analysis...to provide one comprehensive solution no other security services company can match. We've already seen what benefits the "hybrid analysis" combination of static and dynamic application testing can bring to an organization.  But when that's also combined with in-depth application security expertise? Watch out.


For  more information, visit  Fortify on Demand.


And for some great perspective on what this means for the future of HP's Application Security Center, see Rafal Los's post  1+1=3...Fortify On Demand Takes a Step into the Future.




Super Bowl XLV, Christina Aguilera, and Web Application Security Metrics

Las Vegas bookies are great at unearthing creative metrics for starved Super Bowl bettors to place wagers on.


Standard bets surround metrics such as the total number of points scored (commonly called the over/under), how many points the game was won by (the point spread), the total number of turnovers, how the first touchdown was scored, and on and on. If a wager can be placed, friendly Las Vegas bookies will provide the opportunity to make them. In fact, here are all kinds of proposition (or side) bets as well as the more standard bets. Will a player be arrested before the Super Bowl? Will Ben Roethlisberger actually be arrested during the game? The over/under for Christina Aguilera's rendition of the national anthem was 1:56, for example. (I would definitely have taken the "Over" on that one, and would have won...). Next year they will probably add a lyrics-botching side bet.


So the bookies have established a set of metrics, easily trackable, to which bettors have attached value.


We in application security have done a less thorough job. Sure, appsec teams can use their dynamic scanning tools to count vulnerabilities, or make a rough determination of vulns-per-application. However, such metrics are at best inexact, considering that dynamic scans  rarely achieve 100% application coverage, and that false positives are always a risk across the scanning spectrum, from static to dynamic. It's unfortunately the nature of the beast. In any kind of vulnerability count, defect-per-application ratio, or defect-per-1000 lines of code metric, the metric is only as good as the data underlying it; if 20-30% of an application goes unscanned, or if false positive (or false negatives) are significant, metrics quality suffers.


Even if these statistics were based on perfect data, it's unclear what value they would provide, as they don't relate to business risk. To the business, some vulnerabilities are more important than others. It sounds obvious, but merely counting vulns and categorizing  by vulnerability type does not help an organization prioritize remediation efforts.


Returning to the Super Bowl, one could argue that the final score over/under has real business value for the NFL, as casual fans really enjoy watching high-scoring games. Conversely, tracking Aguilera's over/under (ahem!), fun as it is was, had no material effect on the NFL's business. Our challenge as an industry is to do less Aguilera-tracking, and provide metrics that actually lead to real risk reduction. Instead of raw counts of vulnerabilities, we need to prioritize the data to provide real value to organizations with limited resources to deploy when remediating vulnerabilities (as HP's Rafal Los has described most excellently).


Because when you're betting on your application security, you really can't afford to lose. 


Tips and Tricks: Adding Manual/External Vulnerabilities to WebInspect

For WebInspect 8.1


Security professionals frequently conduct manual PEN testing in addition to performing automated security testing with WebInspect.  When new locations and vulnerabilities are found, the question becomes “How do I make WebInspect include these vulnerabilities in the scan results?”  There is currently no easy way to do this (stay tuned to future releases), but it can still be done, assuming the vulnerability is tied to a specific location.  


Step 1 – Setup

I performed a “Crawl Only” of HP’s public test site, zero.webappsecurity.com and turned off “Discovery (Path Truncation), which is an option on the 4th step of the scan wizard. Turning this option off will artificially reduce the coverage of the site.  For this example, I want to demonstrate a location that was missed during a scan, but which can be found manually.  Notice that the “Stats” directory is not listed in the “Site Tree” (the area on the left). This directory would normally be found by an audit probe, but since the scan was configured as a crawl only then the Stats directory was missed.




Step 2 – Manually add the location

Next, I’ll use “Step Mode” to add the missed location to the scan.  Follow the steps below on using Step Mode.


1.            Click the Step Mode bar.

2.            Enable recording by pressing the red button.

3.            Click the Browse button.

4.            Type the URL to the missing location, or use the browser to navigate to the location if the location requires multiple steps before it can be accessed.

5.            In the Step Mode window uncheck all the undesired locations and click “finished”.






Step 4 – Add a custom vulnerability

Now that the location exists in the “site tree” you can right click it and select the “Add Vulnerability” option.  Once the dialog is displayed you can click the “Add Custom” button and specify the severity and description of the custom vulnerability. Each time the “Add Custom” button is clicked then a new vulnerability is added to the location.  The newly created vulnerability will be viewable in all the standard locations that the other vulnerabilities can be seen (reports, vulnerability grid, etc…).



Additional TIP – Adding your own vulnerability to a location that is already vulnerable

If you would like to add a vulnerability to a location that already exists and has vulnerabilities, select the “Edit Vulnerability’ context menu item to launch the same dialog described above. 

From this dialog you can also modify WebInspect reported vulnerabilities.  This could be useful if there is specific information you would like to include for the vulnerability when you generate a report.





I hope you found this topic helpful.  I plan to continue a series for WebInspect tips and tricks.  If there is a topic that you feel would be helpful, please feel free to email me directly at brianmiller@hp.com.

Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.