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: June 2006

Common Misconceptions in Web Application Security, Part 2

In Part 1 of this thread, I mentioned how there were a number of people that had misconceptions about Web Application Security, especially Cross-site scripting (XSS). Last week, a blog called Neosmart posted an article on why XSS is not a vulnerability. I found this to be a perfect example of the largest and most dangerous misconceptions in Web Application Security.

"The problem isn’t so much in the attack itself as much as it is in the usage of the term. XSS is not a real security vulnerability in a product or script since it does not directly result in the loss of data integrity, but rather can be used as a tool in social engineering attacks and can never compromise the security of a server/host under any conditions nor that of an end-user on its own."

XSS is possible due to the lack of input validation on a web application. This allows an attacker to place malicious script (not only JavaScript, but also VBScript) in a page that will be returned to the user. The danger occurs because the user trusts that the webpage only contains content from the original website. The user doesn’t expect that page to contain script that would exploit them.

The list of possible payloads of a XSS attack are extensive. Common perception is that XSS attacks do annoying things like popping up ads or messages in the users browser. While these annoying payloads do occur, XSS exposes the user to numerous other dangers such as:

- Session Hijacking
- Phishing Scams
- Information/Identity Theft
- Denial of Service attacks against user’s browser
- Denial of Service attacks against any website
- Facilitate execution of other vulnerabilities
- Self propagating worms that manipulate large systems (i.e. MySpace.com worm, Yahoo’s Yamanner worm)

The article goes on to make the claim the XSS is something that is fixed in the browser.

"Even that is inconsequential however, because today all modern browsers protect against XSS attacks in one form or the other. To test that, our testers headed off to OSVDB and searched for “XSS” “pops cookie” and “document.cookie,” which are the words most often associated with XSS vulnerabilities. Although the results varied from one browser to the other and from one build to the next, on average 60% - 70% of the XSS vulnerabilities that were present and “functional” in the “last generation” of browsers (Firefox < = 1.0, Opera 8, Internet Explorer 6) didn't work in the "new generation" of browsers (Firefox 2.0-3.0 builds, Opera 9, Internet Explorer 7)."

This is statement shows there is confusion about how XSS works because browsers can't be "cured" of XSS. The vulnerability isn't in the browser! It exists in the improper input validation in the server's web application. The browser only follows directions by running script found in the page with basic security restraints to stop the script from doing blatantly harmful items (accessing the file system, reading inside a remote iframe, etc...). The attacks possible with XSS can not be stopped at the browser level stopped because script has legitimate, non-malicious purposes. Furthermore, legitimate script looks exactly like malicious script. Both make requests for images and more script, possible from other hosts. Both hook events like mouse movement or keyboard activity. Both read and modify the HTML of the page. Both access and manipulate web form values and cookies. Both can use Ajax request to make hidden requests using a user’s credentials without there knowledge. From the browser’s point of view, script is script, regardless of whether it is script from a XSS attack for not.

What should you take away from all of this? Simple. Cross Site-scripting is a security vulnerability. XSS can have a number of very dangerous payloads from annoying popups to session hijacking to complex, self propagating malware that uses Ajax. XSS occurs because web applications fail to validate input properly, allow attackers to submit HTML and JavaScript. XSS is also a 100% preventable problem. You should understand how it works and how you to can design secure applications.

How Poor Code Leads to Possible Identity Theft



Recently, while assessing a web application through an
assessment services engagement, SPI Labs discovered a vulnerability that would
allow attackers to guess the social security number of individuals if the attacker
had basic information about someone. The vulnerability occurred during the
action of signing up for an account. For legal reasons, the person signing up
had to be of a certain age. To verify this, the application contacted a back
end database that contained public information. If you gave the proper
information for name and address but not for a social security number, you
would get sent to another page asking you to re-enter your social security
number. This meant that we had entered the correct name and address and just
needed the right social security number. With this vulnerability, an attacker
could keep trying new values for a social security number until getting a page
that does not ask for a different social. With a hole like that, a phone book
would give you all the information you need to commit identity theft! SPI Labs
recommends two steps to customers to help prevent this type of attack:





  • Limit
    the number of attempts the user is allowed to submit sensitive
    information. We recommend after 3 attempts, lock out the client IP from
    submitting information for 24 hours.

     





  • Display
    generic errors not just specific inputs. Because the application told us that only
    the social security number was wrong, we must have had the address
    correct. A more secure error message would have been “The information
    you provided was not correct.”

XSS+Ajax worm attacking Yahoo mail users


At the beginning of the week, Yahoo was attacked by a worm that propagates
using nothing but JavaScript and Ajax.
I've been giving interviews to the press all day and talked with the FBI about the
worm, so let me take a moment to fill you all in.

 

