Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers |
|---|---|
| Date: | Mon, 13 Aug 2007 13:48:23 -0400 |
On 8/12/07, pdp (architect) <pdp.gnucitizen@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 --------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: preventing sign up forms from being used for user enumeration, Javier Fernández-Sanguino |
|---|---|
| Next by Date: | Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers, Amit Klein |
| Previous by Thread: | Re: preventing sign up forms from being used for user enumeration, Javier Fernández-Sanguino |
| Next by Thread: | Re: [WEB SECURITY] Seeking feedback on proposed security restriction in the browsers, Amit Klein |
| Indexes: | [Date] [Thread] [Top] [All Lists] |