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.

Tag Injection vs. Cross-Site Scripting

As my last post pointed out, it is not necessary to actually modify the HTML on a page to cause Cross-Site Scripting. If the attack is reflected directly into JavaScript or a style tag/attribute, you can have Cross-Site Scripting through  JavaScript injection or CSS injection, without any extra HTML necessary.

XSS attack examples are usually given like

 

 

<script>bad stuff here</script>

 

 

Or

 

 

<img src=x onerror=”bad stuff!”>

 

 

…but what if the bad stuff isn’t actually script? If you blacklist <script> tags and event attributes, you may prevent a textbook XSS attack, but that doesn’t mean you’re safe. An attack that injects an <iframe> tag could be used for clickjacking, where a user could click on a hidden link or button (in the invisible iframe) when trying to click on a visible link or button “below” the hidden frame. Something as seemingly safe as an <img src=”/relative/path”> tag could be used for a Cross-Site Request Forgery attack, if the site is vulnerable (in which case, you should probably fix your CSRF vulnerability!).

 

A common reason why someone might want to use a blacklist to filter out XSS attacks but allow other HTML tags is to allow simple tags such as <b>, <i>, and <u> for formatting. If that’s the case, a safer approach may be to use a language specifically designed for this case, like some variation of BBCode. While such languages have occasionally had XSS problems, it’s generally safer to only allow a specific set of formatting options (whitelist) than to only try to filter out “dangerous” looking tags (blacklist). If possible, don’t allow embedding images directly through an [img] tag, unless you can restrict it to a specific directory or image library.

 

It’s important to understand the distinction between HTML Tag Injection and Cross-Site Scripting, as either one can exist without the other, and still cause grief. Guarding against both is important to keeping your site secure.

 

Users of WebInspect should note that WebInspect will send HTML Tag Injection attacks only after all Cross-Site Scripting attacks have failed. If you see HTML Tag Injection (check ID 10044) in your scan results, it means we were not able to execute script to verify an XSS attack, but were still able to modify the HTML. Don’t take this lightly just because it shows up as a “medium”! While it’s not as serious on its own, it could still lead to an attack if not dealt with.

Context Matters for Cross-Site Scripting Filters

During a recent pen-testing exercise, Cross-Site Scripting (XSS) was as usual the most common issue found. Some sites had issues numbering in the hundreds (with nearly every parameter on every page being vulnerable). This should no longer be surprising to anyone; XSS has been one of the most common vulnerabilities for years. What was most interesting was that in several of these cases, the web site in question was doing very effective HTML filtering. They were either completely stripping all HTML tags, doing some crazy parse-and sanitize routine, or some other filtering that would make a traditional XSS attack impossible. However, these pages were still vulnerable. Why? They were reflecting parameters inside of JavaScript, where different rules apply.

 

When a parameter is reflected inside of JavaScript, an attacker no longer needs to inject an HTML tag to execute script. After all, a script is already being executed. It’s usually only a matter of using one or two characters to break out of the current statement to begin executing arbitrary code. Consider the following simple case:

 

http://example.com/news.php?date=2010-01-01

...

news.php:

<script>
make_ up_some_news('<?php echo strip_tags($_GET["date"]); ?>');
</script>

 

PHP's strip_tags() would remove a traditional XSS attack of the form “<script>alert('XSS');</script>”, but no tags are needed here. http://example.com/news.php?date=');alert('XSS');// will execute script without needing < or >. Even PHP’s htmlspecialchars() would not fix this, unless it was also passed ENT_QUOTES, as it will allow single quotes to pass through by default. HTML only defines the following characters as “special”, which could break the flow of the page:

 

Character

Description

"

quotation mark

'

apostrophe 

&

ampersand

less-than

greater-than

 

To protect a reflection in JavaScript, you would need to filter out newlines, semicolons, curly braces, square braces, parenthesis, and nearly every other non-alphanumeric symbol, depending on where the parameter is being reflected. Reflecting a parameter inside of a <style> tag or attribute has similar problems. It’s not necessary to use angle brackets inside of CSS in order to execute JavaScript, fetch a remote URL, or do other potentially dangerous things.

 

Of course, any list of “dangerous” characters or sequences runs the risk of being non-comprehensive. By far the safest and easiest way to protect yourself is to use a whitelist-style filter instead of a blacklist-style one. Whitelisting involves accepting only what is ‘good’ instead of trying to reject everything that is bad.  Instead of using strip_tags, in this case, try to parse the input as a valid date matching the yyyy-mm-dd pattern you expect. If you’re expecting an integer, require an integer, etc. If it doesn’t match, throw an error. This is not a time to be liberal with what you accept (and reflect)! If these pages were only accepting input in a specific format instead of trying to remove “dangerous” characters or sequences, there would not be a problem, regardless of where it was being reflected.

ASP.NET Cross-Site Scripting Followup: Mono

While doing the research that led to my recent post on ASP.NET view state as a vector for XSS, I discovered that while Microsoft's implementation is secure by default, Mono was not.


The default for a Page's EnableViewStateMac property is true in Microsoft's .NET Framework (despite what some documentation says). In Mono, this defaulted to false. In addition, there were certain problems with configuration which made it more difficult to mitigate this vulnerability:


In web.config, setting:



<system.web> <pages enableViewStateMac="true" />


did not enable view state signing. Neither did setting



<%@ Page EnableViewStateMac="true" %>


inside a page's .aspx file. While these two may be considered ordinary bugs and not directly a security problem, they made it much more difficult to work around the problem for existing installations.


Although Mono's view state format is somewhat different from Microsoft's, it was possible to port the exact same attack I used on Microsoft's ASP.NET to Mono by changing the data structure slightly and using Mono's serializer.


The following link will display a Javascript alert when running the XSP sample project on Mono 2.6.3: http://localhost:8080/2.0/menu/menu1.aspx?__VIEWSTATE=DAwNEAIAAA4BBQEOAQ0QAg8BAQlpbm5lcmh0bWwBJzxzY3JpcHQ%2BYWxlcnQoJ0FTUC5ORVQgWFNTIScpOzwvc2NyaXB0PhAAAAAOAAAA


Affected Versions


Mono 2.6.3 and older


Fixed Versions


Mono 2.6.4
Fixes for older branches should be committed soon


Other info


http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1459
http://www.mono-project.com/Vulnerabilities#ASP.NET_View_State_Cross-Site_Scripting

Configuration is Half the Battle: ASP.NET and Cross-Site Scripting

Although it's not a new problem, a recent advisory and BlackHat presentation have brought attention to an ASP.NET mis-configuration that can leave you wide open to Cross-Site Scripting (XSS) attacks, even if you are diligently sanitizing your other user-supplied data. If the view state is not cryptographically signed, it is possible for an attacker to overwrite properties of any of your server-side controls and modify HTML returned to the user, opening a vector for XSS.


On the Attack


An early example from the 2004 article “Understanding ASP.NET View State” does not really explain the full scope of the problem:


“Nefarious users could parse the view state, modify the prices so they all read $0.01, and then deserialize the view state back to a base-64 encoded string. They could then send out e-mail messages or post links that, when clicked, submitted a form that sent the user to your product listing page, passing along the altered view state in the HTTP POST headers. Your page would read the view state and display the DataGrid data based on this view state. The end result? You'd have a lot of customers thinking they were going to be able to buy your products for only a penny!”


The potential for damage is much worse than that, and the attack is even easier to carry out.



  1. It’s not necessary to fully parse the view state. Without the signature, the only protection the view state has left is the page hash, which always occurs at the same location and can be extracted by just Base64-decoding the right bytes.

  2. As an extension of #1, it’s not necessary to modify properties that are already being put in the view state. The view state parser does not expect any particular properties to be set (or not set), so you can modify nearly anything you want.

  3. The actual attack can, of course, consist of a malicious script and not just modified text.

  4. It’s not necessary to POST the view state data. In fact, the postback event validation makes it even more difficult. Simply encoding the view state data in a GET parameter named __VIEWSTATE will allow you to provide a malicious link to be clicked, not require a user to post a form.


The attacks I created for WebInspect were based on two more discoveries:



  1. Nearly every ASP.NET control is vulnerable (especially ASP.NET 2.0)

  2. A vulnerable control will almost always appear at index 1


The first point comes from the fact that most ASP.NET controls inherit from HtmlContainerControl, which has an InnerHtml property. The results of modifying InnerHtml should be obvious. While ASP.NET 1.1 would throw an exception if you tried to set that property on another type of control, it seems that most ASP.NET 2.0 controls will just set it as an attribute after performing a weak HTML-encoding. This allows for an easy attribute-based XSS attack, even if you can’t set the inner HTML of the control, leaving nearly all classes of controls vulnerable. Actually finding a control to attack brings me to point #2: how the control indexes work. On the ‘base’ page state, the list of control indexes corresponds to the order that they appear on the page. All text that is not part of a server-side control gets placed in a LiteralControl. This does not take open/closing tags into consideration, which is why most controls will first appear at index 1; index 0 will contain a LiteralControl for all text in the page (doctype, open tag, etc) leading up to it. The full list of controls, in general, alternates LiteralControls and subclasses of HtmlControl.


Detecting a Vulnerable ASP.NET Site


One of the biggest problems with this attack is how easy it is to detect a vulnerable site. In most cases, the actual exploit is also rather easy. WebInspect has been detecting an unsigned ASP.NET 1.1 view state since 2005, by just checking the last 2 bytes of the view state. A signed ASP.NET view state will end in 20 bytes of garbage, but an unsigned view state will end in “;>” or “>>”, due to the serialization format. We might get a false positive every 32k pages or so, but overall it’s a pretty effective test. In ASP.NET 2.0, the format changed to a binary serialization which requires reading the entire view state to determine if there is any extra data at the end (no more “<” and “>” tokens). It’s much slower, but still only a few lines of code when you use the ObjectStateFormatter available to you.


When doing my research for this vulnerability, I did a quick survey of 336 random sites running ASP.NET. Of those sites, I found 30 (9%) with unsigned view states. That may not sound like a lot compared to the number of total sites with XSS vulnerabilities (some estimates say at least half, others two-thirds). However, finding most XSS vulnerabilities usually requires checking hundreds of inputs with different kinds of validation. Finding a site with an unsigned view state is fast, simple and passive.


Of course, having an unsigned view state is not a guarantee of being exploitable. Some of those sites had a very minimal view state, which likely means that view state was disabled for the page (ASP.NET will still insert a “stub” view state). If your view state is disabled, disabling signing could be a legitimate performance improvement. If you are not disabling view state, but disabling signing, you’re almost certainly vulnerable.


Protect Yourself!


Protecting yourself is quite simple: don’t disable view state signing! It can be turned off in your web.config, a page’s .aspx file, or code-behind class. A full text search for “EnableViewStateMac“ should be all you need to check your own code. If you’re not changing it anywhere, you’re secure by default. WebInspect users can Smart Update to the latest SecureBase to get updated checks. We can detect an unsigned view state for ASP.NET 1.1 and 2.0 (and later; 3.5 still uses the same view state format), and attempt to attack both of them as well.


While you’re at it, there are a few other settings you may wish to review. If you are putting any sensitive information in the view state, it can be easily decoded and read by a 3rd party. You can set ViewStateEncryptionMode="Always" in your web.config or in individual pages. Since the signing key is always the same, it could be possible to construct a malicious, but valid, view state and then give the link to someone else, creating a Cross-Site Request Forgery attack (CSRF). This would be more difficult to execute than the XSS attack, but it’s just as easy to prevent. Set the ViewStateUserKey property in your page to a user-specific value, like the session ID. This adds a salt when signing, so that two users with the same view state data will have different signatures. If it were me, I would have all 3 options enabled, (salting, signing and encrypting), but everyone should evaluate the needs of their own applications.

Top Five Web Application Vulnerabilities 10/27/09 - 11/8/09

1) HP Power Manager Management Web Server Login Remote Code Execution Vulnerability


HP Power Manager is susceptible to a remote code execution vulnerability via the login form of the web based management web server due to improper bounds-checking of user-supplied data. Exploitation of this vulnerability can give an attacker the means to enact SYSTEM level commands and possibly lead to a complete compromise of the affected system. Even failed attempts will likely cause a denial-of-service condition. Updates which resolve this issue have been released. Contact the vendor for additional information.


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


2) Oracle WebLogic Server Administration Console HTML Injection Vulnerability


Oracle WebLogic Server is susceptible to an HTML Injection vulnerability via the Web Administration Console. 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 are available. Contact the vendor for more details.


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


3) Xerox Fiery WebTools 'summary.php' SQL Injection Vulnerability


Xerox Fiery WebTools is susceptible to a SQL Injection vulnerability. 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. A fix has not yet been released. Contact the vendor for more information.


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


4) IBM Lotus Connections Mobile Activities Pages Cross-Site Scripting Vulnerability


IBM Lotus Connections is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this 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 issue have been released. Contact the vendor for further details.


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


5) Roundcube Webmail Multiple Cross-Site Request Forgery Vulnerabilities


Roundcube Webmail is susceptible to multiple instances of Cross-Site Request Forgery. 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 these issues have been released. Contact the vendor for additional information.


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

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.


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


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.


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


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.


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


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.


http://www.securityfocus.com/bid/36661
http://www.securityfocus.com/bid/36660


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.


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

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.


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


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.


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


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.


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


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.


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


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.


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

Top Five Web Application Vulnerabilities 9/14/09 - 9/27/09

1) Novell GroupWise WebAccess Cross-Site Scripting Vulnerability


Novell GroupWise WebAccess is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this vulnerability to execute script code in the browser of an unsuspecting user in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Updates which resolve this issue have been released. Contact the vendor for additional information.


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


2) IBM Lotus Quickr Multiple HTML Injection Vulnerabilities


IBM Lotus Quickr is susceptible to multiple HTML Injection 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. Fixes which address these vulnerabilities are available. Contact the vendor for more details.


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


3) IBM WebSphere Application Server Eclipse Help Cross-Site Scripting Vulnerability


IBM WebSphere Application Server (WAS) is susceptible to a Cross-Site Scripting vulnerability. 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. Updates which resolve this vulnerability have been released. Contact the vendor for further information.


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


4) OSSIM SQL Injection, Cross Site Scripting and Unauthorized Access Vulnerabilities


OSSIM is vulnerable to multiple vulnerabilities including SQL Injection, Cross-Site Scripting, and unauthorized access. 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. Updates which resolve these issues are available. Updates which resolve these issues are available. Contact the vendor for additional details.


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


5) IBM Lotus Connections 'simpleSearch.do' Cross-Site Scripting Vulnerability


IBM Lotus Connections is susceptible to a Cross-Site Scripting vulnerability. This can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials. Updates which resolve this issue are available. Contact the vendor for more information.


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

60% of Internet attacks now conducted against web applications

New studies have gone a long way in confirming that certain web application security trends are accelerating. The SANS Top Cyber Security Risks report reveals that a full 60% of Internet attacks are now conducted against web applications. It's no longer unpatched operating systems that provide attackers with their main point of entry. In fact, patches for known flaws in operating systems are installed twice as fast as those for web application security vulnerabilities. Apparently, there are so many custom and open-source applications on a typical network that most admins can't even catalog them, let alone update them. And with more than 80% of newly-reported software flaws in common web applications, the numbers will only get worse. Despite the rise in web application attacks, organizations are not doing the simple things to improve their security by scanning for common flaws such as SQL Injection and Cross-Site Scripting. Scanning can go a long way towards preventing your servers from hosting malicious content which can infect users with malware--yet many organizations still bypass this critical step. And it's legitimate websites that have been compromised and are serving as malware servers that are now doing the most damage. Just ask the New York Times.

 

 

 The SANS report is available at http://www.sans.org/top-cyber-security-risks/

 

 

 

Top Five Web Application Vulnerabilities 8/31/09 - 9/13/09

