Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



WebApp Sec: Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers

Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers

From: James Landis <jcl24_at_cornell.edu>
Date: Mon, 13 Aug 2007 13:48:23 -0400

On 8/12/07, pdp (architect) <pdp.gnucitizen_at_googlemail.com> wrote:
> I would suggest that the trust should be put into the browser not the
> website since you have not control over the website but you do have
> control over the software installed on your PC. But again, the
> security of the client depends on the security of the server and the
> security of the server depends on the security of the client.

While thinking about this the last few days, I actually came to the
opposite conclusion. I believe it's fundamental not to trust the
client environment, especially with a protocol as ubiquitously (?)
implemented as HTTP. If we start relying on client behavior as a
partial solution to cross-domain problems, then we're opening
ourselves up for several negative side effects:

1) Developers get lazy about output encoding/transaction security in general
2) We "forget" about the reasons why certain controls have been
implemented in the first place, allowing the problem to resurface
again beyond the date of our collective memory lapse
3) The obvious nightmare of updating the spec, including backwards compatibility

I want to clarify that I'm speaking from the perspective of the
application developer, not the client/browser.

I am of course in favor of implementing anything that helps from a
client perspective. Certainly, problems such as the cross-domain
issues with Flash et. al. should be addressed, since they disobey the
same-source restrictions already defined.

I think there are ways to work within the existing spec to solve most
of the problems we're dealing with. There are a lot of issues that
arise because we're trying to build these complex applications onto a
stateless protocol, but if the trend continues toward more SOA, then
we're dealing with mostly stateless transactions anyway, and we have
to learn how to cope with those at some point.

-j

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------
Received on Aug 15 2007

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos