--- In [email protected], "Gervas
Douglas" <[EMAIL PROTECTED]> wrote:
>
> <<As web applications increased in sophistication, potential exploits
> evolved in complexity as well. Here is a sampling of the threats that
> are often perpetrated against these applications:
> 
> SQL injection - where an attacker would append SQL statements to an
> entry in a web based form to take advantage of a possible coding flaw
> whereby the SQL statement would inadvertantly be executed. The SQL
> statement would then yield valuable information from the web
> application database.
> 
> Cookie manipulation - the attacker manipulates parameters of an
> existing or harvested cookie to gain access and compromise a system
> 
> Cross-site scripting where the server processes a malicious script,
> leading to web defacement, cookie harvesting or other generally bad
stuff.
> 
> Other threats that assail newer web applications include XML based
> attacks that target the applications ability to process malformed or
> non-conformant XML documents.
> 
> How does one protect against these threats from an enterprise security
> perspective?
> 
> Conducting regular security audits and building a "defense-in-depth"
> approach to your security architecture are important ingredients to
> any secure enterprise. It is important that security audits include
> code level inspection of your web application to ferret out command
> injection or buffer overflow vulnerabilities. However, specifically to
> web application security, one should supplement with XML inspection
> conducted either as part of an XML firewall or an IPS that has
> incorporates that capability.
> 
> While doing the above will allow your security administrator to sleep
> easier at night, it doesn't necessarily mean that you're equipped to
> make the transition to securing your web services architecture.>>
> 
> You can find this blog at:
> 
>
<http://www.ebizq.net/blogs/security_insider/2006/06/web_services_security_web_appl.php>
> 
> Gervas
>

Here is a wee article on SOA & Security by Seán Wolfe which I received
by e-mail:

<<Fear Factor

There's been a fair amount of news popping up lately about SOA and
security, key among them the notion of so-called "rogue services."

The idea is that, for instance, a packaged application is brought into
the enterprise, which contains a number of services that are going
unused. But just because they're not being used doesn't mean they're
not capturing, say, customer information.

That's a hot-button these days. By now you've probably read the story
about the Pentagon contractor who went home with a laptop full of
information, not just on veterans, but active-duty military. The
laptop gets stolen, somehow, and now all that sensitive data, mind
you-is on the loose. The contractor's in trouble, the military is
wringing their hands, and law enforcement is on the lookout.

Same thing could happen with SOAs, except now the information is
available on the Internet to anyone who's got the skills to find it.

That could seriously wreak havoc with Sarbanes-Oxley compliance,
couldn't it?

Our top story this week warns of another source of security woes.
Commenting from the Security Software Summit in Baltimore, Jeff
Williams, CEO of security services firm Aspect Security, said
developers need to think security first before they develop a Web Service.

"I want people to think about input validation, error handling, and
other security matters before they create a Web service," Mr. Williams
says. "Otherwise, SOAs that push complexity behind the scenes and
emphasize application interoperability will create of a system of
insecure services sharing information."

AJAX and XML are also potential security hurdles, because they can
access data in smaller increments, making it tougher for security
applications to keep an eye on.

"This is a huge hurdle for developing and testing securely," says Joe
Basirico, manager of technology and security services with Security
Innovation, a provider of software security testing and training
services. "If an attacker can figure out your Ajax data request
layout, which depends on factors such as the type of data being
requested and the permissions needed to access data, they can figure
out how to access data without having the authorization to do so."

All of this is deeply scary stuff. But it leaves us to wonder how many
developers really don't design their apps with security at the
forefront of their minds.

Privacy maven Phil Zimmermann, the inventor of PGP (Pretty Good
Privacy) for email, and now the inventor of the Zfone, for Voice over
IP, likes to say that the Internet is a crime-ridden slum compared to
the well-manicured neighborhoods of the enterprise. If that's even
close to the truth, how can any developer in their right minds not be
looking very carefully at what applications open a door to the Internet?

While the security folks want to make money too, are they hyping the
dangers too much? This week, let's hear from developers on our poll.
How serious are the security threats to SOA or Web services? Feedback
on our poll, would you?