1) Ruby on Rails Form Helpers Unicode String Handling Cross-Site Scripting Vulnerability

 

Ruby on Rails 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 address this issue have been released. Contact the vendor for additional information.

 

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

 

2) IBM Lotus Domino Web Access Cross-Site Scripting Vulnerability

IBM Lotus Domino Web Access (iNotes) is susceptible to a Cross-Site Scripting vulnerability. 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. Updates which address this issue have been released. Contact the vendor for further details.

 

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

 

3) Mozilla Bugzilla Multiple Remote Vulnerabilities

 

Bugzilla is susceptible to several remote vulnerabilities including multiple instances of SQL Injection and a password disclosure vulnerability. 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. The information disclosure vulnerability can be leveraged to steal user passwords. Fixes which address these issues have been released. Contact the vendor for more information.

 

http://www.securityfocus.com/bid/36373 (‘Bug.create()’ WebService Function SQL Injection Vulnerability)
http://www.securityfocus.com/bid/36372 (URL Password Information Disclosure Vulnerability)
http://www.securityfocus.com/bid/36371(‘Bug.search()’ WebService Function SQL Injection Vulnerability)

 

4) IBM Lotus Notes RSS Reader Widget HTML Injection Vulnerability

 

IBM Lotus Notes 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. This issue has reportedly been resolved in a hotfix. Contact the vendor for more details.

 

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

 

5) DotNetNuke Multiple Cross-Site Scripting Vulnerabilities

 

DotNetNuke is susceptible to multiple Cross-Site Scripting vulnerabilities. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials.   Updates which resolve these issues are available. Contact the vendor for additional information.

 

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

 


 

Top Five Web Application Vulnerabilities 8/17/09 - 8/30/09

1) Adobe Flex SDK 'index.template.html' Cross Site Scripting Vulnerability


Adobe Flex SDK is susceptible to a Cross-Site Scripting vulnerability. This can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials in context of a web application built using the SDK. Updates which resolve this issue are available. Contact the vendor for additional information.


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


2)Adobe ColdFusion Multiple Vulnerabilities


Adobe ColdFusion is susceptible to multiple vulnerabilities including instances of Cross-Site Scripting, HTML Injection, session fixation, and information disclosure. Victims can have their session hijacked and give an attacker unauthorized access to the application. Other possible attacks include having content added 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. The information disclosure vulnerability could also reveal sensitive information which could  lead to more damaging attacks. Updates which address each of these vulnerabilities are available. Contact the vendor for more information.


http://www.securityfocus.com/bid/36046 (HTML Injection)
http://www.securityfocus.com/bid/36096  (Double-Encoded NULL Character Information Disclosure)
http://www.securityfocus.com/bid/36056  (Cross Site Scripting)
http://www.securityfocus.com/bid/36053 (Multiple Cross-Site Scripting)
http://www.securityfocus.com/bid/36054 (Session Fixation)


3) Adobe JRun Multiple Unspecified Cross-Site Scripting Vulnerabilities


Adobe Jrun is susceptible to multiple instances of Cross-Site Scripting. 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. Updates which resolve this issue are available. Contact the vendor for more details.


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


4)  IBM WebSphere Commerce Unspecified Information Disclosure Vulnerability


IBM WebSphere Commerce is susceptible to an information disclosure vulnerability.  An attacker can gather sensitive information, possibly leading to brute-force attacks against user accounts. Updates which resolve this vulnerability are available. Contact the vendor for further information.


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


5) Xerox WorkCentre Web Services Extensible Interface Platform Unauthorized Access Vulnerability


Xerox WorkCentre is susceptible to a unauthorized access vulnerability. An attacker can leverage this vulnerability to access the device’s configuration settings and possibly acquire customer passwords. An advisory and patch which resolves this issue have been released. Contact the vendor for additional details.


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

stop the alert();

For nearly a decade, those of us in web security have been doing a disservice to ourselves and, more importantly, our customers. Like Pavlov, we've trained people to respond to certain stimuli. Rather than a bell, we've relied heavily on the alert() dialog box to prove our point--that cross-site scripting is possible.


