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: October 2009

WebInspect Tips: Changing settings to improve scans

Although running WebInspect with ‘out of the box’ scans settings might be the easiest way to start a scan, it is almost sure to produce unexpected results. Configuring any web application scanner is tricky, but by following these simple steps to fine tune the scan more accurate results will be generated.


Know your website


Performing a manual assessment of your website (before using any tools) will help you quickly spot mis-configured scans, tweak scan configuration parameters, and ensure more consistent results.


The first step is to become familiar with the site topology - directory structure, the number of pages, submission forms, etc. Perform a manual site survey and take notes. If you have access to the source, look at the file structure. If not, hover over the menu links and notice the site structure of the URLs. Are URL parameters used to drive the site navigation? If so, record them and use them to drive WebInspect.


It is also important to have some understanding of how the site operates behind the scenes. Different websites tend to handle common administrative tasks in unique and unexpected ways. For example, some websites require users to re-enter their passwords and a pass a ‘captcha’ test before assigning a new password. Other sites allow a password to be changed simply by entering a new password.


Knowing the basics of the site mechanics will go a long way toward heading off mis-configured scans, and getting familiar with the layout of your site is the best way to help WebInspect cover the entire site.


Protect your data


Web application security tools try to force websites to accept input data that they may not have been designed to handle. Therefore one side effect of auditing a website for vulnerabilities is that ‘garbage data’ can be injected into the database. On a database-driven site (like most blogs or CMS systems), this junk data will show up in other unexpected and very visible ways. After a scan, you may find that your default website language has been changed to Farsi, test files have been uploaded, the new blog color theme has been set to ‘Early 80s Disco’, or 13 new users have been added – complete with nonsense test Posts.


To minimize theses risks, scan a non-production version of the target website if possible. Sometimes audits are necessary on a complicated production server setup.  If this is the case, make a backup of the entire production database and verify the ability to successfully restore it before a scan. 


Limit the scan


If the local server hosts multiple web applications, it is important to restrict the audit to the application of interest. For example, my local Apache installation hosts 12 web applications in the htdocs root folder. When I want to scan “Wordpress”, I often forget to restrict the audit, and end up with a noticeably longer scan time, and an unusually large numbers of vulnerabilities. A quick glance at the “site” tree in WebInspect will quickly show whether the scan has started crawling into folders that were not intended.


To prevent the scan from ‘running away’ (taking too long to complete), open the scan settings before the scan is launched, check the “Restrict to folder” option and select “Directory and subdirectories”. Take note: this option is not enabled by default, so this may be worth remembering. Also, make sure the start URL either contains a start page, or the initial directory ends with a trailing “slash”.


Login Macros


Login Macros are essential to correctly scanning a website, yet may unknowingly be the root of many failed scans. Before creating a new login macro to allow WebInspect to successfully gain entry to the actual site, choose a user with limited ability to modify the site. If one is not available, create a new user with the lowest role possible. For example, Wordpress allows 4 roles with varying degrees of ‘power’: Administrator, Editor, Author and Contributor. Scanning Wordpress as the Administrator user may result in any of several undesirable scenarios, including the destruction of the entire blog, while scanning as a ‘Contributor’ should only result in a few extra unpublished blog entries.


Check your login macros for errors during the scan. Often a login macro that is incorrectly recorded may fail to login to the site which causes the scan to produce invalid results. Symptoms include: abnormally short scan times, lack of vulnerabilities, or large numbers of errors in the error log.


Other times the macro may not be able to log back into the website during a scan – even after the first login has been successful. For example, login macros tied to a user account that is able to change its own password will prevent the macro from logging back into the site. Once this happens, the error log may fill up with errors and the scan may stop. It is important to monitor the scan periodically and assess the scan ‘health’.




Some users might be unaware of the unintended consequences of web application vulnerability scanning, while others users might need help understanding their scan process. Although these simple steps are not remedies to solve issues scanning complex sites, they will help rudimentary scans to produce more valuable results. The more information that is provided to WebInspect through the scan configuration settings, the better the outcome of the scan will be.

Top Five Web Application Vulnerabilities 10/12/09 - 10/25/09

1) TYPO3 Core Multiple Vulnerabilities

TYPO3 is susceptible to multiple remote vulnerabilities including SQL-injection, Cross-Site Scripting, information disclosure, frame and session hijacking, and shell-command-execution issues. Each of these issues is exploitable via a browser, although some might require a valid backend login. If exploited, these vulnerabilities could lead to a complete compromise of the application, the theft of confidential information and authentication credentials, hijacked user sessions, or execution of arbitrary commands in context of the web server process. Updates which resolve these issues are available. Contact the vendor for additional details.


2) IBM Rational RequisitePro ReqWebHelp Multiple Cross-Site Scripting Vulnerabilities

IBM Rational RequisitePro is susceptible to multiple Cross-Site Scripting vulnerabilities. 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. An advisory and updates which address these issues are available. Contact the vendor for more information.