Sean Wolfe
Editor, SOA Pipeline
[EMAIL PROTECTED]
www.SOA-Pipeline.com>>

Here is an article by Larry Greenemeier on the same theme:

<<Popular programming initiatives such as services-oriented architectures and 
dynamic Web user interfaces are destined to fail if they're not developed with 
security in mind.

This was the sentiment Tuesday at the Software Security Summit in Baltimore, 
where application security vendors promised that those who forget past software 
development mistakes--particularly when cool new features trumped security--are 
destined to repeat those mistakes on the Web.

"I want people to think about input validation, error handling, and other 
security matters before they create a Web service," Jeff Williams, CEO of 
security services firm Aspect Security, said Tuesday. Otherwise, SOAs that push 
complexity behind the scenes and emphasize application interoperability will 
create of a system of insecure services sharing information.

Although the vendors here had an obvious self-interest in stirring things up, 
concerns over security aspects of Web services have been growing for several 
years. Simply put, it's just more difficult to bake-in protection in a 
distributed world.

In a worst-case scenario, instead of an attack on a Web application exposing 
some credit-card numbers, an attack could expose all credit card numbers, 
Williams added, pointing out that Web services only work "when you can trust 
the relationships between applications."

Dynamic Web coding languages such as Ajax, or Asynchronous JavaScript and XML, 
also require careful attention to security. Ajax applications access data in 
smaller increments, which lets them serve pages faster and provide the user 
with a smoother experience. "This is a huge hurdle for developing and testing 
securely," says Joe Basirico, manager of technology and security services with 
Security Innovation, a provider of software security testing and training 
services.

"If an attacker can figure out your Ajax data request layout, which depends on 
factors such as the type of data being requested and the permissions needed to 
access data, they can figure out how to access data without having the 
authorization to do so," says Basirico, who spent two years as a programmer 
with Microsoft.

Ajax is the technology underlying Google Maps, GMail, Microsoft's own MSN.com 
and Hotmail. Ajax allows a Web application to interact with a user without 
constantly downloading HTML pages, making software on the Web act like it's 
running locally on a PC.

This technology has captured the imagination of companies throughout the 
software industry. IBM in late January announced an "Open" Ajax initiative and 
donated software that allows developers to work with Ajax on the Eclipse 
programmer's workbench. This move was backed by a number of significant 
software and Web companies, including BEA Systems, Google, Mozilla, Novell, 
Oracle, Red Hat, and Yahoo. Open Ajax members met last month to advance their 
plans for standardized, openly developed specifications and tools for Ajax. 
Microsoft is even planning to offer Ajax-style programming technology 
code-named Atlas, which will be included in the next version of Visual Studio.

But attacks within Ajax environments are already a reality. A teenage 
programmer known as "Samy" last year inserted code in his MySpace Web site user 
profile so that those viewing his profile would have their own profiles 
corrupted. "The MySpace hack was the first Ajax worm and consisted of a 
cross-site script that automatically added [Samy's] profile to the friends list 
of many MySpace users," says Caleb Sima, chief technology officer of Spi 
Dynamics, a provider of Web application security and testing technology.

In an Ajax environment, the application makes frequent calls to a database, a 
characteristic that "increases your attack surface," Sima says.

With a more conventional Web application, a user would, for example, fill out 
an online form to apply for a new bank account and submit that form for 
approval. A programmer could add Ajax or Web services capabilities to that 
application by immediately alerting the user if information is entered 
improperly in different fields, even before the form is submitted. "These Web 
services are all making calls to a database," Sima says. "Most developers will 
throw a Web service up, make a database call that is probably SQL injectable, 
and have no session authentication to protect the transaction."

Such oversights compromise the security of Web applications as well as the 
databases they access.>>

You can find this at:

http://www.soapipeline.com/188702749

Gervas 









------------------------ Yahoo! Groups Sponsor --------------------~--> 
You can search right from your browser? It's easy and it's free.  See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to