And why shouldn't we (assuming we're not doing hardcore pentesting where we really need to abuse it)? It's easy to exploit, it's easy to explain, and most importantly: it's in your face.


I'm not saying everyone does it but... everyone does it. We've all proven our point, at one time or another, to a skeptical business person or developer by sending the trivial-but-hard-to-ignore link containing a <script>alert('Vulnerable+to+XSS' )</script> variant. Don't deny it, you know you have.


So what's the end result of all this alert() training? "There was no popup, therefore it's a false positive."  I have heard this more times than I want to admit. When I hear this, I have to sit back and wonder where we went wrong. When did that (business security consultant|developer|manager) become a dog salivating for another alert? When did I let it happen?


At this point you of course have to prove it's somehow dangerous, which means taking time to make the alert work or some sexier attack. Did the developers clobber alert() for some reason (Facebook), or does it need a simple tweak? Who knows... the point is, it takes time. The guy that can fix it didn't just look the source and say "oh crap, the kitchen sink is making it through unfiltered" simply because he didn't get smacked in the face with an alert box.


So what do we do? Well, there's no going back in time... but consider using other examples when you can. Liberal use of the <blink> and <marquee> tags with a "business has closed due to pending litigation" message or a redirect to a competitor's website will often do just as well. Or maybe someone should make an injectable version of jsAscii that replaces all the images on a page (that would be pretty sweet).


So stop demonstrating XSS with alerts and stop being lazy. Mix it up a little and give some different examples--in the end it will make all of our lives easier, our sites more secure, and just may stop that infamous developer who thinks the fix is to filter out the word 'alert'...

Top Five Web Application Vulnerabilities 8/03/09 - 8/16/09

1) Oracle Config Management Multiple SQL-injection Vulnerabilities


Oracle Config Management is susceptible to multiple SQL Injection vulnerabilities.  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.  Successful exploitation of these vulnerabilities requires  'Valid Session' privileges. Updates which address these issues are available. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35692
http://www.securityfocus.com/bid/35676


2) SAP NetWeaver Application Server 'uddiclient/process' HTML Injection Vulnerability


SAP NetWeaver Application 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. Updates which resolve this issue are available. Contact the vendor for more details.


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


3) WordPress 'wp-login.php' Admin Password Reset Security Bypass Vulnerability


WordPress is susceptible to an admin password reset security bypass vulnerability. Successful exploitation will allow an attacker  to reset the administrator password of the application. Updates which address this issue have been released. Contact the vendor for more information.


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


4) SQLiteManager 'main.php' Cross Site Scripting Vulnerability


SQLiteManager 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 has not yet been released. Contact the vendor for further details.


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


5) WordPress Plugin WP-Syntax Remote PHP Code Execution Vulnerability


The WP-Syntax plugin for WordPress is susceptible to a remote code execution vulnerability. Attackers can leverage this issue to execute arbitrary PHP code within the context of the affected webserver process. A fix has not yet been released. Contact the vendor for additional details. 


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


 

Top Five Web Application Vulnerabilities 7/20/09- 8/2/09

1) Hitachi Multiple Business Logic Products Unspecified Cross-Site Scripting Vulnerability


Multiple Hitachi Business Logic products are susceptible to a Cross-Site Scripting vulnerability. 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 this issue have been released. Contact the vendor for additional information.


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


2) IBM Tivoli Identity Manager Session Fixation Vulnerability


IBM Tivoli Identity Manager is susceptible to a session fixation vulnerability.  Victims who are enticed into visiting a malicious URI can have their session hijacked and give an attacker unauthorized access to the application. A fix has been released. Contact the vendor for further details.


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


3) Apache HTTP Server HTTP-Basic Authentication Bypass Vulnerability


Apache HTTP Server is susceptible to an HTTP-Basic authentication bypass vulnerability.  Successful exploitation will give an attacker access to protected resources, likely leading to more damaging attacks.  A fix has not yet been released. Contact the vendor more information.


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