Cross Site Scripting (XSS) is a really big problem that most
people don’t take seriously enough. In the past XSS was mainly used for cookie
theft, session hijacking, petty vandalism, or to just be annoying. But Ajax, with its ability to
make HTTP connection from JavaScript without user intervention makes XSS much
more dangerous. SPI has been in the forefront in researching the dangers of
XSS+Ajax.
I
spoke at the Toorcon security conference in September 2005 about the
dangers of this blended threat (see slides here) The MySpace worm, also
known as
the Samy worm of October 2005 was the first public use of XSS and Ajax.



Here is how the worm works:



A victim opens an email message inside of Yahoo’s web-based
email system. This email message contains an HTML IMG tag. This IMG tag
contains an onload attribute which
contains JavaScript that will execute when the image has finished loading. This
JavaScript does several things:





  • Uses
    XmlHttpRequest to fetch the victim’s address book

  • Scraps
    out all email addresses in the address book for yahoo.com addresses.

  • Uses
    XmlHttpRequest  to grab a “crumb”
    which is a token required to send email

  • Uses
    XmlHttpRequest to send a email infected with the worm to everyone in the
    victim’s addressbook who has a yahoo.com email address

  • Sends the
    harvested email addresses to a 3rd party,
    presumably for spamming purposes.



How did this happen? Well, Yahoo failed to perform proper input validation.They didn’t strip out all the different HTML attributes that allows
script to execute.



Since Yahoo has fixed the problem, I've
attached the source code for the worm to this post. It's quite a
learning experience to examine for yourselves. You can see it is quite small
and uses only 3 Ajax calls to send infected email to everyone in your
address book.


Update: The virus scanner running on out server keeps deleting the virus. I have encoded the virus with ROT13 to prevent the virus scanner from flagging it. You will need to use a site like this to decode the source code and read the virus.

Labels: worm| XSS Ajax

Mastercard abandon's PCI security standard




The two
largest credit card companies in the world, Visa and MasterCard, created a
standard to enforce security on all merchants that allow for payments via visa
or MasterCard. In March of this year, MasterCard removed almost all of the
requirements for web application security so that it is easier to allow
merchants to sign up with them. In doing this, they have dropped quality in
exchange for allowing lower qualified merchants to use their service. Part of
the reasoning behind this seems to have come from the inability of the current
tools they are using to properly assess web application vulnerabilities.
MasterCard’s solution is to only require that SQL Injection and Cross-site
scripting are checked for while leaving many potential vulnerabilities to be
exploited by attackers.




Most
scanners being used for these kinds of checks are not equipped to handle web
applications. While, many of them do have checks for SQL injection and
Cross-site scripting, they are static checks that are sent blindly in the hope
of maybe exploiting an application. Due to the new changes in the Payment Card
Industry security standard, these scanners do enough to allow a vulnerable
merchant to be considered compliant and secure. There are still a number of
vulnerabilities that could exist on the web applications including SQL
injection and Cross-site scripting. Unfortunately, the merchants won’t be
checked thoroughly without using a web application scanner like WebInspect.












WebInspect
differs from a lot of the other scanners in the way it works because of our new
“intelligent” engines. WebInspect no longer just sends blind attacks in the
hopes of hitting something, but it finds all possible parameters and audits
them with specially crafted attacks. SPI Labs is very proud of this new
technology because it is allowing WebInspect to function more like a human in
the way it can create attacks and determine if an application is vulnerable.
With WebInspect, all merchants for MasterCard and Visa would be able to have
the assurance that their sites are secure enough to credit card data so that
you and I don’t have to worry about Identity Theft. The first of these
“intelligent” engines will be coming out this month in the 6.0 release.

Massive defacing of GoDaddy sites





Last week saw the largest single attack in history against
web applications. A Turkish defacer named Iskorpitx defaced over 21,000
websites only a few hours. How did he accomplish this?








All of the sites that were defaced were hosted by a single
provider, GoDaddy. In addition to cheap domain name registeration, GoDaddy also
offers hosting services. Customers receive space and bandwidth, as well as a
few pages and scripts. It appears one of these supplied scripts didn’t properly
validate its input. Experts speculate that the culprit was “gdform.asp” which
allows website visitors to email the website owner. This script would write the
mail message to a temporary file. Iskorpitx exploited vulnerability to inject
code that would redirect the where the mail message was written into an HTML
page. This HTML page contained the defaced content.






The moral of the story: Scripts that are supplied to you may
contain vulnerabilities. You should turn off or remove those that you aren’t
using. If you must use a shared script, look at the code yourself or do some
Google searches to see if there are any known issues.

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.