3) Websense Email Security Cross-Site Scripting and HTML Injection Vulnerabilities

Websense Email Security is susceptible to Cross-Site Scripting and HTML Injection vulnerabilities. Successful exploitation of these issues 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 are available. Contact the vendor for further details.


4) Achievo Multiple Vulnerabilities

Achievo is susceptible to multiple vulnerabilities including Cross-Site Scripting, SQL Injection, and HTML Injection. Successful exploitation of these issues could be used to give an attacker the means to access or modify backend database contents, alter how the site appears, steal authentication credentials, or execute malicious scripts in the browsers of unsuspecting users. Updates which resolve these issues are available. Contact the vendor for additional information.


5) NaviCOPA Source Code Information Disclosure Vulnerability

NaviCOPA is susceptible to a source code information disclosure vulnerability. An attacker can leverage this vulnerability to retrieve certain files from the affected system in context of the web server process. A fix has not yet been released. Contact the vendor for more details.


Organizations are not adequately protecting E-health records

The American Recovery and Reinvestment Act of 2009 (aka the stimulus package) included funds to both implement electronic health records and rules to specifically improve personal health information breach notification rules. It’s ironic, then, that the rush to digitize personal health information didn’t include implementing security.  A recent survey of IT managers involved in healthcare revealed that 80% had suffered at least one incident or more of lost or stolen health information over the past year. More tellingly, most still have no support from their senior management to fix the problems.


It's not that the costs of a breach don't have sufficient teeth. Heartland Payment Systems has incurred over $12.6 million in fines, penalties, and other costs associated with their breach of credit card information. And while that's a different industry and a disproportionately massive example, the breach penalties and notification requirements between PCI and HIPPAA are not dissimilar. According to this health information study, the costs of a compromised health information record exceed $210 per instance. That can obviously add up quickly when a database containing thousands of records has been exposed.


So what's the problem, then? One huge one is that developers still don't have a good understanding of security. Most have heard of Cross-Site Scripting, for instance, but they've never seen it exploited. And when you don't understand the problem, it's hard to convince budget and time constrained managers that the costs to fix the problems are ultimately reasonable. Until the ease with which data breaches occur are understood, vendors are going to continue to play a dangerous game by not fixing the problems. There is a proven need for upgrading our medical systems to be both more cost-effective and to provide better overall health care. But security needs to be a part of that prescription, too.



Top Five Web Application Vulnerabilities 9/28/09 - 10/11/09

1) Juniper Networks JUNOS J-Web Multiple Cross-Site Scripting And HTML Injection Vulnerabilities

Juniper Networks JUNOS is susceptible to multiple Cross-Site Scripting and HTML Injection vulnerabilities. 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. A fix has not yet been released. Contact the vendor for additional information.


2) Symantec SecurityExpressions Audit and Compliance Server Error Message HTML Injection Vulnerability

Symantec SecurityExpressions Audit and Compliance Server 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. An update which addresses this issue has been released. Contact the vendor for further details.


3) Novell eDirectory 'dconserv.dlm' Cross-Site Scripting Vulnerability

Novell eDirectory is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage these issues 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 more information.


4) Interspire Knowledge Manager 'p' Parameter Directory Traversal Vulnerability

Interspire Knowledge Manager is susceptible to a parameter directory traversal vulnerability. Successful exploitation would give an attacker the means to view sensitive information which could lead to more damaging attacks. Updates which address this issue are available. Contact the vendor for additional details.


5) Kayako SupportSuite and eSupport 'functions_ticketsui.php' Cross-Site Scripting Vulnerability

Kayako SupportSuite and eSupport are susceptible to a Cross-Site Scripting vulnerability. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. An advisory and update which address these issues have been released. Contact the vendor for further details.


85% of IT security decision makers think successful external attacks very unlikely

A new report this week from ITC reveals that eighty-five percent of IT security decision makers think that losing data via an external threat is  "very unlikely." Wow. Once upon a time, anyone involved in application security had a need to educate potential customers on why application security was important. You remember. It's not the network layer anymore...the application layer is where the attacks are occurring. That hasn't changed. It's one thing to think that your internal threats are greater than your external threats. What with 'curious' employees and such, that's understandable. But it's something else entirely to think that external threats simply aren't relevant. I'm sure the company that rhymes with smartland payment blisstyms thought so, too.




Budget pressures still leading to increased risks

The Independent Oracle Users Group (IOUG) just released a database security survey of their members. As we've recently seen a lot, budget pressures are once again leading to increased risks. Organizations know there is a problem, understand it's getting worse, yet don't have the budget or resources to fix it. For instance, database breaches grew by 50% from last year to this. That's not a slight increase by any standard. Yet, the demand to do more with less has kept pace with the rise of the threats. And on top of that, database administrators see their biggest problems as internal threats, not external.  While spending on security has fared somewhat better than most areas during the down economy, until things pick up significantly security is still going to take a back seat to other concerns.



Labels: breach
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
Follow Us

HP Blog

HP Software Solutions Blog

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