4) WordPress Multiple Cross-Site Scripting Vulnerabilities


WordPress is susceptible to multiple instances of Cross-Site Scripting. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials.   A fix has not yet been released for the 'wp-comments-post.php' issue, while a patch that resolves the Comment Author URI issue is available. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35797
http://www.securityfocus.com/bid/35755


5) Bugzilla 'show_bug.cgi' Information Disclosure Vulnerability


Bugzilla is susceptible to an information disclosure vulnerability. Successful exploitation would give an authenticated attacker access to sensitive information, and would likely lead to more damaging attacks.  A fix has been released. Contact the vendor for more details.


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

Top Five Web Application Vulnerabilities 7/08/09 - 7/19/09

 1) Oracle Secure Enterprise Search 'search_p_groups' Parameter Cross-Site Scripting Vulnerability


Oracle Database is susceptible to a Cross-Site Scripting vulnerability that affects the Secure Enterprise Search component.  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.  Updates which resolve this issue are available. Contact the vendor for further details.


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


2) Cisco Unified Contact Center Express (CCX) Arbitrary Script Injection Vulnerability


Cisco Unified Contact Center Express (CCX) is susceptible to an arbitrary script injection vulnerability due to a failure of the application to sanitize user-supplied input. Successful exploitation will give an attacker the means to execute arbitrary code in context of the user running the application, possibly leading to further attacks. Fixes which address this issue have been released. Contact the vendor for additional information.


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


3) Cisco Unified Contact Center Express CRS Administration Interface Directory Traversal Vulnerability


Cisco Unified Contact Center Express is susceptible to a directory traversal vulnerability.  Successful exploitation would give an attacker the means to view, edit, or delete any file on the server via the CRS Administration interface. Other attacks would likely be possible.  Updates which address this issue have been released. Contact the vendor for more details.


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


4) WordPress Multiple Existing/Non-Existing Username Enumeration Weaknesses


WordPress is susceptible to multiple existing/non-existing username enumeration weaknesses as different responses are returned for each. Attackers can exploit these weaknesses to discover legitimate login usernames, which would likely aid in conducting brute-force password cracking attacks.  A fix has not yet been released. Contact the vendor for additional information.


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


5) WordPress 'wp-admin/admin.php' Module Configuration Security Bypass Vulnerability


WordPress is susceptible to a security bypass vulnerability. Authenticated users can leverage this issue to gain access to configuration scripts, giving them access to sensitive information and possibly the ability to escalate privileges. Successful exploitation would likely lead to other attacks.  Updates which address this issue are available. Contact the vendor for further details.


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

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

1) F5 Networks FirePass SSL VPN Unspecified Cross-Site Scripting Vulnerability


F5 Networks FirePass SSL VPN is susceptible to a Cross-Site Scripting vulnerability.  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 update which resolves this issue has been released. Contact the vendor for more details.


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


2) ModSecurity SQL Injection Rule Security Bypass Vulnerability


ModSecurity is susceptible to a SQL Injection rule security bypass vulnerability due to improper validation of user-supplied input.  An attacker can leverage this to bypass security restrictions and perform a number of web-application attacks.  A fix has not yet been released. Contact the vendor for additional information.


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


3) Apache Tomcat 'RequestDispatcher' Information Disclosure Vulnerability


Apache Tomcat is susceptible to an information disclosure vulnerability. Successful exploitation would give an attacker access to sensitive information which could likely be used to conduct more damaging attacks. Updates which resolve this issue have been released. Contact the vendor for further information.


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


4) FireStats 'firestats-wordpress.php' Remote File Include Vulnerability


FireStats is susceptible to a remote file include vulnerability due to improper validation of user-supplied input. Successful exploitation could lead to a complete compromise of the application and underlying system.  The latest version (1.6.2) resolves this issue. Contact the vendor for more information.


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


5) Kerio MailServer WebMail Cross Site Scripting Vulnerability


Kerio MailServer WebMail is susceptible to a Cross-Site Scripting vulnerability. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site.  Updates which resolve this issue have been released. Contact the vendor for further details.


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


 


 


 

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.