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.

HP AppDefender and HP WebInspect updates: GNU Bash vulnerability "Shellshock"

Many GNU Bash vulnerability attack vectors exist– some yet to be discovered and/or disclosed. HP Security continues to work diligently to provide product updates enhancing both protection and remediation. 

HP sponsors Texas A&M’s 2nd Annual Coding Gig

tamu.jpgHP Enterprise Security sponsored some brilliant minds at Texas A&M in the 2nd Annual Coding Gig.  Read on to learn more about the big data challenge given to these students and their results.

Tags: appsec| HP| security

HP updates 'HP ArcSight' portfolio to enhance big data security analytics

big security.pngHP today announced updates to its HP ArcSight portfolio, offering enterprises unified security analytics for big data with expanded identity monitoring to accelerate the detection of persistent threats.

 

Enterprises must proactively anticipate intrusions and hasten the detection of risks in order to protect valuable assets. To successfully identify and remediate occurrences of prolonged unauthorized network access, also known as advanced persistent threats (APTs), organizations must be prepared to:

 

  • Handle and process information at high velocity, volume and variety
  • Analyze structured and unstructured data both inside and outside their network
  • Monitor events in cloud, mobile and virtual environments
  • Automatically take action once a threat has been detected

 

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’.

 

Conclusion

 

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.

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

HP Software Solutions Blog

Featured


Follow Us
Labels
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.